DonationCoder.com Software > T-Clock
T-Clock 2010 (download)
Stoic Joker:
Stoic Joker's T-Clock 2010
Application Name T-Clock 2010 VersionBuild 95 Short Description Highly Configurable Taskbar Clock Supported OSes Windows 2000/XP/2003/Vista/2008/7 32 & 64 bitWeb Page www.StoicJoker.com/TClock for general info. Download is still only available here.Download Link T-Clock 2010 (build 95).zip (703.66 kB - downloaded 84032 times.) Download Link T-Clock.20130503.f9f71075.7z (800.47 kB - downloaded 19273 times.) This is LonelyPixel's build containing Henriko's Week Number fixDownload Link White Tiger's GitHub Release Page System Requirements
* Win2k or Higher
* Memory 512KVersion History
* See BelowAuthor Stoic Joker - Has officially closed the project as of Saturday March 10, 2012Source Code Stoic Joker's Last (unreleased) Build 98 and then... Author WhiteTigX - Grabbed the released source code and reopened the project about a year later -+- LonelyPixel's GitHub Source Code Repository -+- White Tiger's GitHub Source Code Repository
Description
The Original TClock written by Kazubon in the early 90's was a popular classic that was on the edge of extinction when Windows started going 64bit. ...I simply chose not to let that happen.
Features
The Application's features.
Planned Features
Currently Open for Suggestions.
Screenshots
Screenshots of the Application.
Usage
Installation
Extract the .zip file (where you like) & run the program.
Using the Application
Hopefully this is all covered in the help file.
Uninstallation
Close Program & delete it.
Known Issues
Currently None - But I have faith that you guys will find something wrong with it... ;)
Version HistoryBuild 95 - Fixed Middle mouse button, and added the following features:
* PC Speaker alarm beep option (.pcb files)
* Locking Workstation Turns Off Monitor(s) (I Just Had to Try Doing This)
* System first week of year (used by popup calendar) adjustable via GUI
* Popup calendar options for 1, 3, or 12 month view (still needs work but is there)
* Added always on top option for calendar
* Added display am/pm as a/p, A/P, and /p optionsBuild 90 - Added Font Quality option to resolve the Fuzzy Font Bugg, and Bouncing Alarm windows. (details)
Okay... It's 12/23/2010, So I either have to either release this thing or change the name.
Beta 8.5 Windows 2000 Support Returns! - Thanks to MSVS2008
Beta 8 ... Same as first 8 Just repacked properly - Not a clue how I screwed that up.
Beta 8 - End of High DPI Dialog Position Bugg (also added build # to About Tab)
Beta 7.5 - Fixed Logic Error which caused Alarm AM/PM setting to be ignored.
Beta 7.4 - Added Display (ISO) Week Numbers on Calendar Option, Close Calendar on Lose Focus Option, Calendar Dialog now dynamically resizes at runtime if/as needed (toggle Week Numbers to see), Added Miscellaneous Tab to Properties Dialog to Adjust Above.
Beta 7.3 - Added Option to have Alarm Ring X Times
Beta 7.2 - Added Option to have Alarm Chime the Hour.
Beta 7.1 - More Fun with the Alarm Tab Crash Bugg
Beta 7 - Rework of Alarms Page Control behavior & etc... (see thread for details)
Beta 6 - This is a rough draft of the requested Time Synchronization feature (details to follow).
Beta 5.5 - More mucking about with the infernal Hotkeys (which should finally be be nailed down at this point)
Beta 5.2 - Fixed Loss of (HotKey) Focus Bugg
Beta 5 - Now with configurable HotKeys (I'm way to tired to post details)
Revised request for Ordinal Date Added (two ways) and also added Day-Of-Year.
OD = Ordinal Date UTC
Od = Ordinal Date Local
DOY = Day of Year in (001 - 366) Decimal format.
Help file has been updated with new options - but it looks like hell
Found this request for the Julian Date in an Email, so I tossed it in (Formatting Option JD)
Added Hotkey Options for Stopwatch, Add/Edit Timers, & Timer Watch dialogs
6. The Properties Dialog Mouse Tab Crash Bugg is gone - Thanks to a T-Clock fan that (also happens to be a programmer) has been working with me via Email for the past few weeks.
5. There is an EasterEgg of sorts for the Win2k folk that (is easy to find in the registry) allows TC2010 to make the Desktop Icon Text Labels transparent.
4. Registry info structure has been modified slightly (Simplicity/Testing purposes) so TC2010 will not use/modify the TC3 configuration data.
3. Taskbar transparency has been brought back because (Um...) it seemed like the thing to do at the time. It has been tested and works on all the above.
2. It is stable, and has been tested on Win2k/XP/Server2k3 x64/7 x64 without any Shell hangs/crashes/etc.
1. Okay, so I finally managed to end up with something stable enough to share with the rest of the class ... There are a couple of things to be noted however: This is alpha so it ain't perfect.
Okay, So I've been trying to get this project back off the ground for a few years ... and as of late ... That's really been starting to bug me. Missing source code issues aside ...(long story documented elsewhere)... I still had the partially branded project file from the web server to work with. That copy however (actually all of them in retrospect...) had an issue with MSVS 2005 SP1, which caused a quite consistent shell crash on load. I confirmed this by compiling the code with MSVS 2005 (no service packs) and it did indeed run just fine. Hence the conclusion that either SP1 or something that SP1 didn't like about my code was the culprit.
I have spent the better part of the last 3 days hammering on this in an attempt to render that particular bugg nice and dead. I have succeeded. Hence (in a mild fit of artistic rage...) I have decided to display said buggs still twitching carcase here ... on the odd chance that someone may need to drive a similar stake through one of its cousins:
--- Code: C++ ---oldWndProc = (WNDPROC)(LONG_PTR)GetWindowLongPtr(hwndClock, GWL_WNDPROC); // The x64 Bugg Was Here // SetWindowLongPtr(hwndClock, GWL_WNDPROC, (LONG)(LONG_PTR)WndProc); <--+++----<<<<< FAIL Code!!! SetWindowLongPtr(hwndClock, GWL_WNDPROC, (LONG_PTR)(LRESULT)WndProc); //----+++--> This Fixed IT!! SetClassLong(hwndClock, GCL_STYLE, GetClassLong(hwndClock, GCL_STYLE) & ~CS_DBLCLKS);
Will TC2010 make it to release? I don't know. But this is a hell of a lot closer to a good start then I've been in the past 4 years.
:D-Original Post
--- End quote ---
mouser:
ouch, thats a tricky one.
Go go TCLOCK!!
Stoic Joker:
ouch, thats a tricky one.-mouser (March 02, 2010, 06:30 PM)
--- End quote ---
Quite true, but it was at least almost (but not quite) twice as much fun as trimming your toenails with a chainsaw... :)
But seriously... Being that I have multiple project files pointing at the same source pool, the 32-bit compile complained about the pointer conversion (might cause data loss (yada, yada, yada...)). So I had to make it conditional at compile time, which ends up being this:
--- Code: C++ ---oldWndProc = (WNDPROC)(LONG_PTR)GetWindowLongPtr(hwndClock, GWL_WNDPROC);//==================================================================================#if defined _M_IX86 //---------------+++--> IF Compiling This as a 32-bit Clock Use: SetWindowLongPtr(hwndClock, GWL_WNDPROC, (LONG)(LONG_PTR)WndProc); //==================================================================================#else //-------------------+++--> ELSE Assume: _M_X64 - IT's a 64-bit Clock and Use: SetWindowLongPtr(hwndClock, GWL_WNDPROC, (LONG_PTR)(LRESULT)WndProc); #endif//================================================================================== SetClassLong(hwndClock, GCL_STYLE, GetClassLong(hwndClock, GCL_STYLE) & ~CS_DBLCLKS);
Which compiles cleanly (no errors or warnings) and runs without crashing on both 32 & 64 bit test machines.
f0dder:
What's up with having two casts (ie., (LONG)(LONG_PTR))? A single (LONG_PTR) ought to suffice, and work on both x86 and x64... reason for your old code crashing is probably that LONG is 32bit in both x86 and x64, so you get pointer truncation... whereas LONG_PTR is defined thus:
--- ---#if defined(_WIN64)
typedef __int64 LONG_PTR;
#else
typedef long LONG_PTR;
#endif
Yay for the moronic (or should we just say old-school-C-not-C++?) way the PlatformSDK is structured... *me barfs*. "Yeah, this is a pointer, except, like... it's an integer".
Stoic Joker:
What's up with having two casts (ie., (LONG)(LONG_PTR))? A single (LONG_PTR) ought to suffice-f0dder (March 03, 2010, 01:53 AM)
--- End quote ---
...Ought to, being the operative part :) ...But results in:
warning C4244: 'function' : conversion from 'LONG_PTR' to 'LONG', possible loss of data
However, Originally I was using a single Line of code for both (e.g. no compile time switching), so I needed to get that single line to work on/for both the 32 & 64 bit versions ...(and I insist on the code compiling with zero errors or warnings)... Which is I think how I landed there. Did I mention that this (or rather that 4 year ago project) was my baptism by fire in the pointer casting department.
I did some quick testing and now have:
--- Code: C++ ---oldWndProc = (WNDPROC)(LONG_PTR)GetWindowLongPtr(hwndClock, GWL_WNDPROC);//==================================================================================#if defined _M_IX86 //---------------+++--> IF Compiling This as a 32-bit Clock Use: SetWindowLongPtr(hwndClock, GWL_WNDPROC, (LONG)(LRESULT)WndProc); //==================================================================================#else //-------------------+++--> ELSE Assume: _M_X64 - IT's a 64-bit Clock and Use: SetWindowLongPtr(hwndClock, GWL_WNDPROC, (LONG_PTR)(LRESULT)WndProc); #endif//================================================================================== SetClassLong(hwndClock, GCL_STYLE, GetClassLong(hwndClock, GCL_STYLE) & ~CS_DBLCLKS);
...Which works on both 32 & 64 bit test machines. I could try running a few tests with just (LONG_PTR)(LRESULT) for both after work if you think it would be cleaner, but for now I'm just glad to be done abusing my server.
Only x64 machines I have are my main (Win 7) dev machine and my (Win 2k3 R2) domain controller. Repeatedly crashing the shell on the dev machine makes it impossible to keep my notes in order ... So I've been torching the shell over & over via Terminal Services for the last few days on the Domain Controller. Which says a lot for TS as in over 100+ shell hangs/crashes the original session never disconnected once and the box is still stable.
Disclaimer: (Kids do not try this at home) This is not considered a good practice or even recommended behavior... (It's actually rather stupid) ;)
Navigation
[0] Message Index
[#] Next page
Go to full version