-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persist window size/location #370
Comments
I can see it now also, it seems to happen when you put it exactly on the limit at the edge of the screen. |
I think the problem occurs because I take the coordinates of the window from 'GetWindowPlacement' and compare them to coordinates from 'GetSystemMetrics' and looking at the coordinates I get, they aren't working in the same coordinate-system. |
If I remember right, all the coordinates need to be in the same scale (DPI) as the primary monitor. GetScaleFactorForMonitor is what I use to convert dimensions |
I just checked my code to see why I'm not seeing any similar issues. I
use GetWindowPlacement and SetWindowPlacement w/o any coordinate
translation and it appears to work fine even with multiple monitors at
different DPIs. I do some additional checking to make sure the
restoration is within valid bounds, but nothing DPI or scale related.
…------ Original Message ------
From: "Jan Wilmans" ***@***.***>
To: "CobaltFusion/DebugViewPP" ***@***.***>
Cc: "Matt Frost" ***@***.***>; "Author" ***@***.***>
Sent: 5/2/2021 5:29:51 PM
Subject: Re: [CobaltFusion/DebugViewPP] Persist window size/location
(#370)
I think the problem occurs because I take the coordinates of the window
from 'GetWindowPlacement'
<https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getwindowplacement>
and compare them to coordinates from 'GetSystemMetrics'
<https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics>
and looking at the coordinates I get, they aren't working in the same
coordinate-system.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#370 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5EK4SGYEP5T3MGGL5EWW3TLW747ANCNFSM437UKRWQ>.
|
All coordinates are in pixels so no scaling is involved, but I use 'GetSystemMetrics' to know whether the stored coordinates are actually visible right now. for example, if you have two monitors the 'virtual screen' size might be (-1920,0) - (1920,1200), but if one monitor is disconnected, half of the virtual screen's coordinates is now an 'off screen' location. I have had complains in the past of 'debugview not showing', and this was the cause. So the prevent that I check the 'visibility' of the coordinates before restoring the window's position. It not appears that the coordinates returned by GetSystemMetrics are not exactly aligned with the numbers coming from GetWindowPlacement... This is where the positions are stored: and here we read/check/set them: |
FWIW the code linked above is wrong because I should be able to make a PR to fix this, if this project still accepts them? |
sure, I would love a PR, the project files may be a little out of date, let me know if you need me to update them first |
The coordinates returned by GetWindowPlacement() must be passed to SetWindowPlacement() and not SetWindowPos() as the former functions account correctly for non-standard DPI, while the latter one does not. Using SetWindowPlacement() also allows to remove the checks for the coordinates being valid because the function already checks for this and will always position the window inside the visible area anyhow. Fixes CobaltFusion#370.
DebugView++ v1.8.0.103
Win 10 18363
Monitors: single 4K monitor
App window size/location is not persisting reliably.
See attached gif containing app version and example of non-persistence
The text was updated successfully, but these errors were encountered: