Messages

1

Developer's Corner / Re: Diff before commit

« on: November 08, 2010, 10:20 AM »

For me the diff before commit is the final approval step.
It is were I make sure of code quality - conformance to coding style and naming convention.
Make sure that any test code is removed.
Make sure I have tested all code paths.
Make sure that all changes correspond to something in the change description - even if it is just "review changes"
Make sure that all required changes have been done.

The only time I don't do the diff is if there is no decision in the change - such as adding in an update from an external source (e.g. updating to a later version of a 3rd party library.)

2

T-Clock / Re: T-Clock 2010 (beta - download)

« on: July 25, 2010, 05:30 PM »

As an experiment I added the DPI aware to the x64 version's manifest.
It now appears in the right place <added> and the calender appears on screen </added>.
But it isn't scaling correctly internally.

I have attached before and after images for the about, mouse, and quicky tabs - the others appear normal.
In the mouse tab the list of actions starts too soon so overlaps the controls for setting the actions.
In the quicky tab the list doesn't fill the remainder of the page.
The font in the tabs is smaller - so more fit on one line.
The label with the build information fits better but still wraps onto a second line and gets clipped.

3

T-Clock / Re: T-Clock 2010 (beta - download)

« on: July 25, 2010, 04:26 PM »

It is still appearing off screen, and still shows scaled coordinates to window spy. If I move it so the right edge is adjacent to the taskbar then with the mouse at the right edge of T-Clock's window the x screen position  is about 1400 but when i move it right is suddenly jumps to over 2000.

Man, I've tried everything I can think of trying to duplicate this to aviod picking on your hardware. But, I think we may need to explore that possibility. I had hoped that someone else with that type of setup would chime in to confirm or disprove the behavior ... but it seems it just the two of us stuck head-2-head. I'm debating on adding a (work arround) option to save last dialog position as a last resort.

Everything I try makes it worse, and the more I research this everything points at the origional code as being correct.

*Shrug* I'm stumped...

-Stoic Joker (July 22, 2010, 06:50 AM)

I think I have found what's wrong with the x64 version.
The two versions (x64, and x86) have different manifests. The x86 has both the sections that are in the x64 clock.exe but in the opposite order, and also has a third section that includes the dpiAwareness setting. So it looks like the x64 version isn't set as DPI aware.

4

T-Clock / Re: T-Clock 2010 (beta - download)

« on: July 20, 2010, 04:41 PM »

Well this one runs.
But it isn't any different - except there is extra text on the about page - but it wraps after the second - and 3/4 of the second line gets clipped off.

It is still appearing off screen, and still shows scaled coordinates to window spy. If I move it so the right edge is adjacent to the taskbar then with the mouse at the right edge of T-Clock's window the x screen position  is about 1400 but when i move it right is suddenly jumps to over 2000.

5

T-Clock / Re: T-Clock 2010 (beta - download)

« on: July 19, 2010, 01:27 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.

-Stoic Joker (July 16, 2010, 10:26 PM)

Murphy was so impressed by your fix he slipped a x86 version into the x64 folders so it doesn't work on my system.

6

T-Clock / Re: T-Clock 2010 (beta - download)

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

7

T-Clock / Re: T-Clock 2010 (beta - download)

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

8

T-Clock / Re: T-Clock 2010 (beta - download)

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

9

T-Clock / Re: T-Clock 2010 (beta - download)

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

10

T-Clock / Re: T-Clock 2010 (beta - download)

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

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.

11

T-Clock / Re: T-Clock 2010 (beta - download)

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

12

T-Clock / Re: T-Clock 2010 (beta - download)

« on: June 13, 2010, 07:07 PM »

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)

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)

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

