Concept of WNDCLASSEX, good programming habits and WndProc for system classes

Question

I understand that the Windows API uses "classes", relying to the WNDCLASS/WNDCLASSEX structures.

I have successfully gone through windows API Hello World applications and understand that this class is used by our own windows, but also by Windows core controls, such as "EDIT", "BUTTON", etc. I also understand that it is somehow related to WndProc(it allows me to define a function for it)

Although I can find documentation about this class, I can't find anything explaining the concept.

So far, the only thing I found about it was this:

A Window Class has NOTHING to do with C++ classes.

Which really doesn't help(it tells me what it isn't but doesn't tellme what it is). In fact, this only confuses me more, since I'd be tempted to associate WNDCLASSEX to C++ classes and think that "WNDCLASSEX" represents a control type . So, my first question is What is it?

In second place, I understand that one can define a WndProc in a class. However, a window can also get messages from the child controls(or windows, or whatever they are called in the Windows API). How can this be?

Finally, when is it a good programming practise to define a new class? Per application(for the main frame), per frame, one per control I define(if I create my own progress bar class, for example)?

I know Java/Swing, C#/Windows.Form, C/GTK+ and C++/wxWidgets, so I'll probably understand comparisons with these toolkits.

Answer 1

A window class describes the properties that will be used for all instances of that class. As well as colors, icons and so on, one of these properties is the Window Procedure. This is the callback function that is responsible for handling all messages from the system and processing them as necessary.

While unrelated the concept is analogous to C++ classes - One piece of code defines the data and functionality of a class and there may be many instances of that class.

As a very rough example the "BUTTON" class WndProc translates a WM_LBUTTONDOWN/WM_LBUTTONUP sequence as a "click". During this sequence the WndProc will also paint the button in a "pressed" state as a response to the WM_PAINT message.

Where a window needs to communicate an action to a parent (e.g. a click) it sends messages as "notifications" or "commands". These messages are manually created by the child control and contain an identifier and any pertinent data.

The benefit of all this just by creating window (using CreateWindow) of the button class I get all this behavior automatically.

As well as the ones provided by windows I can also create my own windows that can be resued throughout my app. You must register at least one class for your main window (otherwise it would have no functionality so wouldn't be very interesting) but beyond that it is up to you.

It's quite possible to have applications that contain only the regular controls (buttons, listviews, progress bars) but there are times where you may want to create a custom class. This could either be to encapsulate specific behavior, or because you wish to use many instances of that control through your program.

For example if the UI of my application should need images of giraffes that spin when the mouse is over them I can write the code to do this in a WindowProcedure and register that as a new class ("SPINNYGIRAFFE"). The rest of my application just creates windows of the "SPINNYGIRAFFE" class and everything just works.

Answer 2

How can this be?

The child controls(these are also windows) send a message to their parent window, Windows (note the capitilization, this is the OS) knows the current WndProc of that window and calls it.

When is it a good programming practise to define a new class?

Every window must have a class, thus unless an existing class exists for your window, you must define a new class. You likely will need to define classes for all your own top level windows, but not for any controls (built in classes for these) or for dialogs since the dialog box APIs in Windows use another buildin class.

Answer 3

Everything is on MSDN

Can't you read ?!

Answer 4

Pointless remark greg

If someone looking for some help understanding msdn doc and people are nice enough to spend a few time answering then I definitely don't understand why you writes such bull shit.

Are you (like me) a "someone is wrong on the net" freak ?! :)