Volume control, and introduction to windows programming.

[tom jacobs]

So Liah, you might wanna do the volume slider--

(Fordy and Liah: herein contains an introduction to Windows programming.)

The code for _drawing_ the volume slider _slot_ was already in there, just the bitmaps of the slot weren't loaded. I've added the few lines of code that loads them, so now we have that slider slot thing. So, we want an actual volume slider knob on that now. Here we go:

1) Read my just-improved architecture page: http://bluetunes.pbwiki.com/ArchitectureOverview . Some bits are might be a bit confusing, but just having read over it will be handy. Correct it if you find it vauge. Ask me if there's confusing bits, and I'll go more details there. There's not much there, so I wanna add things, but only things that help.

2) Right click in that top BlueTunes 2 folder and SVN Update. (When you update, make sure you update in that top level BlueTunes 2 folder, or you might get half an update). Compile and run it, and see the backing slider slot.

3) Right click in the top folder and TortoiseSVN->Show Log. (This thing is handy and fun.) Click revision 142. Doubleclick Main.cpp in the bottom pane to see what what I added to that file in that commit. Have a look through that diff in the cool diff viewer and see where I've added the bitmap loading code, and modified the drawing code.

4) So from this you can see that if you want to display some graphic ( e.g. pretty much anything ) on BlueTunes's face, you need to:

       a) Load the bitmap (once) at the start of the program.

Currently this is done by calling Windows' LoadBitmap( ) function to load a "resource", e.g. IDB_VOLUME_LEFT, into a "HBITMAP"; a Handle to a Bitmap.
A resource is some thing, bitmap, etc, that you tell VC to compile right into the EXE/DLL, and then the the EXE/DLL can load it via its #defined name, e.g. IDB_VOLUME_LEFT.
Handles:  Most everything with programming in Windows involves you creating things and then you getting a Handle of some sort to it.

       b) Do that funky "CreateCompatableDC/SelectObject/BitBlit" stuff to draw the bitmaps, everytime you get a WM_PAINT message.

For this we need the Windows programming introduction:
Handling messages:
Windows programs work by having Windows throw messages at your program and your program doing things when it gets the messages. A large portion of the code in most Windows programs is located in the "Windows just gave me a message" part of the program. ( the messageHandler functions in our case ).
So have a look at that Main::messageHandler. It's just one big switch/case, handing messages. The one we wanna handle to draw things is WM_PAINT. Windows sends this to us whenever we need to redraw our window; if it was just un-minimized; if some other window obscuring it just went away revealing ours, etc.* Windows passes us hWnd ( a handle ) which tells us which thing needs to be re-drawn. ( it even passes a rectangle of the part that needs to be re-drawn, but we ignore that and just draw the whole thing ). That's why we got the if( hWnd == topPanel ) line there. You can see the volume slider-slot drawing code is in that. So the volume slider-knob code would go just below the slider-slot drawing code there. Anyway, that's why its in there. You now know a good portion of Windows programming.
Oh, and the whacky logic I've got in that code with the volumeLeft etc places the volume slider in the right spot and sizes it nicely when you resize the window, so you'll have to have a look how that works to place the slider-knob. Ignore the minimode stuff, that's not done yet.
Drawing with BitBlt:
BitBlt means "BIT BLock Transfer". It copies a bitmap from one thing to another. Specifically, it copies stuff from a HDC ( again another handle ) to another HDC.
The thing we want to draw to in this case is called "ps.hdc".
But stupidly, we can't transfer from a bitmap directly, we have to create a new HDC, tell that HDC which bitmap it should be (using SelectObject), then transfer from that HDC. Yeah, freaky concept, keep reading.
So once we have that new HDC with our bitmap "selected into" it, we do the BitBlt from it, to ps.hdc, and bam, the graphic is displayed on our window.
That's the very quick introduction to all that HDC stuff, have a crack and understanding what each line of that volume slot-slider drawing code is doing. (SelectObject, etc)

So eventually want to abstract all this stuff so its not so messy. Ideally, it would be like:
Bitmap bm = LoadBitmap( IDB_VOLUME_LEFT );
DrawBitmap( bm, surface, x, y );
(And have the Bitmap class remember how big it is so we don't have to specify the sizes in the draw call. I did this in BT1, but not well.)

You gotta remember, the Library is from swoosh and is fantastically detailed on networking ( too much for us ) and files etc, but all the GUI stuff in it I have written recently, and thus there's not enough of it yet. Let's build that library up with lots of nice, useful abstractions. I often add TODOs to places and things that need abstracting away into nice functions in Library.

But just copying that existing slider slot drawing code is totally fine for now. It makes it much easier to abstract it having the things there in front of you that need to be factored rather than thinking of all the possible use-cases and going crazy and handing things that never will happen.

I'm big on not factoring things out that don't need it. It's that premature opt. thing in practice. Hey, just write it to get it working first. Then you can see what factors out nicely in the real world of actual running, useful code.

Oh, and check out "BlueTunes 2.rc" for the ready-to-load volume bitmap names.

So you'll probably want some time and then to get back to me with questions-- cya!

-----
* Windows ISN'T nice enough to remember what we drew to our window when something else covers it, because that was the sensible thing to do given 16mb of memory in 1995. Thesedays it is a different story, and OSX and Vista are nice enough to remember it. XP should have too, but XP is shit. Anyway.

--
Tom.

[tom jacobs]