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.
Related
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...
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 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.
In .Net there is a feature called KeyPreview. How can I do this in WinApi. Maybe I don't necessarily need this but my hWnd has WM_KEYDOWN, but it does not receive it when my Text Box has focus. How can I achieve this?
Thanks
*Using pure Win32API...
is there an alternative, how could I handle the Text Box's WM_KEYDOWN?
You can try subclassing the edit control. Either "instance subclassing", to trap messages for only one window, or "global subclassing" to trap messages for all windows of that class (in your application, not system-wide).
The example here (http://msdn.microsoft.com/en-us/library/ms997565.aspx) shows how to subclass an edit control and trap the WM_GETDLGCODE message -it wouldn't be that difficult to change it to WM_KEYDOWN.
You may have problems previewing the keys used for dialog commands, e.g. TAB or RETURN, as they may be trapped higher up the food chain. You may need to look at changing WM_GETDLGCODE as well.
If you use MFC you can look at PreTranslateMessage (I am not sure regarding to PreTranslateMessage, but you can easily to verify whether to enough to override the function).
You can set keyboard hook.
There is no such a possibility in WinAPI to catch the messages belonging to controls in window procedure of parent window (although some exceptions exist).
What .NET basically does is that it routes all messages of all controls including their parent window to a single window procedure. Then it's easy to catch all the messages in one place.
This is your way to go - to set window procedures of all the controls into single procedure and there to catch all the messages
As window procedure also receives hwnd parameter, it's then also easy to determine the control to which the message belongs.