Okay, I've done the following so far:

'- Bugfix: Dragging the windows around the screen no longer
' has a strange repaint problem on some systems
'- Better graphic for remote on Doublesize skin.
'- Bugfix: Double-click-and-hold behavior 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.

Currently am working on:

'Awaiting Bugfixes:
'- FIX: Less-than-hicolor screens, RGB hit tests don't work?
'Awaiting Feature Additions:
'- Requested feature: Always on top
'- Requested feature: Alpha transparency for non focused window

I ran into a thorny issue with the hicolor screens. What's wrong is that when VB loads up a bitmap (in this case the bitmap with the button hit tests) is downconverted to whatever bitdepth the current screen is. And there's not enough resolution in a 8, 15, or 16-bit-per-pixel screen for one easy color elemnt to represent different buttons. And even if I chose different levels for each color element as suggested elsewhere in this thread, then the actual values are going to be dependent on the video driver. Here's an example:

24 bit mode, difference in each value=10
0A 00 FF
14 00 FF
1E 00 FF
28 00 FF

16 bit mode, difference in each value=10
08 00 FF
10 00 FF
18 00 FF
29 00 FF

Note how the 16 bit video driver has random values that are not quite what I saved in the 24 bit file. And I can't, for example, do "If greater than 15 then it's the same as 20" because the value for 30 comes out to be 24 thanks to the screwy way the video driver has to average 8 bits down to 6 bits. And I don't even have a 15-bit mode in my video driver to test against for that. And also I can't predict exactly what a different video driver will do, so getting device-caps on the video card won't necessarily help.

So my options are:
-Throw out the easy way of skinning completely and go back to some kind of table-based system. Or keep the bitmap method and do 0/128/255 for each RGB value but I don't think that yields enough values for the remote's 24 buttons.
-Write code to read into the windows BMP format and get the stored pixels of the button-hit-test bitmap directly instead of loading it into an image and using GetPixel like I'm doing now.
-Just forget supporting lower-than-24-bit color altogether.

Who votes for that last one?