Is it possible for a child control to get informed if the active state of the parent was child? Without implementing anything at the parent?
Somethig like ON_NOTIFY_REFLECT???
No. Reflection works only for messages sent to the parent for the control that are usually captured by the parent. AFAIK this way is also only implemented for WM_COMMAND and WM_NOTIFY messages.
But what is the problem when you just forward the message to the child control.
Another way would be a classic generic subclass that may help you to capture the WM_ACTIVATE message.
Sometimes a timer does the same job, that just checks the current state of the application.
Depends on what you want to do...
Related
I'm trying to create a child window that always fills its parent client area and is always the same size and position. My temptation is to call GetWindowLongPtr on the parent, hook its window proc and intercept the WM_SIZE and WM_MOVE messages and resize/move my child in response to those messages.
However the project I'm working on is written in WTL and I'm tempted to believe there's a WTL solution that is more graceful/savvy than this brute force interception of messages. I'm not very familiar with WTL and the documentation is sparse at best. I'm considering using CHAIN_MSG_MAP_MEMBER but I'm unsure how to determine when my handler for WM_SIZE would be handling the parent's message or the child's own WM_SIZE messages
I'd like the change to the parent class to be as nonintrusive as possible... perhaps a single line in the parent's message map. Also the parent can be any window, not just top level windows.
Use CDialogResize class. It is declared in atlframe.h. You can find some examples in the internet. This in the one of example.
I have an edit control. In the parent window I'm listening a WM_COMMAND message. But my control doesn't send it on change. Moreover, when I'm watching messages with Spy I can see only different keyboard messages on the edit control itself and the only message in the main parent window is WM_CTLCOLOREDIT.
P.S.: The only interesting thing I'm doing - I'm creating an edit with HWND_MESSAGE parent and assign a parent later with SetParent();
For an edit control, notifications are sent to the original parent of the control. That is, in your case, the message only window.
In a comment to a similar question Raymond Chen says:
Many controls cache the original parent. Not much you can do about it.
You may be best postponing creation of the edit control until you have created its parent.
I am writing a fairly simple wrapper around Win32 controls/dialogs/windows.
The issue I have is that ListBox's and ComboBox's seem to behave rather differently.
In the base Widget class that I am inheriting from, I override the existing WNDPROC for the control and then handle messages in the new WNDPROC, primarily promoting them to boost::signal events.
The issue is that, while ComboBox's WndProc receives the CBN_SELCHANGE - as expected - ListBox's WndProc does not receive the LBN_SELCHANGE command.
I realize that the dialog/window that owns the control will likely receive this, but I've kind of gone down this rabbit hole already and it feels like a pretty neat solution. Need I back out and have the owners of the controls handle the WM_COMMAND messages (and from there promote it to an event on the control itself).
This is a learning exercise, so please don't remind me about MFC or comment on the value of doing this.
Notification messages are typically sent to a control's parent. Presumably all the windows (i.e. both parent windows and controls) are using the same window procedure? In this case the usual solution is: in the notification handler in your window procedure check if the notification came from the current window. If it did, raise an event; if it didn't resend the message back to the control it came from (where it will be raised as an event).
I've written a simple GUI using WTL:
I've got everything figured out as far as setting up the window is concerned, and also wired up the menus and such to call whatever I wish. But I need to know when, for example, someone checks one of the checkboxes in the list view, or when someone clicks on a button.
Do these child windows send a message to the main window notifying of the state change, and is that notification generally consistent between child window types?
Child notifications are typically sent to the parent window in the form of WM_NOTIFY or WM_COMMAND messages.
Some child notifications are common across most control types (e.g. NM_CLICK and NM_CUSTOMDRAW), but in general you'll need to look at the notifications reference for each control type on MSDN to see what's available. To start, the reference for listview notifications are here and the button notifications are here.
I always struggle to keep all these macros straight in my head. Is there an easy way to remember them, and which to use in a given scenario?
Specifically, does one of these allow a dialog to intercept/detect messages to child control windows? e.g Can the dialog register an interest when IDC_MY_CONTROL gets a WM_PAINT message?
ON_NOTIFY handles WM_NOTIFY messages. ON_CONTROL handles WM_COMMAND messages from controls. ON_CONTROL_REFLECT is for handling messages sent to a parent from the child class.