Author Topic: T-Clock 2010 (download) (Read 1066758 times)

Stoic Joker · « **Reply #150 on:** June 14, 2010, 06:50 AM »

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

// 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 · « **Reply #151 on:** June 14, 2010, 04:19 PM »

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 · « **Reply #152 on:** June 14, 2010, 06:19 PM »

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. 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]

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 · « **Reply #153 on:** June 15, 2010, 11:26 AM »

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]
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)

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.

Stoic Joker · « **Reply #154 on:** June 15, 2010, 12:14 PM »

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)

...Shit.

Well on a brighter note, I don't have to worry about the compiler error now as the code wouldn't have worked anyway...

Stoic Joker · « **Reply #155 on:** June 15, 2010, 07:40 PM »

Okay new plan of attack.
Step 1. RTFM...
Step 2. Repeat Step 1.

...And then I noticed I had the friggin equation backwards.

I'm currently installing Win7 on a Virtual PC so I have a test machine I can safely reboot every 5 minutes, without worry of losing the project history/ or having to restart the other virtual test machines.

Stoic Joker · « **Reply #156 on:** June 15, 2010, 10:00 PM »

Okay, so the MSDN has an article on how to properly support High DPI environments. In said article it had some sample code, which I ripped through, to pull the following out a section of code that was commented as being the right way to handle window positioning at High DPI settings.

When run, it made the problem worse on all of the (XP/Vista/7) test machines, depending on DPI setting, it would either show up in the center, or to the left of the screen.

In a fit of curiosity...(after a short inspirational swearing break)... I concocted the following test:
Currently released un-fixed beta 7.5 build of T-Clock
OS = Windows 7 Pro VPC
Resolution = 1600 x 864
DPI = 144

The Properties Dialog showed up right where it was supposed to ... Which is not exactly the result "we" were expection.

So, here is the "score":
Sagji cannot get it to work properly (show up in the right place).
I cannot get it to fail (show up in the wrong place).

Conclusion: We Really need a third option/party/kind soul/curious bystander to run this thing at 144DPI on Windows 7 to see what it does - because at this point I'm honestly not sure if I'm trying to fix it, or break it.

sagji · « **Reply #157 on:** June 16, 2010, 11:46 AM »

If this the article you are referring to?
http://msdn.microsof...464660(v=VS.85).aspx

From what It says, and what you are seeing it sounds like DPI Virtualisation is on for me and off for you - check if XP scaling is on in the custom DPI setting dialog.

Stoic Joker · « **Reply #158 on:** June 16, 2010, 12:22 PM »

I'll have to explore that this evening. I know I didn't change it there so it'll be set to whatever the default is.

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.

And yes, that is one of the articles I went through. There is another in the same area that has the code samples I based the (disfunctional) modifications on.

daddydave · « **Reply #159 on:** June 16, 2010, 01:06 PM »

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?

Stoic Joker · « **Reply #160 on:** June 16, 2010, 03:09 PM »

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)

lol ...bare in mind Sagji is using a 30" monitor at 2560 x 1600, so bumping to fonts up a bit is quite understandable.

Other than letting us know what you monitor size, configuration, & resolution is I can't think of much at the moment - But it's Sagji's bugg (hehe) ... So I'd like to wait and see what his take on this is before drawing any conclusions.

Thank you.

[Musing aloud] Are screen coordinates calculated/handled differently on really big displays?!?

daddydave · « **Reply #161 on:** June 16, 2010, 05:27 PM »

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)

lol ...bare in mind Sagji is using a 30" monitor at 2560 x 1600, so bumping to fonts up a bit is quite understandable.
-Stoic Joker (June 16, 2010, 03:09 PM)

Must be nice..

Other than letting us know what you monitor size, configuration, & resolution is I can't think of much at the moment - But it's Sagji's bugg (hehe) ... So I'd like to wait and see what his take on this is before drawing any conclusions.

Thank you.

[Musing aloud] Are screen coordinates calculated/handled differently on really big displays?!?

Mine is 1440 x 900. 19" wide screen.

Stoic Joker · « **Reply #162 on:** June 16, 2010, 06:19 PM »

I've got dual Dell UltraSharp 17" monitors. So I can max the VPC at 1600 x 984 @ 144DPI and it still does just fine.

T-Clock 2010 (download)

I'm Stumped.

sagji · « **Reply #163 on:** June 18, 2010, 10:58 AM »

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.

Stoic Joker · « **Reply #164 on:** June 18, 2010, 12:30 PM »

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.
-sagji (June 18, 2010, 10:58 AM)

