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).
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 derived the CHtmlEditCtrl, and want to be able to react when the control gets or looses its focus. However the standard MFC OnSetFocus and OnKillFocus handling routines are not being called.
I presume it has something to do with the control actualy being a wrapped ActiveX control.
I have tried giving it the WS_EX_CONTROLPARENT and WS_TABSTOP styles on creation as suggested here, but it did not help.
I found somewhere that I should make my control the event sink for HTMLDocumentEvents2, but I would rather avoid that if possible.
EDIT: Spy++ says I should be getting WM_PARENTNOTIFY and WM_MOUSEACTIVATE messages. However, my Derived Class receives absolutely no messages. I tried it with OnSize and OnCreate too. No message whatsoever is being sent. Any idea?
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.
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.