I want to build a MFC application, with one main dialog, and all the other dialogs are child of this main dialog (and embedded in it).
Now, i was able to embed the first child in the main dialog, but i want to pass to the next dialog (note that the order of opened dialogs is random), so i need to hide the first dialog and show another. To know which dialog is shown at the moment and hide it, i've tried using a CDialog variable to store the current opened dialog, but i get a CObject::operator =' : cannot access private member declared in class 'CObject' error.
Is there another way to do this "hide and show dialogs" game?
EDIT: Could i store some ID of the dialogs and use it to acomplish this task?
So i managed to accomplish this task using classes IDDs.
First, i store the last opened dialog's IDD
m_dlgStartPage.Create(CStartPageDlg::IDD, this);
m_openedWin.nDialogIDD = m_dlgStartPage.IDD;
m_dlgStartPage.ShowWindow(SW_SHOW);
Then, when a new dialog needs to be shown, i send a message to my main dialog (nIDD is the IDD of pending dialog to show):
AfxGetApp()->m_pMainWnd->SendMessage(WM_COMMAND_CHANGE_WINDOW, nIDD, 0);
And last, in my main dialog, i parse all the child dialogs and check if m_openedWin.nDialogIDD matches with each dialog's IDD, so i can hide it. After this, i parse once again all the chid dialogs and use the nIDD from the sent message to show the correct one.
I don't really like this approach, because of all the parsing and sent messages to the main dialog's class, so if anyone has a better idea or method, please post it.
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 have an dialog with several buttons and sliders on it and am adding another button that should close the dialog and open another that is essentially a mini version it.
I need access to the buttons in the first dialog in the second mini dialog (since they should have the same functionality).
Is there a way to use the class from the first dialog on the second so that I have access to those buttons? I've tried right clicking the dialog and adding a class, but it makes me make a new one instead of being able to use an existing one.
Thanks in advance!
I've created a simple Dialog box with a few controls (edit, text, etc) and saved
it to the resource folder in GME/GME.rc/Dialog
I added an auto-gen'd event handler which created a new class (Class.cpp
for the purposes of this example) Note: the Class::Class(CWnd *pParent) :
CDialogEx(Class::IDD, pParent) constructor is empty, I'm not sure if that's
relevant but I don't think it is..
There's a MESSAGE_MAP COMMAND(menu_item_id, &class::member_function())
invocation within the Class.cpp was auto-generated. It's wrapped in the
standard BEGIN_MESSAGE_MAP macro stuff.
However: when the menu item is clicked, the item remains gray. The
properties for "enabled=true" and "gray=false" are both properly
configured. So, I assume this is error is due to the message handler isnt
registered.
Any help would be appreciated.
Without code, it's pretty darn hard to help. Are you sure you put the message handler for the menu id in either a CView, CFrame, CDocument, or CWinApp derived class? If you put the menu handler in your dialog class, it's not going to do you much good.
Dialogs do not contain the code to run through the list of ON_UPDATE_COMMAND_UI handlers that MFC uses to enable menu items. Ordinarily this is handled by CFrameWnd for example. Try calling UpdateDialogControls in your OnInitDialog function.
I see that your code is also missing the ON_UPDATE_COMMAND_UI macro for the menu item, even though the handler it would reference was created for you.
You add menu item handlers to the window that has the menu, which is usually the CMainFrame. Copy the message map and handler to the CMainFrame and see if that helps. I'm not sure what you're trying to do here - I assume you want to display 'Class' (maybe better to edit your post to call this 'ExampleDialog' or something...) when the menu item is clicked, right? Or did you somehow add a menu to your CDialogEx-derived class? If the last, I guess this is what Mark is referring to - 'how are you displaying the menu'? How are you manually adding a menu to your dialog?
I have tons of existing code using wxWidgets. The main window is wxDialog. Now I have to add a wxMenuBar to that dialog. But, in order to do it, the window should be derived from wxFrame.
Is it possible to add a wxMenuBar to the wxDialog?
If not, is it possible to convert existing code in a way that main window is derived from wxFrame instead from wxDialog?
It's not possible to add a native menu bar to a wxDialog, however, it is possible to use a non-native menu bar control like wxFlatMenuBar (not included with wxWidgets), and add it to the top of the dialog as if it was just another control. Also note though that besides being a non-native menu bar, you also won't be able to use some wxWidgets API to manage it like wxUpdateUIEvents.
There's at least a couple things you will need to take into consideration when changing a wxDialog to a wxFrame.
First, if your dialog is a modal dialog, you will need to manually set the new frame as modal (using wxWindow::MakeModal()) rather than calling ShowModal().
Second, if you had any event handlers setup for the affirmative (OK/Apply button for example) or escape (Cancel or window close) events, you will likely need to rewrite them to handle changes in window behavior.
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?