Um... When I change the DPI setting it only asks to logoff and then back on to enable the change (which I do). But are you saying that after a reboot the behavior changes again? Or are you just rebooting instead of logging off/on to be sure it takes? IIRC my results don't change either way as I had to reboot the VPC a few times during the tests for other reasons - and - I just can not get the thing to fail.

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.
-sagji (June 18, 2010, 10:58 AM)

Crap, you're right - I misquoted the dialog.

On a Side Note: everything on the compatability tab here on my office machine is disabled also.

Damn Strange it are...

Stoic Joker · « **Reply #165 on:** June 18, 2010, 04:07 PM »

Okay, in the interest of clarity I skipped the vitalization and ran the test on my physical hardware. So with 2 17" monitors running 1280 x 1024 resolution I ran the DPI test with Logoff and reboot between each change to see if/how it would (Mis?)behave.

120DPI (125%) it positioned itself just fine after log off/on - Also positioned just fine after reboot.

144DPI (150%) it positioned itself just fine after log off/on - Also positioned just fine after reboot.

192DPI (200%) it positioned itself just fine after log off/on - After reboot it positioned itself below the taskbar.

I would however like to note that at those (1280x1024 192DPI) settings nothing else on the screen looked right either. Text, Icons, Wallpaper all were blurry, and the Icons were so large that four of them could barely fit in a row. e.g. settings were outside the rational limits of the hardware.

sagji · « **Reply #166 on:** June 19, 2010, 05:38 AM »

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.
-sagji (June 18, 2010, 10:58 AM)
Um... When I change the DPI setting it only asks to logoff and then back on to enable the change (which I do). But are you saying that after a reboot the behavior changes again? Or are you just rebooting instead of logging off/on to be sure it takes? IIRC my results don't change either way as I had to reboot the VPC a few times during the tests for other reasons - and - I just can not get the thing to fail.
-Stoic Joker (June 18, 2010, 12:30 PM)

If I change the DPI to 150% and log off then it appears in the correct place. When I reboot it appears in the wrong place.
If I change the DPI to 125% then regardless of rebooting it always appears in the correct place.

Stoic Joker · « **Reply #167 on:** June 20, 2010, 01:34 PM »

Well, best I can tell at this point is that my nemesis is apparently the Win7 DWM. I say this because its influence is only felt at DPI settings that are above 150. Anything below that reverts (via default system behavior) to XP's scaling behavior.

Hence the issue becomes a pissing contest between the application and the DWM as to where and how things get scaled/located...especially if the application is not marked as DPI aware in some fashion. Therein lying the tricky part.

Options for marking an application as DPI aware are either using a function call (that isn't recognized by MSVS2005), or using an entry in the manifest (that isn't recognized by MSVS2005). Which brings one (or at least me) to the conclusion that this ain't gonna get solved with MSVS2005 - Which of course I am and have been using.

So...(best I can tell) it's backup the project and upgrade the compiler time. I grabbed a copy of MSVS 2010 pro yesterday, and am currently pondering what if any install options there are e.g. will they play nice together, or do I have to commit to an upgrade.

Stoic Joker · « **Reply #168 on:** June 21, 2010, 05:58 PM »

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?!?

Sagji, all of the known universe now holds it's breath awaiting your reply...

sagji · « **Reply #169 on:** June 22, 2010, 04:28 AM »

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...

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

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

No change from the previous version.

MKappy · « **Reply #170 on:** July 02, 2010, 01:27 PM »

Hello all

Just recently found T-Clock after years of using Dale Nurden's program.
I'm glad to see this effort going on as I had always hoped there would be enhancements made.
I use the functionality every day at both home and work.

I'd like to offer some enhancement ideas that may or may not have already been suggested.

1 Allow what is displayed when the mouse hovers over the date/time in the system tray to be user selectable.
What I personally would select for example is to display the current months calendar.
This allows you to quickly see the month without using up one of your mouse click options

2 Add right click capability to match the left click.
Note: Middle button on Win 7 Pro brings up "document flip" so we really only have 2 copies not 4 available.

My motivation for this is to give us at least one if not two additional copy strings.

Example use case:
--- Left Single Click - copy the current date time as a Prefix - e.g. yyyy-mm-dd_
--- Left Double Click - copy the current date time as a Suffix - e.g. _yyyy-mm-dd_hh"hrs"_mm"mins"
--- Right Single Click - copy in a user defined string - e.g. an email address, [email protected]
--- Right Double Click - copy in a user defined string - e.g. an email address, [email protected]

3 Auto Rename file for file drag and drop?

This might be possible now but it's beyond my knowledge of how one would set this up.

