topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Tuesday January 27, 2026, 12:22 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Recent Posts

Pages: prev1 ... 205 206 207 208 209 [210] 211 212 213 214 215 ... 246next
5226
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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.
1600x984-144DPI.jpg

I'm Stumped.
5227
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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?

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?!?
5228
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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.
5229
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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.
5230
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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.
5231
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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.
...Shit. :wallbash:

Well on a brighter note, I don't have to worry about the compiler error now as the code wouldn't have worked anyway...
 :hanged:
5232
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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.
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]
  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.

[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.
5233
Politics, is the Art of lying.

Technology is Science, not art.

We are the Peers Google's Jury is made of.

+1 for Eóin.
5234
I don't thing FireFox will work on a read-only drive - which is why I didn't suggest it - But I have used that trick (Drive with hardware write protect toggle) in a pinch.

Public Computers are like Public Toilets, once you sit down you're fully exposed to the last guy's mess.
5235
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker 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]
  1. // Native Coordinates * Logical Pixels / DPI
  2.   hdc = GetDC(NULL);  
  3.  
  4.   wscreen = MulDiv(iW, GetDeviceCaps(hdc, LOGPIXELSY), GetDpiX());
  5.   hscreen = MulDiv(iH, GetDeviceCaps(hdc, LOGPIXELSY), GetDpiY());
  6.  
  7.   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.
5236
Living Room / Re: Need to Convert .wav to .aac
« Last post by Stoic Joker on June 13, 2010, 10:05 PM »
Or better yet, just use FLAC.
I'm not sure if the phone will take a FLAC file, but I'll keep that option in mind.
5237
Living Room / Re: Need to Convert .wav to .aac
« Last post by Stoic Joker on June 13, 2010, 11:04 AM »
Last freeware version: http://www.xup.in/dl...e_I_final_2.6.0.zip/

Thanks folks, this one took care of it just fine (and on Win7 x64). Only hiccup was that converting from .wav to .aac directly destroyed the file (without error). But converting from .wav to .mp3 then to .aac worked fine.

So now when my phone rings, it sounds like (I think it should) a phone ringing not a spaceship, symphony, TV commercial, or zoo trip. :)

I even created a silent ringtone that I can assign to "Special" people that I wish to auto-magically ignore (hehe).
5238
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker on June 13, 2010, 09:36 AM »
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.

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++ [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. }

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.
5239
Living Room / Need to Convert .wav to .aac
« Last post by Stoic Joker on June 12, 2010, 07:47 PM »
I know I had a program that did this, but I can't find it. I'm trying to make a ring tone for my cell and aparently the phone (Nokia 6350) wants .aac files only.

Any suggestions?

tia
5240
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker on June 12, 2010, 05:51 PM »
Jibz obviously knows what I mean, although I wasn't thinking of a birthday type of reminder, though it would be able to be used for such a thing. I suppose it ought to be called a reminder rather than an alarm, though it would work as both.
Understood, however if I'm to add that type functionality as a target without modifying the project's (It's a clock) scope...we'll have to persist in calling it an alarm... ;)

When the alarm is activated, a dialogue pops up with some text that is input when the alarm/reminder is created. For example, I have to take a number of tablets each day, so each reminder could tell me which tablet I need to take. I used to use Atomic Alarm Clock, which is ideal, but doesn't work in Win x64.
Hm... Okay, small window, string of text, and a Jack Russel bounce function (honestly my only interest in this is the silly bouncing window) ...That sounds do-able.

First I gotta get the high DPI Dialog Position bugg figured out. but I'll toss this on the To-Do pile.


...Started with Bouncing Window, and my Mind Went Here:
FarSide.jpg
5241
Living Room / Re: WebCam Advice Needed
« Last post by Stoic Joker on June 12, 2010, 05:20 PM »
BTW: Since it was you who ultimately responded to your own post I guess that makes you DC's new webcam go-to guy huh?
 ;D

It does seem to appear that way, however I'll have defer to Cowboy Frank for any truly technical explanations.  ;)
5242
Living Room / Re: WebCam Advice Needed
« Last post by Stoic Joker on June 12, 2010, 11:14 AM »
So... Lacking any other input... I ran across this guy who had a quite comprehensive WebCam comparison going on; and went with his recommendation of the Logitech 2 MP HD Webcam Pro 9000

