Version 1.2, 08-05-2003:
------------------------

- Bugfix: Dragging the windows around the screen should no
longer have a strange repaint problem on some systems,
unless the system is dog-slow.

- Better graphics for Doublesize skin, courtesy
CharcoalGray99 and Rob Voisey.

- Bugfix: Double-click-and-hold no longer behaves strangely.

- Bugfix: When -minimized is on the command line or when
Start Minimized is in the configuration, changing the
skin no longer causes the program to re-minimize.

- Side Effect: When the application is minimized, changing
the skin makes it un-minimize. This is good, it lets you
see the skin you changed to.

- Fix Deferred: Switching to an incorrect skin or "blank"
might (depending on what the hard disk looks like at the
time) leave the current skin as-is instead of reloading
the default skin. Not easy to fix... and rather a minor
issue anyway. I could theoretically put up an error box
if you get the skin wrong, but I hate modal error boxes.
I'd rather just have the lack-of-a-skin-change be your
clue that you got it wrong. A commercial product would
have an error box or a CommonDialog for selecting a skin,
but I'm not ready to invest that kind of time in this yet.

- Dual Monitor support seemed to work, so it's no longer
labeled as 'Experimental' in the configuration screen.
Note that this will allow the application to be placed
completely off-screen and its position 'saved' that way.
So if you can't see the application, right-click on the
systray icon and deactivate dual monitor support.

- Fix Deferred: Less-than-24-bit screens, RGB hit tests for
skinned buttons don't work. Can't easily support this
without rewriting the way I make skins. If you really
*need* this application to work for you on a 16-bit
screen, contact me and I'll see what I can do.

- Bugfix: ImageGrabber no longer consumes 99 percent CPU
time in Task Manager when idling (when the app is
minimized to the system tray).

- Bugfix: Screen image updates no longer freeze when you
hold down a command button. In theory, this lets you see
the results of a long-press as it's happening rather
than having to guess. However, I've got notes in my code
that it might screw up the responsiveness of the
right-click menu. The image updates are supposed to
freeze when the right-click menu is up. If you can
reproduce a situation where the right-click menu is up
and the image updates are continuing and you can't get
the menu to respond, let me know.

- Feature Addition: Always on Top.

- Feature Addition: Alpha transparency. Only works on
Windows 2000 or later.

Return Values
If the function succeeds, the return value is the requested 32-bit value. If the function fails, the return value is zero. To get extended error information, callGetLastError.

but when I right click on the face to see the configuration menu, CPU usage drops below 5%. (that's with only a right-click, nothing else!)

is this after loading the release you just released to fix the transparency issue, or the release you started the thread with?

That's because it's not working so hard trying to constantly load up and draw the screens over and over again. As soon as the screen updates pause, so does the CPU usage.

Is there a way the process could be spawned at 'below normal' priority? That way she'd be pre-empted by most everything.