1. //================================================================================================
2. //------------------------------+++--> Adjust the Window Position Based on Taskbar Size & Location:
3. void SetMyDialgPos(HWND hwnd) { //----------------------------------------------------------+++-->
4.         int wscreen, hscreen, wProp, hProp;
5.         int wTray, hTray, x, y;
6.         RECT rc, rcTray;
7.         HWND hwndTray;
8.  
9.   GetWindowRect(hwnd, &rc); // Properties Dialog Dimensions
10.   wProp = rc.right - rc.left;  //----------+++--> Width
11.   hProp = rc.bottom - rc.top; //----------+++--> Height
12.        
13.   wscreen = GetSystemMetrics(SM_CXSCREEN);  // Desktop Width
14.   hscreen = GetSystemMetrics(SM_CYSCREEN); // Desktop Height
15.        
16.   hwndTray = FindWindow("Shell_TrayWnd", NULL);
17.   if(hwndTray == NULL) return;
18.  
19.   GetWindowRect(hwndTray, &rcTray);
20.   wTray = rcTray.right - rcTray.left;
21.   hTray = rcTray.bottom - rcTray.top;
22.  
23.   if(wTray > hTray) { // IF Width is Greater Than Height, Taskbar is
24.           x = wscreen - wProp - 21; // at Either Top or Bottom of Screen
25.           if(rcTray.top < hscreen / 2)
26.                   y = rcTray.bottom + 21; // Taskbar is on Top of Screen
27.           else // ELSE Taskbar is Where it Belongs! (^^^Mac Fag?^^^)
28.                   y = rcTray.top - hProp - 21;
29.           if(y < 0) y = 0;
30.   }else{ //---+++--> ELSE Taskbar is on Left or Right Side of Screen
31.           y = hscreen - hProp - 21; // Down is a Fixed Position
32.           if(rcTray.left < wscreen / 2)
33.                   x = rcTray.right + 21; //--+++--> Taskbar is on Left Side of Screen
34.           else
35.                   x = rcTray.left - wProp - 21; // Taskbar is on Right Side of Screen
36.           if(x < 0) x = 0;
37.   }
38.  
39.   MoveWindow(hwnd, x, y, wProp, hProp, FALSE);
40. }

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.

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

1. if (rcTray.top > 0) {
2.     // tray at bottom
3.     ...
4. } else if (rcTray.left > 0) {
5.     // tray at right
6.     ...
7. } else if (rcTray.bottom < hscreen) {
8.     // tray at top
9.     ...
10. } else if (rcTray.right < wscreen) {
11.     // tray at left
12.     ...
13. } else {
14.     // error - tray is fullscreen
15.     return;
16. }

13

T-Clock / Re: T-Clock 2010 (beta - download)

« on: June 13, 2010, 07:51 AM »

Heh, now I am going to have to turn the house upside down to find all my forgotten Larson books. 

-haydut (June 13, 2010, 07:20 AM)

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

14

T-Clock / Re: T-Clock 2010 (beta - download)

« on: June 13, 2010, 07:45 AM »

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)

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

1. iW = GetSystemMetrics(SM_CXSCREEN); // Desktop Width
2.   iH = GetSystemMetrics(SM_CYSCREEN); // Desktop Height
3.  
4. /////////////////////////////////////////////////////////////////////////////////////////////////////
5.   hdc = GetDC(NULL);
6.        
7.   wscreen = MulDiv(iW, GetDeviceCaps(hdc, LOGPIXELSY), 96);
8.   hscreen = MulDiv(iH, GetDeviceCaps(hdc, LOGPIXELSY), 96);
9.        
10.   ReleaseDC(NULL, hdc);

-Stoic Joker (June 12, 2010, 09:01 AM)

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.

15

T-Clock / Re: T-Clock 2010 (beta - download)

« on: June 10, 2010, 05:23 AM »

I think the 8 point font looks OK.

With my curent 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.

<ADDED>
When it is partly off screen it is only off the right side - the bottom edge is in the correct place.

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.

16

T-Clock / Re: T-Clock 2010 (beta - download)

« on: June 07, 2010, 04:15 AM »

The 7.5 download includes a copy of 7.3.

Also in the first post it says known issues none - but should it not mention my problem with the properties dialog appearing off screen when DPI is set to more than 100% and the taskbar is on the right?

Some more information about it.
My screen is set to 2560x1600 (widescreen)
Where the dialog appears depends on the width of the taskbar - if it is minimum width then the dialog isn't visable, if it is very very wide then some of the dialog appears to the right of the taksbar, if it is set so that 10 notification icons fill one line then the left border and a very small part of the dialog appear under the taksbar.

17

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 30, 2010, 07:25 AM »

Actually I was thinking of alarms, not hourly chimes. The standard samples, and a lot of other suitable sounds, are so short as to be easily missed, but I don't want the alarm to repeat until cancelled.

-sagji (May 15, 2010, 02:07 PM)

Hm... Let me Mull that one over a bit - I got see how many worms come flying outa the can when I open it before comitting...

-Stoic Joker (May 15, 2010, 03:13 PM)

Okay, You win ... Alarms can now Chime the Hour.

-Stoic Joker (May 27, 2010, 09:59 PM)

I was only using striking the hour as an example, so would prefer something more flexible - such as a simple numeric.
Also when the alarm is specified using the 24 hour clock then at 6 pm it strikes 18 times not 6.

18

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 30, 2010, 06:41 AM »

Is this the map you are looking for?
http://msdn.microsof...ms647003(VS.85).aspx
Versions 7 and 7.2 have the same version no in the file (2.0.1.111).
I have a vague memory of VS2005 having an auto build no option somewhere - presumably in the linker options section.

-sagji (May 28, 2010, 09:14 AM)