...Now given that I'm a cheap bastard - I opted for free shipping - So it'll be here next Thursday.
5243
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker on June 12, 2010, 10:34 AM »
Are there any plans for some sort of popup dialogue for alarms? I have no sound on my computers, so the alarm as it stands is no use to me. It'd be nice not to have to use another program.
That's what the blink option is for, it flashes the clock face when time is up. However if that's not enough of an attention getter, I could consider a system modal message box popup that bounces a bit. (Okay the bouncing may be a bit much, but I was just thinking that Jack Russel Terriers are impossible to ignore...:)). Would that work for you?

I was thinking more along the lines of being able to add a line or three of text that would pop up with each alarm, but I realise that may be beyond the scope of the T-Clock. As it happens, I just discovered "Stickies", another very useful little freeware program, which allows me to do what I need. Coincidentally, there's a setting in that program for the alarm to bounce.  :)

I must say the prospect is interesting ... Can you expand on that feature description a bit? And/or toss me a link to this Stickies program?
5244
T-Clock / Re: T-Clock 2010 (beta - download)
« Last post by Stoic Joker on June 12, 2010, 09:01 AM »
Are there any plans for some sort of popup dialogue for alarms? I have no sound on my computers, so the alarm as it stands is no use to me. It'd be nice not to have to use another program.
That's what the blink option is for, it flashes the clock face when time is up. However if that's not enough of an attention getter, I could consider a system modal message box popup that bounces a bit. (Okay the bouncing may be a bit much, but I was just thinking that Jack Russel Terriers are impossible to ignore...:)). Would that work for you?

I notice, on my computer at least, that the time and date seems to only use the top half of the taskbar, and if I increase font size, the bottom of the time and date disappears. I seem to remember I had this problem with TclockEX in Vista. I am using Win 7 Ultimate x64 now.
Clock Size & Text Position on the Clock Text Tab are for resizing/moving the clock's position in the taskbar. Al-tho admittedly it's a bit flaky at times. Try toggling the font size up or down (hit apply) and then back where you wanted it (hit apply) if the positioning adjustments don't seem to be "taking" properly. This is an old bugg that's on my To-Kill list that I just haven't gotten to yet.



I think the 8 point font looks OK.

Perfect, something that actually works... :)

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.

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

<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. The rest is just subtracting the dialog & gap sizes from the X & Y before tossing it to that point via MoveWindow(...)
5245
I'm still not sure about folding the thing over the back and using it like a spiral notebook. How do you keep the screen that would then be on the backside from getting scratched up?

Same rules as a dead tree edition I guess ... Be careful where you set it down so you don't get goo on the pages.
5246
Okay this might sound insane...but I do think it a language issue. (Bear with me)

I've been fighting with some .asp stuff and ran across an article (that I now can't find) that described simular character substitutions issues (as described above) during string compare operations when there was a language cross between A & B. I recognize some of the characters that swapped in majoMO's from the article.

May be check/validate the code-page used, or look into some of the runtime localization APIs.

Just thinking out loud here...I could be way off.
5247
If anything it's like going to the malicious folks out there and saying "Hey MS is about to fix this hole, quick hurry and exploit it before it's too late!"

Damn Straight! Google set the bar at "Don't be Evil" apparently just so that being malevolent was still available.

+2 for Microsoft's Side.
5248
Living Room / Re: Reasons to be Afraid of Driving in China
« Last post by Stoic Joker on June 11, 2010, 05:28 AM »
Maybe they have traffic signs (even though I do not see them) but nobody respects them. The right-of-way rule is universal, I think (except probably for people driving on the left side of the road).
Definition of Chinese Right-of-Way Rule:
  You have the right to be in the way, and other drivers have the right to hit you.
5249
Screenshot Captor / Re: The Print -Icon... do printout immediately
« Last post by Stoic Joker on June 10, 2010, 12:19 PM »
my thinking was, use the File menu if you want the print dialog.. use the quick toolbar button if you want a quick immediate printout.

Ah! True, that is a commonly used default behavior. I didn't know there was an A or B option to the print command/response available (I've never actually used/seen the program...  :-[ )

Carry on, I'll go sit in the corner. ;)
5250
Screenshot Captor / Re: The Print -Icon... do printout immediately
« Last post by Stoic Joker on June 10, 2010, 07:18 AM »
it's designed that way on purpose but i could make it an option.

That's probably the most user friendly route. In most office printing environments (which I deal with daily) there's a mono printer default and a color printer option.
Pages: prev1 ... 205 206 207 208 209 [210] 211 212 213 214 215 ... 246next