I'm planning to create modeless dialog and to receive messages from another thread. According to my understanding to creating modeless dialog I need to create CWinThread and some frame or dialog inside of CWinThread derived class object. But do I really need to create frame/dialog? Why I can't post messages direct to CWinThread derived class object?
You don't need a dialog to receive messages, but you do need a window handle. That window handle does not need to be associated with something visual. What I think you need is a message only window.
In MFC you can do this with CWnd using the CreateEx method to create the message only window. Pass HWND_MESSAGE to the hWndParent parameter of CreateEx.
It is true that you can create a hidden modeless dialog just to receive messages. However, this is grossly wasteful. What's more, MFC is designed around the concept that dialogs are created in the main UI thread. So for a number of different reasons you really do want to avoid creating a dialog just to receive messages in a thread. Use a message only window.
The message handler posts/sends messages to Window handlers, so you need a placeholder window to receive that message and handle as needed.
You can post messages to a CWinThread derived object using PostThreadMessage. But there are some cases where this is dangerous, discussed here:
http://www.codeproject.com/Articles/225755/PostThreadMessage-Demystified
Related
I'm using raw Win32 and C++ for a project. As I understand it, I am able to superclass Windows controls by retrieving the class information, replacing the procedure, then registering this as a new class and using it when creating a new window. Subclassing is done by replacing the window's procedure after the window is created. The advantage of superclassing is that you are able to process messages before CreateWindow() returns.
I'm looking to see if it's possible to superclass a dialog box created with CreateDialog() because I'd like to use a resource file for the dialog layout. The problem is that I don't know how I would provide my superclass when I create a dialog box. Is it even possible? Any idea how MFC handles this?
If you use an extended dialog box template to create your dialog, you can specify a custom window class as part of the DLGTEMPLATEEX definition.
The dialog manager will create and layout your dialog as normal, and call your window procedure for any dialog messages. You can use the DefDlgProc function to obtain default processing for any dialog messages you don't want to handle yourself.
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 am using MFC MDI. I create a window the main document window. I create another window(lets call it second window) as child of MDI Window View, then I create child window(third window) of second window. Again I need to create another window, child window of third window. I have a button on the ribbon and I want to call message handler in the third window to handle this command. I have added message map and all required stuff but it is not calling the message handler. If I define the message handler in MDI window view, it catches the event. If I dont delare the message handler in my main CWinApp class or MDI window View class the button appears disabled.
All my child view classes are inherited from CWnd and main MDI window is derived from CView. Please let me know what I am missing here.
Saba
I am at the loss here. You are using MFC; why using events? use command messages and command message handlers instead events.
Use MFC implemented and well working command routing.
MFC doesnt route messages generated by clicking Ribbon buttons to child windows. If we want to send messages to child windows of MDI windows we need to do it ourselves. Ribbon button's messages are either passed to active MDI window or CWinApp class.
I have a class derived from CDockablePane. I need to do something when the view is focused, so I handle WM_SETFOCUS and it all works nicely most of the time.
But when the pane is docked in Tabbed Document mode (TDI), and the user activates it, the WM_SETFOCUS is not called.
I used Spy and noticed the WM_MDIACTIVATE message is sent to the pane's parent window.
However if I handle WM_MDIACTIVATE inside the pane or inside the mainframe, it does not get called either.
Any ideas what I need to handle?
You may need to inherit the frame class and trigger the sending of a custom message to your views when WM_MDIACTIVATE is received by the frame.
I have a first dialog with a simple button on it and while clicking the button, a second dialog is created using CDialog::Create(IDD,this). I would like the parent to be notified when the second dialog is destroyed but without adding any code to the second dialog i.e., without adding a m_pParent->Notify() line in OnDestroy method.
I have tried OnParentNotify, PreTranslateMessage, SubclassWindow in the parent dialog with no success. I have not used the WS_CHILD style for the second dialog. Any idea?
To complete: in fact, I have a ComboBox derived class (but the issue is the same with buttons) and I'm displaying a modeless Dialog instead of displaying the listbox. But I would like the control to be as generic as possible so that any modeless dialog could be used. That's why I do not want to add a specific notification in the second dialog. If I'm obliged, I will use this trick but I asked for a more generic solution. PreTranslateMessage only catches WM_PAINT, WM_NCMOUSELEAVE and WM_NCMOUSEMOVE.
Use a base class and have your parent refer to the modeless child by base class only. In the base PostNcDestroy have it post to the parent.
It doesn't make sense to have the parent do a bunch of filtering / spying on all messages. It does make sense to implement behavior in a base class that you want to have common to all the different future flavors you might have of the modeless child.
OnParentNotify() is not called since dialog2 is not a child of dialog1.
PreTranslateMessage() should help here (although I don't like this bullet). The trick is that a modeless dialog doesn't destroy itself when it's closed. If you want the dialog to die, it must call DestroyWindow() when it closes, such in an OnCancel() override.
Of course, the first thing that comes to mind is t wonder why you don't want to add custom notification in your modeless dialog code.
EDIT: Another method would consist in installing a message hook (for the current thread, Not the whole system!). This would help you catch all messages for all windows associated to the same thread as dialog1. See SetWindowsHookEx()
How about posting a main parent form event to the message queue?