Move Windows triggers not precise...

WARNING: You currently have Javascript disabled!
This website will not function correctly without Javascript enabled.

kbgeoff

5 discussion posts

I'm having an issue with my triggers not moving the matching window to the defined location... it's off by less than a dozen pixels.

I have one monitor that is dedicated to three RDP sessions. The windows are slightly smaller than the monitor's resolution so I'm able to cascade them from lower-left to upper-right. However, the window in the lower-left (which should be snug in the corner of that monitor) is slightly to the left so it shows up on the next monitor.

I originally thought it was something wonky with window snapping (where the left/top values for move were the pre-snapped values) but I turned off window snapping, did Alt+Space > M to get the window into the lower-left to the pixel, used the Move Windows crosshairs to choose size/location of the window and it still is scooted to the left.

Here's an image showing a little bit of both monitors. Visio is full-screen on the "RDP" monitor and the 2px red lines I added at top and bottom straddle the monitor boundary. You can see the RDP window on the left monitor a little bit. Please note, the vertical alignment of the RDP window (an inch below the Visio window) is just fine, it's only the horizontal alignment that seems to be weird.

I've attached the troubleshooting info to this post... you should be able to identify the trigger in question with my current monitor profile and the start of the window text.

Any ideas?

• Attachment [protected]: DisplayFusionDebugInfo.zip [21,864 bytes]

Jun 1, 2017 (modified Jun 1, 2017) • #1

I think I know what might be happening here. Could you try adding 7 to the "Left" value in the Trigger rule?

Jun 2, 2017 • #2

kbgeoff

5 discussion posts

I did a test by re-defining the X,Y,W,H of all three of my RDP windows. Here's how the triggers are set...

A: X=974, Y=-983, W=1700, H=990
    C: X=1078, Y=-1023, W=1700, H=990
    D: X=1194, Y=-1080, W=1700, H=990

Here's how the windows are positions after the trigger runs...

A: X=967, Y=-983, W=1714, H=997
    C: X=1071, Y=-1023, W=1714, H=997
    D: X=1187, Y=-1080, W=1714, H=997

Here's the difference between defined and actual...

A: X=-7, Y=0, W=+14, H=+7
    C: X=-7, Y=0, W=+14, H=+7
    D: X=-7, Y=0, W=+14, H=+7

So, to your point, I think I need to add 7 to X, subtract 14 from W, and subtract 7 from H. Does this jibe with the discrepancies you see in code?

Jun 2, 2017 (modified Jun 2, 2017) • #3

Yep, thanks for confirming! Window borders in Windows 10 are invisible, but still there in terms of setting window co-ordinates. We compensate for that automatically when running a function but it looks like we're also compensating for that in the location selector for the Trigger rules, so it's getting double-compensated.

We've added this to our list to fix up

Thanks!

Jun 5, 2017 • #4

kbgeoff

5 discussion posts

Thanks for the update, Keith! This provides a little more sense to the strange positioning I was seeing.

Jun 5, 2017 • #5

kbgeoff

5 discussion posts

I didn't see this fix explicitly called out on the v9.0 Beta 4 change log. Was the issue fixed in this version and just not listed or is it planned for a future release? If the latter, any idea when? Having to jump thru hoops to adjust the X/Y/W/H of windows snapped to screen edges is a pain.