Callback procedures in Child Windows
Do you have to have a separate callback procedure for each window you create? In other words, if I have a main window with callback WinProc, and then create a child window (About Box), do I have a separate callback that handles events for the child window, or can I use the main WinProc to capture those events?
So, let me clarify my question as I have been experimenting. Do most created child windows have their own callback procedure? Or, are the child window events captured in one main callback procedure? I experimented by only having one callback, so I have conditionals on which windows handle is submitting the message. That works fine. Lots of conditions, but one main processing point.
The problem I was seeing/having experimenting with multiple window definitions and callbacks is that I was having trouble Destroying Child Windows properly, and other weirdness, without passing global status flags so that the main window callback knew what had happened with child windows. I'm sure it is fixable and it's a coding problem, but I wondered how the majority of coders do it?
The problem I was seeing/having experimenting with multiple window definitions and callbacks is that I was having trouble Destroying Child Windows properly, and other weirdness, without passing global status flags so that the main window callback knew what had happened with child windows. I'm sure it is fixable and it's a coding problem, but I wondered how the majority of coders do it?
To my understanding, the window callback procedure (
You specify the
Nonetheless, it is possible to change the
Windows of different classes naturally have different window callback procedures – assuming that different classes were registered with distinct window callback procedures. I believe that, technically, it would be possible to register multiple classes with the same window callback procedure. But is that a good idea?
It probably depends ;-)
WNDPROC) is a property of the window class.You specify the
WNDPROC when you call the RegisterClass() method to register your window class. Consequently, all windows of the same class also share the same WNDPROC, by default. You can differentiate individual windows by the HWND parameter that is passed to the callback.Nonetheless, it is possible to change the
WNDPROC of a specific window, by calling SetWindowLong() with nIndex set to GWL_WNDPROC. So each window can have its own separate WNDPROC. But then you must pass on all messages that you did not process in the "new" window procedure to the "old" one, via CallWindowProc()!Windows of different classes naturally have different window callback procedures – assuming that different classes were registered with distinct window callback procedures. I believe that, technically, it would be possible to register multiple classes with the same window callback procedure. But is that a good idea?
It probably depends ;-)
Last edited on
Here are some tutorials I've recently posted that would answer your question - which is an important and foundational one.
http://www.objreader.com/index.php?board=19.0
A Window Class is a Class. It may be C based, but is nonetheless a class (technically a struct, of course, but in the broader sense of OOP, it qualifies under the concept 'class'). Applications of any size or complexity naturally have many objects - each with specific purposes and duties. Speaking in such general terms - try to answer your own question.
A GUI app (of any size or complexity) will have many objects - likely GUI objects. It stands to reason that seperate Window Procedures should be written for each GUI object.
Attacking the issue from another angle, think of typical child window controls such as edit controls, buttons, and listboxes. I can absolutely guarantee you that each has it's own Window Procedure (and it's address is obtainable through GetWindowLong()/GetWindowLongPtr().
At the above link, I believe it's my Form5 example that shows multiple application windows and multiple Window Procedures. In fact, I believe one of the windows is a Dialog Box which I built 'low-level' without Windows 'Dialog Engine'. A bit unusual in that a seperate 'message pump' for the dialog is used.
The alternate situation is multiple windows of the same class. That can be seen at the above link in my Form4 example.
http://www.objreader.com/index.php?board=19.0
A Window Class is a Class. It may be C based, but is nonetheless a class (technically a struct, of course, but in the broader sense of OOP, it qualifies under the concept 'class'). Applications of any size or complexity naturally have many objects - each with specific purposes and duties. Speaking in such general terms - try to answer your own question.
A GUI app (of any size or complexity) will have many objects - likely GUI objects. It stands to reason that seperate Window Procedures should be written for each GUI object.
Attacking the issue from another angle, think of typical child window controls such as edit controls, buttons, and listboxes. I can absolutely guarantee you that each has it's own Window Procedure (and it's address is obtainable through GetWindowLong()/GetWindowLongPtr().
At the above link, I believe it's my Form5 example that shows multiple application windows and multiple Window Procedures. In fact, I believe one of the windows is a Dialog Box which I built 'low-level' without Windows 'Dialog Engine'. A bit unusual in that a seperate 'message pump' for the dialog is used.
The alternate situation is multiple windows of the same class. That can be seen at the above link in my Form4 example.
Topic archived. No new replies allowed.