DonationCoder.com Software > T-Clock
T-Clock 2010 (download)
Stoic Joker:
Interesting theory, however, both X & Y are adjusted at runtime by SetMyDialgPos(...) exclusively. If they weren't the dialogs would all be getting pinned to the top of the screen as they are all initially initialized at position 0,0. I suspect that width always being greated than height, and wide-screen monitors componding that, it's simply taking a larger sampling to skew the numbers far enough to notice/annoy...Either that or both are equally wrong, but the Taskbar is defending its Screen-estate by forcing the dialogs upward. Might be interesting to see what a wide monitor does when run portrait at high DPI.
I did have time to run a few tests yesterday and believe I have found part of the solution. If I feed the DPI into the MulDiv(...) function the dialog will appear it the correct location. The issue being that I'm hard-coding the DPI just for the test because for some reason Pure C does not like the GetDpiX() & GetDpiY() functions. But as soon as I get that figured out, I believe the correct answer will look something like this:
--- Code: C++ ---// Native Coordinates * Logical Pixels / DPI hdc = GetDC(NULL); wscreen = MulDiv(iW, GetDeviceCaps(hdc, LOGPIXELSY), GetDpiX()); hscreen = MulDiv(iH, GetDeviceCaps(hdc, LOGPIXELSY), GetDpiY()); ReleaseDC(NULL, hdc);
Note: The statement in the code commenting "Down is a Fixed Position" is merely in reference to the Taskbar dimensions being irrelevant to the height calculation if the Taskbar was on the (left or right) side of the screen.
sagji:
OK having another look at it.
One of the following lines is used to set the position of the dialog relative to the unblocked edge - both place the dialog in the correct place.
x = wscreen - wProp - 21;
y = hscreen - hProp - 21;
One of the following lines is used to set the position of the dialog relative to the taskbar that is blocking the edge - both place the dialog in the wrong place and the magnitude of the error is proportional to the width of the taskbar.
y = rcTray.top - hProp - 21;
x = rcTray.left - wProp - 21;
So it looks like the wscreen and hscreen are already scaled for font size - it is rcTray.top or rcTray.left that needs to be scaled.
Stoic Joker:
So it looks like the wscreen and hscreen are already scaled for font size - it is rcTray.top or rcTray.left that needs to be scaled.-sagji (June 14, 2010, 04:19 PM)
--- End quote ---
Close, I think we're on the same page now, but the rcTray RECT structure is generated by a query to the system for where the Taskbar window is actually at. Hence it need not be scaled as it's an actual location. 21 isn't important because it just a decorative gap to keep the dialog slightly away from neighboring edges.
The issue, I believe, is in the x & y "measurements" because they're based in the physical pixel resolution which in your case (IIRC) is 2560 x 1600. At the default 96 DPI the physical & logical pixel dimensions match. When the DPI is increased the logical pixel count also increases, but the physical pixel count (can't) doesn't. The x & y values are from GetSystemMetrics(...) which only measures the (current resolution) physical pixel dimensions and throws off the calculations by the logical pixel difference.
Here's an interesting bit. I compiled a test copy with this code:
--- Code: C++ ---wscreen = MulDiv(iW, GetDeviceCaps(hdc, LOGPIXELSY), 144 /*GetDpiX()*/); hscreen = MulDiv(iH, GetDeviceCaps(hdc, LOGPIXELSY), 144 /*GetDpiY()*/);
On XP @ 144DPI the dialog position is perfect.
On Win 7 @ 96DPI the dialog y (height) is correct, but the w is (almost perfectly) in the middle of the screen.
On Vista @ 144DPI perfect, at 96DPI same odd behavior as 7.
[Download removed to save space and avoid confusion - SJ]<-Let me know if this works for you @ 144DPI also)
If I can ever get the GetDpi() functions to cooperate (compile) we should have this thing licked.
sagji:
So it looks like the wscreen and hscreen are already scaled for font size - it is rcTray.top or rcTray.left that needs to be scaled.-sagji (June 14, 2010, 04:19 PM)
--- End quote ---
Close, I think we're on the same page now, but the rcTray RECT structure is generated by a query to the system for where the Taskbar window is actually at. Hence it need not be scaled as it's an actual location.
-Stoic Joker (June 14, 2010, 06:19 PM)
--- End quote ---
I think you missed a consequence of something I said.
When I use windowspy from AutoHotKey I get actual values - probably returned by using the same method you use to get the position of the taskbar. When it queries the position of the taskbar it sees values based on the actual resolution. When it queries the position of the properties dialog it sees values scaled down for the DPI setting - then the dialog is just off screen (x = 2560) it returns x = 1709.
It looks as if Win 7 is doing the DPI scaleing for you and things are going wrong becasue this means that the x is being scaled twice.
21 isn't important because it just a decorative gap to keep the dialog slightly away from neighboring edges.
The issue, I believe, is in the x & y "measurements" because they're based in the physical pixel resolution which in your case (IIRC) is 2560 x 1600. At the default 96 DPI the physical & logical pixel dimensions match. When the DPI is increased the logical pixel count also increases, but the physical pixel count (can't) doesn't. The x & y values are from GetSystemMetrics(...) which only measures the (current resolution) physical pixel dimensions and throws off the calculations by the logical pixel difference.
Here's an interesting bit. I compiled a test copy with this code:
--- Code: C++ ---wscreen = MulDiv(iW, GetDeviceCaps(hdc, LOGPIXELSY), 144 /*GetDpiX()*/); hscreen = MulDiv(iH, GetDeviceCaps(hdc, LOGPIXELSY), 144 /*GetDpiY()*/);
On XP @ 144DPI the dialog position is perfect.
On Win 7 @ 96DPI the dialog y (height) is correct, but the w is (almost perfectly) in the middle of the screen.
On Vista @ 144DPI perfect, at 96DPI same odd behavior as 7.
(see attachment in previous post) <-Let me know if this works for you @ 144DPI also)
--- End quote ---
Nope - you now get both wrong - the dialog appears at the same x as before but not it is only 1/2 way down the screen.
This difference between XP and later is not totally unexpected - on the Win 7 page to set the custom DPI there is a checkbox "use XP style DPI scaling."
If I can ever get the GetDpi() functions to cooperate (compile) we should have this thing licked.
--- End quote ---
If you put the error message here I could be equally confounded by its incomprehensibility.
Stoic Joker:
Nope - you now get both wrong - the dialog appears at the same x as before but now it is only 1/2 way down the screen.-sagji (June 15, 2010, 11:26 AM)
--- End quote ---
...Shit. :wallbash:
Well on a brighter note, I don't have to worry about the compiler error now as the code wouldn't have worked anyway...
:hanged:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version