Goal: Get a real window (not a message box) up and understand every line of code I used. Then mess around with it a bit to increase my understanding of how all the parts work.
After reading through the section in the book and a few examples on other sites I found something I was confused about. There were many data types here that I had never heard about before. Since I wasn't about to call a function that had a return type that I didn't understand I started poking around.
I am sure most of you already know what I found, however I am writing this in hopes it could help someone with the same questions as me. Turns out there is something called Hungarian Notation. You can read more about it here. Basically for my purposes it means that the h means that it is a handle which is a pointer. This cleared up some questions.
At first I wondered why they did this. Most of these things seem to be types that already exist renamed. I guess it is for two reasons:
1) Clarity, so you know what a variable is used for
2) They can change what these types mean and we don't all have to change our programs. Lets them change Windows.
I don't know if these are the reasons. Just my guess (based on the reasons that I use type definitions myself)
I was still left with one type I had not heard of: ATOM.
ATOM RegisterClassEx(CONST WNDCLASSEX *lpWClass);What the heck is ATOM? Well thanks to the WIN32 SDK Help I have an answer:
Quote:In Microsoft(R) Windows(R), an atom table is a system-defined table that stores strings and corresponding identifiers. An application places a string in an atom table and receives a 16-bit integer, called an atom, that can be used to access the string. A string that has been placed in an atom table is called an atom name.
So my guess here (could be totally wrong) is that all of my class information is stored in an atom table and the integer is returned so Windows knows how to find it. Couldn't really find anything on this so if it works another way I'd be interested in knowing.
Well once I got all that cleared up the code was pretty straight forward. Well except one small problem. Turns out I had typed CreateWindowEX instead of CreateWindowEx. So I spent about an hour trying to figure out what #include or
library I had missed. Searching MSDN and previous posts here and banging my head against the keyboard. Finally in frustration I posted for help, thanks to EasilyConfused for spotting my typo. Moral of the story: Assume its a typo first.
So I got the program up and running and BAM! I have a window. While reading the chapter and typing in the code I noticed that WndProc (the event handler) offered a possibility for having some fun (fun being relative).
The message cases all start with WM_, a quick search on the Win32 help shows that there are a LOT of possible messages available, including one for the left mouse button being pressed. So I added the following code to WndProc:
case WM_LBUTTONDOWN: MessageBox(NULL,"\tYou Pressed a Button", "Button Notice", NULL); return 0;Nothing to be proud of but it works and I have hardware interaction with my windows application from an input device (the mouse). I am not sure that this is the way that it is done in a game but at least I have interaction.
It looks like my next step will be learning something called WGL (haven't read the section yet just saw the title)and perhaps drawing something on the screen.
Good to see you are making progress at a nice sensible rate with the Win32 API. It is a horrendously complex and hard to use API (IMHO) and I think you are bang on the nail in taking such small steps and making sure you have a good understanding before moving on.
It's so bad because it is all C-legacy stuff and the whole world and his dog seems to think no-one should learn Win32 API anymore in favour of C# and Windows Forms, but personally I think there is a lot of benefit in learning all this stuff, even if only to give you a massive edge if you do move on to the managed alternatives in the future.
Handling WM_LBUTTONDOWN like that, by the way, is exactly how I believe most games would work under the hood. Microsoft are now recommending against using DirectInput for keyboard and mouse handling and suggest dealing with the messages directly, as you have done. The only painful part about these messages is decoding the parameters passed to them via the wParam and lParam but it is not too bad, just make sure you've got a nice easy shortcut to the SDK docs somewhere you can always find it.
Best of luck. I get a real (masochistic) kick out of Win32 API programming so I'll be keeping an eye on this journal.