I am writing a Dialog Based C++ application with MFC for the GUI. After the creation of the project, Visual Studio also created two classes ProjectNameApp and ProjectNameDlg. When adding a Menu to my application the menu item handlers (for the menu buttons) are added as methods to the ProjectNameApp class. In one of these handlers I want to access a variable of the ProjectNameDlg class, more specific, a CComboBox. But that, of course, is not possible. So I have two questions:
is there a way to acces that CComboBox variable from the Dlg class?
if not, how can I move the Menu handlers to the Dlg class to directly use the CComboBox variable?
Also, my application has to be dialog based, and it has to have a menu.
The last I dealt with any of this was in VS-2008, but if memory serves the CDialog object is probably allocated on the stack in CProjectNameApp::InitInstance(). There is probably some code there that looks kind of like:
CProjectNameDlg dlg;
int nResponse = dlg.DoModal();
One thing you could do is to add a pointer to the dialog as a member of the ProgramNameApp class. So in ProgramNameApp.h add a data element like:
std::tr1::unique_ptr<CProjectNameDlg> m_pDlg;
Then change the code in CProjectNameApp::InitInstance() to be:
m_pDlg = std::tr1::unique_ptr<CProjectNameDlg>(new CProjectNameDlg());
int nResponse = m_pDlg->DoModal();
Naturally you'd have to be on the lookout for any other uses of dlg and change them accordingly.
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 having a proglem with the MFC application and the DialogBox. I am quiet sure I've done everything well with this tutorial: https://msdn.microsoft.com/en-us/library/6wb9s9ah.aspx
but still it doesn't work...
1. I've created new project with simple menu commands.
2. I've created new menu item (+ID) and new resource DialogBox (+ID).
3. Then I've added a new class named CParameters with the Class Wizard. For the BaseClass I've typed in CDialog.
4. I've created new handler on the menu item and added the code
CParameters dlg;
dlg.DoModal();
I think this is it, and this should work... But it doesnt... What is missing??
Here is my project, you can access it freely:
https://www.dropbox.com/sh/e6ajoxqk76hkuvn/AACRMY8bgcuyXguFwP240QB9a?dl=0
Additionally I want to insert TextEditors and to change parameters in my program from the dialog box.
A scan of your source code reveals that you are trying to handle the menu item event within the class that is going to display the dialog.
void CParameters::OnParam()
{
// TODO: Add your command handler code here
CParameters dlg;
dlg.DoModal();
}
I don't see anywhere else that you actually instantiate the dialog class (I may have missed it). What you are trying is incorrect. You cannot handle the menu item event within the same class that displays the dialog because that class (CParameters) has not been instantiated, so, it cannot respond to the menu event. Typically, the menu event would be handled in the mainframe class.
If you are doing this by adding a new menu item from a simple SDI application, then trying adding that part of code in
CMainFrame::OnEdit
OnEdit method used here is obtained from the Event Handler for the new menu item and Message type being COMMAND.
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.
I need to create some dynamic menus in a VS2010 SDI application I'm writing. I've seen this, but don't really understand it
Dynamic menu using mfc
At the moment, I've no idea how to even use GetMenu to get a handle to the menu from my Doc file. I'm trying this, but it says GetMenu doesn't take zero arguments, even though many examples I've seen clearly show this.
CMenu *menu = GetMenu();
menu->AppendMenu(MF_STRING, ID_HIDE, _T("Text"));
All I want to do is add a list of files underneath a sub-menu, selected from a database (hence the dynamic part), so a user can select the one they want to work on.
Thanks,
James
If you're calling GetMenu from within a window class derived from CWnd, you'll be calling CWnd::GetMenu and it will not require a window handle. If you're calling it from anywhere else you will get ::GetMenu(HWND) and you will need to pass a window handle. You can get the handle from any CWnd object with its m_hWnd member or by calling GetSafeHwnd() on it.
I've used MFC dialogs before where you do:
EnterNameDlg dlg;
dlg.DoModal();
string str = dlg.GetName();
However a dialog I have now actually looks at a list-box control in such a method and it's not working. Although the class instance clearly exists after DoModal(), does the actual dialog get destroyed? I noticed calling DoModal() a 2nd time leads to OnInitDialog() also being called again which seems to support this theory, the dialog is recreated from the template rather than simply made visible the 2nd time.
Yes, DoModal creates a dialog on each call and destroys the window before returning.
Only the data members will still be valid. Of course, you can add more data members in your EnterNameDlg class if you want to collect data during dialog's lifetime.
As soon as the dlg gets out of scope, everything will be deallocated.
After DoModal class instance still exists, but window and all its controls are destroyed. You can call only functions that don't work with dialog controls after DoModal. Inside of the dialog class, keep required values in class members like CString, when OK button is pressed. These members can be read after dialog is closed.
The entirety of MFC is built around an awkward pairing - the Windows window with its associated handle, and the MFC class object. The MFC classes are designed to outlast the window in most cases.