With my current setting normally the dialog appears with just the left most part visible. At 200% it doesn't appear at all. 300% is the same. At 125% it appears entirely to the left of the task bar. When I go back to 150% it also appears to the left of the task bar. If I reboot then it goes back to appearing mostly off screen.-sagji
I haven't gone quite that high, but I have been able to duplicate some of the behavior. I created a Vista Virtual PC for testing and both it and the XP VPC work fine with the original code, however ... The research I've done points at there being some behavioral changes made it Win 7 so if I don't get any other reports from people running high DPI on Win 2k/XP/Vista (Hint...!) I'll have to add a version check to any fix we can concoct.
My first batch of tests with factoring the DPI into the positioning code did manage to make the issue worse (e.g. reproducible on XP & Vista) ... So that's a good sign that I'm on the right track. I just need to figure out which screen measurement to factor in to pin the thing in the right place. So far I'm pretty sure this one is wrong:
iW = GetSystemMetrics(SM_CXSCREEN); // Desktop Width
iH = GetSystemMetrics(SM_CYSCREEN); // Desktop Height
/////////////////////////////////////////////////////////////////////////////////////////////////////
hdc = GetDC(NULL);
wscreen = MulDiv(iW, GetDeviceCaps(hdc, LOGPIXELSY), 96);
hscreen = MulDiv(iH, GetDeviceCaps(hdc, LOGPIXELSY), 96);
ReleaseDC(NULL, hdc);
-Stoic Joker
Should wscreen not use LOGPIXELSX?
<ADDED>
When it is partly off screen it is only off the right side - the bottom edge is in the correct place.
I've noticed that behavior, and regardless of taskbar size/position too. Damn Strange it Are!
It might be an idea to log every step in calculating its position - as that might let us see where it is going wrong.
Or if you provide a debug version I could step through it and see if I can see anything.
I'm reasonably certain that the answer lies in feeding the right info into the MulDiv(...) function. as that's the only step where the DPI is handled.
But is it the only place where the DPI should be handled? What if some of the other values are already scaled?
The rest is just subtracting the dialog & gap sizes from the X & Y before tossing it to that point via MoveWindow(...)
I did some investigation using the windowspy tool that is part of AutoHotKey and looked at the values for both the taskbar and T-Clock's property window.
With the taskbar set so wide the left edge of the property window's border appears at the left edge. I see the following values.
T-Clock { left: 1035; top: 606; width: 491; height: 440; }
Taskbar { left: 1547; top: 0; width: 1013; height: 1600; }
The two lefts should be the same, and top+height should be close - but they are out by a factor of ~1.5, so it looks like T-Clock has font scaling applied to its coordinate space while the taskbar has the native coordinate space.
Setting the taskbar width so that the border only just appears on-screen I get:
T-Clock { left: 1709; top: 606; width: 491; height: 440; }
Taskbar { left: 2221; top: 0; width: 339; height: 1600; }
Doing some crunching of the number I find
T-Clock.left === 2560 - Taskbar.width - T-Clock.width - 21
Which is correct - but is in native coordinates not font scaled.
So it looks like you are calculating
top in font scaled coords, and
left in native, and then applying them in a font scaled context.