Um, no. That function is used to pull the version info from a compiled binary for version validation. It actually is already being used in/by T-Clock to verify that the correct .dll version is being used.

But that won't help with automagically updating the build number at compiletime. I thought perhaps you knew of a compiler option or script that would auto update the code during the build process for the older project types - C# projects will happily increment the build number - But this ain't C#

-Stoic Joker (May 28, 2010, 05:57 PM)

What about these?
http://www.flounder....ng_build_numbers.htm
http://support.microsoft.com/kb/237870
http://www.codeproje...ion.aspx#xx1406378xx

19

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 28, 2010, 09:14 AM »

I have tested 7.2

The alarm crash has gone.

Is this the map you are looking for?
http://msdn.microsof...ms647003(VS.85).aspx
Versions 7 and 7.2 have the same version no in the file (2.0.1.111).
I have a vague memory of VS2005 having an auto build no option somewhere - presumably in the linker options section.

20

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 27, 2010, 08:58 AM »

I have downloaded the 0.7 release.

I still get a crash in x64 by going to the alarm tab and closing the dialog.

-sagji (May 26, 2010, 08:56 AM)

If you could export the T-Clock config from the registry and either post it or send it to me, it will be easier for me to resolve - If I can duplicate the crash.

-Stoic Joker (May 26, 2010, 05:55 PM)

Reg export for HKEY_CURRENT_USER\Software\Stoic Joker's attached, also I don't see the same problem in my x86 machine.

The about page doesn't give the version no, or date.

That's true, mainly because I've already got 4 places I have to manually update the build number (version tab of properties dialog) and I didn't want to add a fith that I knew I'd forget.

The best solution to that is for the app to read the information, put in by the build chain, from the exe.

21

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 26, 2010, 08:56 AM »

I have downloaded the 0.7 release.

I still get a crash in x64 by going to the alarm tab and closing the dialog.

The dialog still appears off screen.

The about page doesn't give the version no, or date.

I wanted to check I was running the new version so I tried the SyncOpt - this dialog also appears off screen, I also get an error saying "can't open SNTP.log"

22

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 17, 2010, 05:01 AM »

I changed my DPI setting to 100% (96 DPI) an the problem didn't occur, but strangely when I set it back to 150% it didn't recur until I restarted explorer - although normally it occurs all the time.

-sagji (May 16, 2010, 08:16 AM)

I do most of my testing With a Virtual PC running WindowsXP (Which makes for safer crashing) I set it to 150DPI, and discovered much of the T-Clock interface looks like crap that way. Are you seeing that also? But the Properties Dialog positioning remains (on screen) correct. Damn peculiar it is.

-Stoic Joker (May 16, 2010, 02:29 PM)

A lot of programs do look bad at high DPI settings but T-Clock looks fine. On the Windows 7 custom DPI dialog there is a checkbox for "Use XP style DPI settings" which in my case is unticked.

I have noticed a new problem. When the taskbar is set as transparent there are minor redraw artefacts. When I mouse over an Icon in a toolbar and move the mouse away there is a faint grey square round the icon. Also when a tooltip disappears there is a faint line round where it was, and when the transparency is changed the separator used between toolbars suffers a similar problem.
A screen shot would explain this much better - however the effect isn't seen in the screen shot - which also doesn't show the transparency at all.

That almost sounds like a driver issue - Vista had problems with stalling clock output (and etc...) when it was first released, but after a few MS updates the problem went away...Which is why I never looked into it. What OS and hardware configuration are you running?

------------------
System Information
------------------
Time of this report: 5/17/2010, 08:33:38
       Machine name: WOL-001
   Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7600) (7600.win7_gdr.100226-1909)
           Language: English (Regional Setting: English)
System Manufacturer: To Be Filled By O.E.M.
       System Model: To Be Filled By O.E.M.
               BIOS: Default System BIOS
          Processor: AMD Athlon(tm) II X2 250 Processor (2 CPUs), ~3.0GHz
             Memory: 6144MB RAM
Available OS Memory: 6144MB RAM
          Page File: 3028MB used, 9256MB available
        Windows Dir: C:\Windows
    DirectX Version: DirectX 11
DX Setup Parameters: Not found
   User DPI Setting: 144 DPI (150 percent)
 System DPI Setting: 96 DPI (100 percent)
    DWM DPI Scaling: Enabled
     DxDiag Version: 6.01.7600.16385 32bit Unicode

---------------
Display Devices
---------------
          Card name: NVIDIA GeForce 9500 GT
       Manufacturer: NVIDIA
          Chip type: GeForce 9500 GT
           DAC type: Integrated RAMDAC
         Device Key: Enum\PCI\VEN_10DE&DEV_0640&SUBSYS_604619DA&REV_A1
     Display Memory: 3311 MB
   Dedicated Memory: 495 MB
      Shared Memory: 2815 MB
       Current Mode: 2560 x 1600 (32 bit) (60Hz)
       Monitor Name: Dell 3007WFP
      Monitor Model: DELL3007WFPHC
         Monitor Id: DEL4016
        Native Mode: unknown
        Output Type: DVI
        Driver Name: nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
