Processing Ajax...

Title

Message

Confirm

Confirm

Confirm

Confirm

Are you sure you want to delete this item?

Confirm

Are you sure you want to delete this item?

Confirm

Are you sure?
Save up to 50% on our desktop apps during our Year End Sale!Save up to 50% on our desktop apps during our Year End Sale, including DisplayFusion, ClipboardFusion, FileSeek, LogFusion, TrayStatus, and VoiceBot!Save up to 50% on our desktop apps during our Year End Sale!

User Image
Derek Ziemba
6 discussion posts
Version: DisplayFusion Pro 11.0 Beta 11

As part of my "Cycle Right Through Available Positions" script, a call is made to
BFS.Window.GetVisibleWindowHandles()
then filtered by
(visHandle) => BFS.Application.GetMainFileByWindow(visHandle) == thisApp
to find positions already occupied by the same program.

The problem is restored windows occupying positions behind foreground windows being included as visible windows, when they are actually entirely obscured by the foreground window.
Effectively, this results in "Visible" actually meaning "Present".
This gives rise to a 2nd problem where there is no BFS API to determine window ordering (like the "z-index", so to speak).

Example:
    - Suppose 4 monitors, each divided into 2 subdivision, therefor providing 8 total positions.
    - You have tons of vscode & chrome windows open, some you kind of forgot about, but they're there, just burried under other windows.
    - Monitor 1's focused window is 2 side by side vscode instances. Both monitor 2 & 3's focused windows are maximized Chrome instances.
    - You wish to maximize one of the vscode instances but still need to references the other instance, so before maximizing, you hit the "Move Right Through Available Positions" hotkey on the instance you need to reference expecting it to move to subdivision 1 on 2nd monitor.
    - Unexpectedly, it just dissappears!!! Or so you think before turning your head to see it jumped all the way 4th monitor used for Slack & email.
    - Realize the 2nd & 3rd monitors positions are technically already occupied by other vscode instances for one reason or another, even though those instances in those positions are in no way "Visible"
This also is a problem with maximized windows. If for example monitors 1, 2, & 3 have maximized Chrome windows but monitors 2's Chrome is behind a maximized vscode, invoking the script on Chrome@monitor#1 will result in it moving all the way to monitor#4. If every monitor has a maximized chrome, then invoking the script does nothing.
In the "Move Left" version of the script I detect the condition and force a move but I haven't yet updated the "Move Right" script with that code -- I'm using "Move Right" as the guinea pig to fix the issue mentioned in this post & https://www.displayfusion.com/Discussions/View/bug-bfswindowmovetonextmonitormaximized-on-an-already-maximized-window-breaks-the-window/?ID=01939519-6a2f-71a8-a111-bf1d91246e1a so didn't want to add my new "experimental feature" from "Move Left"
21 days ago (modified 21 days ago)  • #1
Owen Muhlethaler (BFS)'s profile on WallpaperFusion.com
Yeah we don't currently store the Z order, if it's something we add in the future we'll let you know.

Thanks!
20 days ago  • #2
Subscribe to this discussion topic using RSS
Was this helpful?  Login to Vote(-)  Login to Vote(-)