Okay, Did a compile with MSVS2010 or the modified code - which promptly failed the positioning test quite consistently.

So, I did a compile of the original (un "fixed") code - and all of the positioning test passed (for me)

Now, the $10,000 question is: Will it work for Sagji?!?
 (see attachment in previous post)
Sagji, all of the known universe now holds it's breath awaiting your reply...

 :D

-Stoic Joker (June 21, 2010, 05:58 PM)

That wasn't the universe holding its breath, that was the universe sniggering behind its hand.  :D

No change from the previous version.

I have Win 7 x64 installed, I downloaded the version at the top of the thread, the x64 version , changed Windows to use hideous 144dpi, and T-Clock looks fine to me whether Windows XP scaling is checked or unchecked (was prompted to log off each time). Is there something I should look for?

-daddydave (June 16, 2010, 01:06 PM)

Yes - I get the same untill I reboot.

I did try toggling Use XP DPI scaling in the program's shortcut, but it had no effect. Now as to which one can effectivly override the other goes ... I've not a clue.

-Stoic Joker (June 16, 2010, 12:22 PM)

Strange I don't get that setting - the closes I have is "Disable display scaling on high DPI systems" in the settings section of Compatibility tab, and everything in that section is disabled.

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)

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)

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++ [Select]

1. wscreen = MulDiv(iW, GetDeviceCaps(hdc, LOGPIXELSY), 144 /*GetDpiX()*/);
2.   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)

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.

If you put the error message here I could be equally confounded by its incomprehensibility.