Window.Top not working on Second Screen

General
1

When the app closes, it reads the top-left corner of every open window (WIndow.Top and WIndow.Left) and saves them to disk. When the app opens again, it reads the X-Y coordinates from disk, and positions the windows to where they were when the app closed. This works fine.

Now add a second monitor. If both monitors have the same scale, no problem. But when one monitor has a different scale than the other, crap happens.

Monitor(0) has 250% scale
Monitor(1) has 150% scale

It is not practical to have the monitors the same scale, because while they are both identical 4K resolutions, one is many times the other in physical size.

When I set the Y position of a window on monitor 1 at 864 (Window.Top = 864), it works. The window is completely on the screen and visible, and it still has a lot of extra room below the window to the bottom of the screen.

When I set the Y position of the same window on monitor 1 at 865 (Window.Top =865), the window disappears. It exists, but it is completely below Screen 1. No part of the window is visible. When I read back the Y position from the window (Y = Window.Top), it reads 1442, even though I just wrote 865.

I have breakpointed and debugged the app. I am certain there is no problem with the code. I set a breakpoint to watch the 864 value go into Window.Top, and then immediately read 1442 from Window.Top in the debugger. The stored and retrieved Y values are different. Every value over 864 has the same result, that is, XOJO positions the window 1.66 times lower than the actual setting.

In other words, the value XOJO writes to the window is 1.66 times the actual value the code writes to the Window function, but only if the .Top value is over 864.

What is going on? Surely there has to be a way to work with screens that are not of the same scale.

2

I have a three monitor setup with my main screen in the centre. I too store the window coordinates of my main screen (also if Full-screen when closed).

The coordinates of my left screen windows are negative — could this be the issue, are you making them positive. Also, before I set the coordinates I check if they are within the limits of the screens, otherwise if I had a window open on the left monitor and relaunched with the monitor missing, the window could be placed in limbo, or with it’s window handle above the screen top.

I was able to fix these with a Full-screen on then off toggle. Also, if the window seems out of range, don’t apply the previous settings, in case the screens have been moved or removed since quitting.

3

[quote=487473:@Alex McPhail]Monitor(0) has 250% scale
Monitor(1) has 150% scale[/quote]
This leads to the assumption that you’re noticing that on Windows or Linux - since macOS usually doesn’t have those Screen Scales :wink:

Yup. Xojo’s Framework is still quite buggy in that regard :frowning:

This Thread comes to mind: Screen() behavior in Windows HiDPI builds with multiple displays/scaling factors .
And those Feedback Reports: <https://xojo.com/issue/53050>, <https://xojo.com/issue/53983>

The situation described in <https://xojo.com/issue/53983> might give a hint about what’s going on.
Xojo is using “Points” for Screen/Dialog-Positions (trying to take account of the .ScaleFactor), not effective Pixel-Positions.
Trying to place a Dialog on a “Monitor that is left of the Main Monitor” with -1000 (in “Points”) might lead to the Xojo Framework thinking it’s still on the Main Monitor. And quite some other situations that boil down to the same/similar “positioning issues”.

So what I am doing: Figure out on which Monitor the Window is. And when re-positioning, I explicitly set it to the relative position of the Monitor. Since you can’t do that properly with Xojo’s Framework methods (especially with all these Multi-Monitor/Multi-Scales HiDPI issues they are still suffering), I do that using the Windows API.

Have a look at this example project: Monitors_v3
It’s been a while that I’ve written that. Maybe this is helpful for your purpose. If not - never mind :wink:

4

David - I don’t think you have applied different scales to your screens on MS Windows. If you did, then you would experience the same problem I am.

To further illustrate the problem, if I manually drag the window near the bottom of screen 1, then read the Window.Top property, it reads correctly. But then in the next statement, if I write the same number back to the same Window.Top property, the window disappears of the screen.

This is clearly a problem with XOJO.

5

[quote=487546:@Alex McPhail] if I write the same number back to the same Window.Top property, the window disappears of the screen.
This is clearly a problem with XOJO.[/quote]
Have you tried positioning the Window using Windows API, such as in the linked example project Monitors_v3?
If you play with the [Pos] Buttons on the bottom-right: do they work in your situation/setup?

6

What you are seeing is our framework attempting to adjust coordinates for the different screen resolutions:

(864 / 1.5) * 2.5 = 1440

The hope was that having the other monitors adjusted relative to the first would be less confusing, but it sounds like the math is backwards in this case and should be:

(864 / 2.5) * 1.5 = 518.4
7

This is the same problem as my detailed <https://xojo.com/issue/54369> from December 2018. I’ve re-tested recently and it’s still behaving badly. (Yes, it’s a Xojo issue, for Windows with multiple displays that have mixed scaling factors. OSX builds work perfectly in similar configurations).

I’m hoping to see this fixed sometime soon so that I can ship certain software products with support for HDPI under Windows - at the moment, I’m limited to turning off HDPI for Windows builds in those situations.

Greg: all of the displays should have adjusted coordinates based on the “main” display being central, with it’s top left corner being at 0,0 in the entire virtual coordinate space. All other displays to the left and right need to end up with contiguous virtual coordinates relative to “main” regardless of scaling factors. Any/all of the displays can have a mix of what would be considered “regular” scaling factors (100% on a standard def display, 200% or 300% on a Retina/HDPI display running at “Retina” resolution like OSX, etc) plus other variations. In a 2 or 3 display system, “Main” can be any type of display at any display scaling and at any position within the arrangement. And the same is true for every display attached.

From a Xojo application standpoint: the framework should provide, and then accept back (so that the application can programmatically position the window on any of the attached displays) coordinates for the window that will move it to where it’s expected to go. In my case, I want to query Xojo about the attached displays (Xojo provides virtual coordinates), and then based on those coordinates, I want to be able to position and center a Xojo window on each of those displays (with that window being smaller than the display size). Right now that only works perfectly if either (a) the Xojo application is built with HDPI turned off, or (b) it’s built with HDPI turned on, and all attached displays have the same scaling factor. In the second case, as soon as one display has a different scaling factor, it’s broken.

“Broken” means: trying to center a window on a display that’s not “main”, and then, that window ends up either being mispositioned (partially overlaps into one of the other displays) or in some cases, it totally disappears (it’s been mis-offset so far in virtual coordinate space that it doesn’t appear on any of them).

8

[quote=487739:@Jürg Otter]Have you tried positioning the Window using Windows API, such as in the linked example project Monitors_v3?
If you play with the [Pos] Buttons on the bottom-right: do they work in your situation/setup?[/quote]

Jürg: Many thanks for your sample program. I will look at it this weekend.

9

It seems to me this should be a fundamental capability of a Windows-based system. I am surprised such a critical weakness has persisted for so long. Is this something XOJO is working on?

10

[quote=487739:@Jürg Otter]Have you tried positioning the Window using Windows API, such as in the linked example project Monitors_v3?
If you play with the [Pos] Buttons on the bottom-right: do they work in your situation/setup?[/quote]

Jürg: I worked your code into my app, and now it works perfectly !!!

Thank you so much for you help. Not having the Windows programming background, I never would have figured this out on my own.

Cheers!

Alex

11

[quote=487739:@Jürg Otter]Have you tried positioning the Window using Windows API, such as in the linked example project ?
If you play with the [Pos] Buttons on the bottom-right: do they work in your situation/setup?[/quote]

fwiw: I tend to empty my Dropbox every now and then… so the links above will fail sooner or later.

Since this example seems to be helpful to others, I have moved the example project: Monitors to here: Xojo - some pieces 4u.