Just thought I’d post a note here about case #53050 that I filed a couple of weeks ago, and hoping their might be some relief from this issue in R3.
Screen(), as well as the Window properties, for left/top/width/height, don’t behave properly on Windows systems, when the application is built as HiDPI and when the user has a multi-display configuration with any difference in scaling factors between them. This isn’t a new problem.
It boils down to, it’s difficult, if not impossible, to programmatically move a window from one display to another; and do things like, center it, or expand it to fill.
Building the Windows version as non-HiDPI defeats the purpose of all the work that went into supporting Retina/HiDPI on both platforms. Telling users to temporarily set all of their displays to the same scaling factor when using the application isn’t realistic. It just needs to be able to trust the behavior of Screen() and the Window properties and work correctly.
The solution should be in the framework. Screen() should be adjusted to provide a continuous “virtual” desktop at a scaling factor, I believe, that would be normalized to Screen(0), which the user has designated as “main”. The left/right/width/height values for all of the Screen()s should be virtualized and contiguous from left to right (and top to bottom, although it’s reasonable to assume that users aren’t stacking display space vertically). The equivalent properties for the usage of Window should be on the same scale and applicable to the same contiguous desktop space that the corrected Screen() function would provide.
Has anyone else been trying to use Screen() in these configurations and managed a solution? What I’ve been in the process of doing, as a way of trying to work around this, is undo the flaws in what Screen() is currently doing, then use some Windows platform info to reconstruct what Screen() should be doing, and to come up with a fixed MyScreen() function to use instead. With some more work this should be possible, but then there’s as an issue of how the Window properties are also incorrect in some situations, and I’m not sure I can work around both areas.
One thing that’s necessary is a way of knowing what the scaling factor is for each display. Right now, the Screen() function doesn’t provide this. There’s the scaleFactor property of the Window, but that’s also not behaving “correctly” in these configurations. One way I’ve found to get the ACTUAL scaleFactor for a Window, no matter what display it sits on, is to do this:
// GetDpiForMonitor is available only in Windows 8.1 or later; there ought to be some equivalent for Windows 7 support…
Soft Declare Function GetDpiForMonitor Lib “Shcore” Alias “GetDpiForMonitor” (hMonitor As UInteger, dpiType as Integer, byref dpiX as UInteger, byref dpiY as UInteger) as Integer
dim realScaleFactor As Single
realScaleFactor = me.ScaleFactor // The scaleFactor of the WINDOW, SHOULD be the same as the scaleFactor of the display it’s currently positioned on
dim dpiX, dpiY As UInteger
call GetDpiForMonitor(ourGetMonitorHandle(), 0, dpiX, dpiY) // We use another function of ours to get the display’s handle
realScaleFactor = dpiX/96.0 // This is the actual scaleFactor of the display this WINDOW is in. Will be different from me.ScaleFactor if the display’s SF <> 100%