Driver File Version: 8.17.0011.9745 (English)
     Driver Version: 8.17.11.9745
        DDI Version: 10
       Driver Model: WDDM 1.1
  Driver Attributes: Final Retail
   Driver Date/Size: 4/3/2010 23:55:31, 11906664 bytes
        WHQL Logo'd: n/a
    WHQL Date Stamp: n/a
  Device Identifier: {D7B71E3E-4500-11CF-7B5C-4D401FC2C535}
          Vendor ID: 0x10DE
          Device ID: 0x0640
          SubSys ID: 0x604619DA
        Revision ID: 0x00A1
        Video Accel: ModeMPEG2_A ModeMPEG2_C ModeVC1_C ModeWMV9_C
       D3D9 Overlay: Supported
            DXVA-HD: Supported
       DDraw Status: Enabled
         D3D Status: Enabled
         AGP Status: Enabled

23

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 16, 2010, 08:16 AM »

I changed my DPI setting to 100% (96 DPI) an the problem didn't occur, but strangely when I set it back to 150% it didn't recur until I restarted explorer - although normally it occurs all the time.

I have noticed a new problem. When the taskbar is set as transparent there are minor redraw artefacts. When I mouse over an Icon in a toolbar and move the mouse away there is a faint grey square round the icon. Also when a tooltip disappears there is a faint line round where it was, and when the transparency is changed the separator used between toolbars suffers a similar problem.
A screen shot would explain this much better - however the effect isn't seen in the screen shot - which also doesn't show the transparency at all.

24

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 15, 2010, 02:07 PM »

I have installed the beta 6, and have noticed the following.

The properties dialog doesn't appear on screen - but it is in the window list. It looks like it is appearing to the right of the taskbar - however as my taskbar is on the right of the screen this places it off screen.

-sagji (May 14, 2010, 07:36 AM)

Unfortunately I can't seem to duplicate this behavior. I moved my Taskbar to the right side of the screen, selected T-Clock properties and it popped up to the left of the Taskbar as expected. I tried this on both the left & right monitor of a dual monitor (Win7 x64) rig and on a WinXP single monitor rig. Do you perhaps have another desktop customizing app that in bay be confused by/conflicting with?

-Stoic Joker (May 14, 2010, 06:44 PM)

Windows 7 Home Pro x64 (UK) Single mointor (2560x1600) 144 DPI (150%), No extra apps. Sometimes it will show just the left border of the dialog on the right of the screen. The high DPI setting throws a lot of apps off, so a likely suspect.

Alarm sounds tend to be short - often so short as to be easily missed. It would be useful to specify the number of occurrences - so that the bell could ring say 6 times at 6 pm.

Ring 6 times at 6:00pm - You mean for the hourly chime? The plain alarms have the repeat option which will loop the sound file until dismissed. Also for alarms, you can throw any sound file at it .wav, .mdi, .mp3 ... The sounds that come with are just handy examples to play with (Okay, granted I love the ClockChimes.wav - But it isn't mandatory... ).

Now the 6 rings @ 6 Hourly Chime thing I like, I'd actually been toying with trying that ... So it looks like I will be now.

Actually I was thinking of alarms, not hourly chimes. The standard samples, and a lot of other suitable sounds, are so short as to be easily missed, but I don't want the alarm to repeat until cancelled.

25

T-Clock / Re: T-Clock 2010 (beta - download)

« on: May 14, 2010, 07:36 AM »

I have installed the beta 6, and have noticed the following.

The properties dialog doesn't appear on screen - but it is in the window list. It looks like it is appearing to the right of the taskbar - however as my taskbar is on the right of the screen this places it off screen.

If I open the properties dialog and go to the alarm page and press OK, or Cancel, - then after about 7 secs. explorer stops working. If instead I go to the clock text, or time format pages it works correctly.

The initial colour of the clock text is black - however the background is also nearly black, so the text is hard to read. While different OSs and themes vary I think that very dark backgrounds are much more common that very light ones, and that white would thus be a better default colour.

When creating an alarm it is difficult to enter the time by typing in the time. In the hour field the cursor is usually at the beginning (even after typing a digit) and thus any typed value is discarded. The minutes field is a little better - or I was just more experienced at the field's oddities.

Alarm sounds tend to be short - often so short as to be easily missed. It would be useful to specify the number of occurrences - so that the bell could ring say 6 times at 6 pm.