[Sovled] Win32 C++ - Child Windows
-
Working on a Win32 C++ (non-MFC) application and I've run into an issue that I can work around but from reading the MSDN documentation I shouldn't have to do this. I'm under the impression that a child window for example:
CreateWindowEx(WS_EX_CHIENTEDGE,
TEXT("LISTBOX"),
TEXT("DEVICES"),
WS_CHILD | WS_VISIBLE | ...
10,10
mainWindowHandle,
(HMENU)IDC_DEVICELISTBOX,
mainWindowInstance, NULL)should pass all messages to its parent message queue and should be processed in its parent's WndProc callback message? This does not function like this in my application so I have to use "GetWindowLong" and "SetWindowLong" to define a callback message for each control child window. I've seen a lot of examples but I'm still not clear if my application is working as expected or if I'm just stressing out over nothing. Thanks for any help in advance.
-
Working on a Win32 C++ (non-MFC) application and I've run into an issue that I can work around but from reading the MSDN documentation I shouldn't have to do this. I'm under the impression that a child window for example:
CreateWindowEx(WS_EX_CHIENTEDGE,
TEXT("LISTBOX"),
TEXT("DEVICES"),
WS_CHILD | WS_VISIBLE | ...
10,10
mainWindowHandle,
(HMENU)IDC_DEVICELISTBOX,
mainWindowInstance, NULL)should pass all messages to its parent message queue and should be processed in its parent's WndProc callback message? This does not function like this in my application so I have to use "GetWindowLong" and "SetWindowLong" to define a callback message for each control child window. I've seen a lot of examples but I'm still not clear if my application is working as expected or if I'm just stressing out over nothing. Thanks for any help in advance.
-
Working on a Win32 C++ (non-MFC) application and I've run into an issue that I can work around but from reading the MSDN documentation I shouldn't have to do this. I'm under the impression that a child window for example:
CreateWindowEx(WS_EX_CHIENTEDGE,
TEXT("LISTBOX"),
TEXT("DEVICES"),
WS_CHILD | WS_VISIBLE | ...
10,10
mainWindowHandle,
(HMENU)IDC_DEVICELISTBOX,
mainWindowInstance, NULL)should pass all messages to its parent message queue and should be processed in its parent's WndProc callback message? This does not function like this in my application so I have to use "GetWindowLong" and "SetWindowLong" to define a callback message for each control child window. I've seen a lot of examples but I'm still not clear if my application is working as expected or if I'm just stressing out over nothing. Thanks for any help in advance.
A bit of correction: Each thread has a message queue and each window belongs to the thread that created it. When you send a message to a window then the message is (automatically) put into the message queue of the thread that owns the window. The message will be passed to the window by the owner thread when it decides to get a message from its message queue and decides to dispatch it (EDIT: a bit of correction here: sent messages and some other messages are handled specially (like WM_QUIT/WM_PAINT) and/or out of order of the queue). A child control sends most of its commands/notifications (not window messages!!!) to its parent window and these are automatically put into the owner thread of the parent window (the child window has nothing to do with the owner thread of the parent window and the message queue of the owner thread, that is handled by the system automatically). Only a few specific "messages" (commands/notifications) are passed to the parent window, the rest (most) of the messages are processed by the window proc that belongs the the class of the child control. The "notifications" and "commands" that are passed to the parent usually arrive as WM_COMMAND and WM_NOTIFY messages to the window proc of the parent window. (There are a few exceptions, like WM_CTLCOLOR...)
-
A bit of correction: Each thread has a message queue and each window belongs to the thread that created it. When you send a message to a window then the message is (automatically) put into the message queue of the thread that owns the window. The message will be passed to the window by the owner thread when it decides to get a message from its message queue and decides to dispatch it (EDIT: a bit of correction here: sent messages and some other messages are handled specially (like WM_QUIT/WM_PAINT) and/or out of order of the queue). A child control sends most of its commands/notifications (not window messages!!!) to its parent window and these are automatically put into the owner thread of the parent window (the child window has nothing to do with the owner thread of the parent window and the message queue of the owner thread, that is handled by the system automatically). Only a few specific "messages" (commands/notifications) are passed to the parent window, the rest (most) of the messages are processed by the window proc that belongs the the class of the child control. The "notifications" and "commands" that are passed to the parent usually arrive as WM_COMMAND and WM_NOTIFY messages to the window proc of the parent window. (There are a few exceptions, like WM_CTLCOLOR...)
Not confusing at all! I think things are getting clearer. This is my main initial confusion. Window Procedure A window procedure is a function that receives and processes all messages sent to the window. Every window class has a window procedure, and every window created with that class uses that same window procedure to respond to messages. The system sends a message to a window procedure by passing the message data as arguments to the procedure. The window procedure then performs an appropriate action for the message; it checks the message identifier and, while processing the message, uses the information specified by the message parameters. I think the key confusion for me is what Windows considered a "CLASS". pasztorpisti, thanks again but can you clarify something for me? When you say "(not window messages!!!)" your not talking about "WM_*" messages but messages that are specific to a class like "BM_*", "LB_*", "CB_*", and ...?
-
Not confusing at all! I think things are getting clearer. This is my main initial confusion. Window Procedure A window procedure is a function that receives and processes all messages sent to the window. Every window class has a window procedure, and every window created with that class uses that same window procedure to respond to messages. The system sends a message to a window procedure by passing the message data as arguments to the procedure. The window procedure then performs an appropriate action for the message; it checks the message identifier and, while processing the message, uses the information specified by the message parameters. I think the key confusion for me is what Windows considered a "CLASS". pasztorpisti, thanks again but can you clarify something for me? When you say "(not window messages!!!)" your not talking about "WM_*" messages but messages that are specific to a class like "BM_*", "LB_*", "CB_*", and ...?
You are right. Classic window messages (like WM_PAINT, WM_SIZE, ...) are all processed by the window proc of the control itself (that is window class specific). Specialized child windows (controls like Button, Edit, ...) are designed that they send only a few messages to the parent window (like WM_COMMAND message when the user presses a button, and WM_NOTIFY with control specific struct pointer). I guess this design was created because back in the old days people wrote their programs in procedural languages (C, Pascal) and in that case it is more comfortable to write just one windowproc for your window and to handle all child control messages there instead of writing a lot of window procs for all buttons, edit boxes, and so on... If you think about it, most of the core windows API is also a C interface. The irony here is that today GUIs are mostly built with object oriented GUI frameworks where one control is one object (I'm not talking about MFC here, that is at most 1/3 object oriented, Qt is a much better example). Such a framework needs to have/handle all control specific messages/notifications in the object associated with the control. For this reason the window specific implementation of such a framework usually delegates the handling of child control speicific messages from the parent object to the child object. Later the programmer usually registers an event handler into the object of the child control. You also need all control specific messages in the object associated with the child control when you want to write reusable specializations of some windows-builtin child controls (like static or edit).