The idea here would be to rename a dropped file to have a predefined user date/time string appended as a prefix or suffix before the file extension.
This might be the same as the single click option for example or perhaps yet another string specifically for this purpose.
For example:
   Original file name: Draft_ideas.doc
   Suffix Drag drop results in: Draft_ideas_2010-07-02_02hrs_07mins.doc
   Prefix Drag drop results in: 2010-07-02_Draft_ideas.doc

4 Drag and drop the clock ?

I've got no idea if this is even remotely possible....
What if you click down on the date/time in the system tray and drag and drop it?
Could this be made to paste a string?

I hope to one day get modern coding skills back up to date and join you all as contributing developers.

Thanks again for your efforts

   Mark

Stoic Joker · « **Reply #171 on:** July 05, 2010, 09:23 AM »

Being that I had a vacation I decided to actually be on vacation (from everything) and left the computer alone for a while.

Hello all

Just recently found T-Clock after years of using Dale Nurden's program.
I'm glad to see this effort going on as I had always hoped there would be enhancements made.
I use the functionality every day at both home and work.
-MKappy (July 02, 2010, 01:27 PM)

I'm glad to hear you've found it to be useful.

I'd like to offer some enhancement ideas that may or may not have already been suggested.

1 Allow what is displayed when the mouse hovers over the date/time in the system tray to be user selectable.
What I personally would select for example is to display the current months calendar.
This allows you to quickly see the month without using up one of your mouse click options

So popup calendar on mouse-over - The system global mouse-over timeout may cause performance issues (annoying response lagg) with/for that - But I'll look into it as it does sound rather handy.

2 Add right click capability to match the left click.
Note: Middle button on Win 7 Pro brings up "document flip" so we really only have 2 copies not 4 available.

My motivation for this is to give us at least one if not two additional copy strings.

Example use case:
--- Left Single Click - copy the current date time as a Prefix - e.g. yyyy-mm-dd_
--- Left Double Click - copy the current date time as a Suffix - e.g. _yyyy-mm-dd_hh"hrs"_mm"mins"
--- Right Single Click - copy in a user defined string - e.g. an email address, [email protected]
--- Right Double Click - copy in a user defined string - e.g. an email address, [email protected]

I'm not sure if the context menu popup will share well with the single right click event, but yes I am pondering alternatives for the now basically useless middle button/wheel click events.

3 Auto Rename file for file drag and drop?

This might be possible now but it's beyond my knowledge of how one would set this up.

The idea here would be to rename a dropped file to have a predefined user date/time string appended as a prefix or suffix before the file extension.
This might be the same as the single click option for example or perhaps yet another string specifically for this purpose.
For example:
   Original file name: Draft_ideas.doc
   Suffix Drag drop results in: Draft_ideas_2010-07-02_02hrs_07mins.doc
   Prefix Drag drop results in: 2010-07-02_Draft_ideas.doc

That certainly sounds worth looking into.

4 Drag and drop the clock ?

I've got no idea if this is even remotely possible....
What if you click down on the date/time in the system tray and drag and drop it?
Could this be made to paste a string?

I hope to one day get modern coding skills back up to date and join you all as contributing developers.

Thanks again for your efforts

Mark

I'm not sure we really need that many roads-to-Rome ... But, I may explore that later.

kronckew · « **Reply #172 on:** July 14, 2010, 01:44 PM »

just a quick suggestion, came here to see if there were any updates since i installed tc 2010 for x64 in june. i note that in the 'about' tab in the properties it does not mention a version no., the current download in post 1 has an exe file date 3 days later than mine, but the internal version number compiled into it is the same, and appears to bear no connection to the history. could you pls. add a date next to the versions in the history so we know when you compiled or released it, and/or put the version no. corresponding to the history lsit in the 'about'. thanx for listening. great program anyway, working fine in win7 x64 ultimate so far.

Stoic Joker · « **Reply #173 on:** July 16, 2010, 10:26 PM »

@kronckew - Build # added to about screen.

Okay, as luck would have it, my brother who just moved down here and is staying with us for a while has a 42" TV with a PC input. This gave me a much better test platform for the High DPI bugg. So...

Monitor: 42" Toshiba 1080p HD TV
OS: Windows 7 Professional
Resolution: 1920x1080
DPI: 150

Dialog Position: Where it Belongs... (Finally!)

In case anyone is wondering, the origional code was actually correct, I just needed to add the DPI aware option to the manifest file - which required VS2010. *Sigh* ...I really liked VS2005 better.

Only (other) down side at this point is I'm not sure if/how well it will run on Windows 2000 after being compiled with MSVS2010.

On a brighter note, I can finally get on with some of the other ideas/suggestions that have been mentioned/discussed/requested above.

cranioscopical · « **Reply #174 on:** July 17, 2010, 05:03 PM »

Well done!