DonationCoder.com Software > T-Clock
T-Clock 2010 (download)
sagji:
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 (June 10, 2010, 05:23 AM)
--- End quote ---
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:
--- Code: C++ ---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 (June 12, 2010, 09:01 AM)
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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(...)
--- End quote ---
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.
sagji:
Heh, now I am going to have to turn the house upside down to find all my forgotten Larson books. ;D
-haydut (June 13, 2010, 07:20 AM)
--- End quote ---
Which puts into my mind a Larsoneqsue picture of a house resting on its roof, and the caption
"He turned the house upside down looking of it."
daddydave:
The first thing I think of when I think of Gary Larson is the cartoon where a guy and a kangaroo are at a bar, and the guy is saying something like, "Well, you may be a kangaroo, but I know a few things about marsupials myself!" So true-to-life!
Stoic Joker:
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.
-sagji (June 13, 2010, 07:45 AM)
--- End quote ---
Thanks for the analysis, but... I'm afraid I was a bit unclear earlier. The code snippet I posted before is not in the build you are using/have. It was only posted as an example of the solution I am working on (Which makes you analysis flawed - which is my fault). The complete function code for the build you have is:
--- Code: C++ ---//================================================================================================//------------------------------+++--> Adjust the Window Position Based on Taskbar Size & Location:void SetMyDialgPos(HWND hwnd) { //----------------------------------------------------------+++--> int wscreen, hscreen, wProp, hProp; int wTray, hTray, x, y; RECT rc, rcTray; HWND hwndTray; GetWindowRect(hwnd, &rc); // Properties Dialog Dimensions wProp = rc.right - rc.left; //----------+++--> Width hProp = rc.bottom - rc.top; //----------+++--> Height wscreen = GetSystemMetrics(SM_CXSCREEN); // Desktop Width hscreen = GetSystemMetrics(SM_CYSCREEN); // Desktop Height hwndTray = FindWindow("Shell_TrayWnd", NULL); if(hwndTray == NULL) return; GetWindowRect(hwndTray, &rcTray); wTray = rcTray.right - rcTray.left; hTray = rcTray.bottom - rcTray.top; if(wTray > hTray) { // IF Width is Greater Than Height, Taskbar is x = wscreen - wProp - 21; // at Either Top or Bottom of Screen if(rcTray.top < hscreen / 2) y = rcTray.bottom + 21; // Taskbar is on Top of Screen else // ELSE Taskbar is Where it Belongs! (^^^Mac Fag?^^^) y = rcTray.top - hProp - 21; if(y < 0) y = 0; }else{ //---+++--> ELSE Taskbar is on Left or Right Side of Screen y = hscreen - hProp - 21; // Down is a Fixed Position if(rcTray.left < wscreen / 2) x = rcTray.right + 21; //--+++--> Taskbar is on Left Side of Screen else x = rcTray.left - wProp - 21; // Taskbar is on Right Side of Screen if(x < 0) x = 0; } MoveWindow(hwnd, x, y, wProp, hProp, FALSE);}
I have no idea where the experimental code will put the dialog at high DPI so I don't want to make it too accessible (e.g. make it the primary first post download). But if you are willing to give it a try Here is the compiled test version you thought you were testing earlier.
[Download removed to save space and avoid confusion - SJ]
Sorry about the confusion.
sagji:
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.
-sagji (June 13, 2010, 07:45 AM)
--- End quote ---
Thanks for the analysis, but... I'm afraid I was a bit unclear earlier. The code snippet I posted before is not in the build you are using/have. It was only posted as an example of the solution I am working on (Which makes you analysis flawed - which is my fault).
-Stoic Joker (June 13, 2010, 09:36 AM)
--- End quote ---
I didn't use the code sample at any point in my analysis, and the code sample below matches what I deduced including the magic number of 21. The complete function code for the build you have is:
--- Code: C++ ---//================================================================================================//------------------------------+++--> Adjust the Window Position Based on Taskbar Size & Location:void SetMyDialgPos(HWND hwnd) { //----------------------------------------------------------+++--> int wscreen, hscreen, wProp, hProp; int wTray, hTray, x, y; RECT rc, rcTray; HWND hwndTray; GetWindowRect(hwnd, &rc); // Properties Dialog Dimensions wProp = rc.right - rc.left; //----------+++--> Width hProp = rc.bottom - rc.top; //----------+++--> Height wscreen = GetSystemMetrics(SM_CXSCREEN); // Desktop Width hscreen = GetSystemMetrics(SM_CYSCREEN); // Desktop Height hwndTray = FindWindow("Shell_TrayWnd", NULL); if(hwndTray == NULL) return; GetWindowRect(hwndTray, &rcTray); wTray = rcTray.right - rcTray.left; hTray = rcTray.bottom - rcTray.top; if(wTray > hTray) { // IF Width is Greater Than Height, Taskbar is x = wscreen - wProp - 21; // at Either Top or Bottom of Screen if(rcTray.top < hscreen / 2) y = rcTray.bottom + 21; // Taskbar is on Top of Screen else // ELSE Taskbar is Where it Belongs! (^^^Mac Fag?^^^) y = rcTray.top - hProp - 21; if(y < 0) y = 0; }else{ //---+++--> ELSE Taskbar is on Left or Right Side of Screen y = hscreen - hProp - 21; // Down is a Fixed Position if(rcTray.left < wscreen / 2) x = rcTray.right + 21; //--+++--> Taskbar is on Left Side of Screen else x = rcTray.left - wProp - 21; // Taskbar is on Right Side of Screen if(x < 0) x = 0; } MoveWindow(hwnd, x, y, wProp, hProp, FALSE);}
--- End quote ---
This was very helpfull - I was able to identify why the window doesn't go off the bottom of the screen, and confirm my theory with a little experiment.
This function only changes the position on one axis - the other remains unchanged.
This function contains no DPI scaling, and the values you are working from and all native, however when you set the window's position that appears to be font scaled by the system.
As an experiment I set the taskbat to bottom and made it tall, and opened the properties - it then appeared near the right edge but positioned so the top was near the top of the taskbar.
I have no idea where the experimental code will put the dialog at high DPI so I don't want to make it too accessible (e.g. make it the primary first post download). But if you are willing to give it a try Here is the compiled test version you thought you were testing earlier. (see attachment in previous post)
Sorry about the confusion.
--- End quote ---
The special version places it in the same position as the normal one.
Code Review Comment
The way you check for Horiz/Verti taskbar isn't robust - it works but eventually on some system it will go wrong, and then you will have a very hard to find bug.
Given you split it into 4 positions any way the could should be
--- Code: C++ ---if (rcTray.top > 0) { // tray at bottom ...} else if (rcTray.left > 0) { // tray at right ...} else if (rcTray.bottom < hscreen) { // tray at top ...} else if (rcTray.right < wscreen) { // tray at left ...} else { // error - tray is fullscreen return;}
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version