Language: C++
Development Environment: Microsoft Visual C++
Libraries Used: MFC
Pretty new to MFC, so bear with me. I have a dialog that is launched via DoModal(). I'm attempting to add buttons to this dialog that will replace the default "OK" and "Cancel" buttons. Right now, I can't quite figure out how to do this. I deleted the OK and Cancel buttons and added new ones with new IDs, added event handlers, and just some simple code for them to execute upon being pressed, but I couldn't get it to work.
I suspect it has something to do with the fact that DoModal() expects responses from OK or Cancel, but nothing else. I'm not really sure though. Any help would be greatly appreciated!
EDIT: Stripped down code added for reference.
void CPrefsDlg::Launch() {
[ ... ]
CSAPrefsDialog dlg;
INT_PTR nRet = -1;
nRet = dlg.DoModal();
// Handle the return value from DoModal
switch ( nRet )
{
case -1:
AfxMessageBox("Dialog box could not be created!");
break;
case IDABORT:
// Do something
break;
case IDOK: // This works just fine.
exit(0);
break;
case IDSAVEONE: // This does not work.
MessageBox("Save One");
break;
default:
break;
};
}
void CPrefsDlg::SaveOne()
{
// I tried adding in my own handler for 'Save One'...this does not work.
MessageBox("Save one");
}
To wire up your dialog to terminate and return IDSAVEONE, you need to add a click handler to the Save One button and have it call EndDialog:
void CSAPrefsDialog::OnBnClickedSaveone()
{
EndDialog(IDSAVEONE);
}
If you add the click handler through the dialog editor (e.g. by double-clicking on your button) then the necessary framework code will be generated for you to wire this up; otherwise you'll need to add the following line into your BEGIN_MESSAGE_MAP section in your dialog class:
ON_BN_CLICKED(IDSAVEONE, &CSAPrefsDialog::OnBnClickedSaveone)
but (as AJG85's just beaten me to posting) depending on what the operation is, how fast it is and whether you want to report errors in the preferences dialog or not, you may want to just carry out the extra function in your on-clicked handler instead.
MFC has built in ids for the ok and cancel buttons. Those being IDOK and IDCANCEL. You can either handle these in a switch via the return of DoModal() or probably better would be to override OnOK() and OnCancel() methods in your dialog class to do what you want.
You can do this by adding a line to the message map to call your handler:
Edit: The same thing works for buttons you add to the dialog which I added to my example code below:
BEGIN_MESSAGE_MAP(MyDialog, CDialog)
ON_BN_CLICKED(IDOK, &OnBnClickedOk)
ON_BN_CLICKED(IDSAVEONE, &OnBnClickedSave)
END_MESSAGE_MAP()
void MyDialog::OnBnClickedOk()
{
// do extra stuff when they click OK
CDialog::OnOK(); // call base class version to complete normal behavior
}
void MyDialog::OnBnClickedSave()
{
// this would be called for your save button with custom id IDSAVEONE
// note: no base class call here as it's specific to your dialog
}
Related
I have an MFC dialog based application that has 2 Dialogs: Main Dialog CMyDlgand Second dialog CMyDlg2.
On the main Dialog I add a Button "Go dialog 2". So I added a handler for the button so that when clicked it pops up the second dialog. Everything works fine But on the second Dialog I have added a Rich Edit Control from toolbox. I Added for it a variable. I also added a class for the second dialog.
Now If I run the Application I get the dialog one and if I pressed "Go to dialog 2" I got what I want. But I need at some point to change the font of the rich edit control but my program crashes.
So I overrided OnInitDialog and inside it do some changes to the control but program crashes. After debugging I found that the handle of rich edit is null?!
So how and where can I change the color or do some initializations to the control?
(I called AfxInitRichEdit2() in OnInitInstance())
BOOL CMyDlg2::OnInitDialog() {
m_richEdit.SetWindowText("Hello there!"); // program crashes because the handle m_richEdit is null.
return TRUE;
}
And this is the handler of button that creates the Dialog2 and that contains the rich edit control:
void CMyDlg::OnBnClickedButton1(){
CMyDlg2 theDlg;
theDlg.DoModal();
// TODO: Add your control notification handler code here
}
If I create the rich edit control programmatically then everything works fine because I create it at OnInitDialog and then it works fine but I need the one that is I added using the wizard toolbox.
*** The thing is that if I write:
m_richEdit.SetWindowText(""); // program crashes but if I wirte:
GetDlgItem(IDC_RICHEDIT221).SetWindowText(""); it works fine?
You probably have the following code inserted by wizard:
void DoDataExchange(CDataExchange* pDX)
{
CDialogEx::DoDataExchange(pDX);
DDX_Control(pDX, IDC_RICHEDIT22, m_richEdit);
}
This tells the dialog to associate m_richEdit with the dialog control IDC_RICHEDIT22. But this association is not performed until the base class method CDialog::OnInitDialog(); is called.
BOOL CMyDlg2::OnInitDialog()
{
//this line should work:
GetDlgItem(IDC_RICHEDIT22)->SetWindowText("Hello");
//this line won't work:
//m_richEdit.SetWindowText("Hello there!"); <- richedit's handle is NULL
//this line will subclass m_richEdit
//plus run other initialization
CDialog::OnInitDialog();
//m_richEdit is ready
m_richEdit.SetWindowText("Hello there!");
return TRUE;
}
It's recommended to put CDialog::OnInitDialog() int the first line, to make sure the initialization is done.
GetDlgItem works because the control IDC_RICHEDIT22 exists in the dialog template and you have a valid dialog handle. You are basically making a simple call based on WinAPI's GetDlgItem:
HWND hedit = ::GetDlgItem(m_hWnd, IDC_RICHEDIT22);
::SetWindowText(hedit, "Hello world");
There is no additional initialization needed.
But m_richEdit is just a C++ object, declared as CRichEditCtrl m_richEdit; The constructor for this C++ class doesn't do much besides setting m_hWnd to NULL.
Once it's associated with a valid window handle, we can begin using its windows methods such as CRichEdit::SetWindowText
I have a Modeless dialog which shows a bunch of buttons; some of these are customized to draw stuff with GDI.
Now, when the user clicks on a customized one under certain conditions, a message box appears to alert user of the error and this is fine.
The problem is that after accepting the Message Box (showed as MB_ICON_ERROR), everywhere I click in the dialog, I always get the error message as if the whole dialog send the message to the customized button and the only way to get rid this is to press tab and give the focus to another control.
This is a strange behaviour and knowing why happens wouldn't be bad, but a simple workaround for now should do the job.
Since the moment that is probably a matter of focus, I've tried to set it on another control (in the owner dialog) by doing:GetDlgItem( IDC_BTN_ANOTHER_BUTTON )->SetFocus();
and then, inside the customized control by adding:KillFocus( NULL );but had no results.
How should I use these functions?
Thanks in advance.
PS: if I comment the AfxMessageBox, the control does not show this bizarre behaviour.
EDITI'll show some code as requested.
// This is where Message Box is popping out. It is effectively inside the dialog code.
void CProfiloSuolaDlg::ProcessLBtnDownGraphProfilo(PNT_2D &p2dPunto)
{
// m_lboxProfiles is a customized CListBox
if(m_lboxProfiles.GetCurSel() == 0)
{
// This profile cannot be modified.
/*
CString strMessage;
strMessage.Format( _T("Default Profile cannot be edited.") );
AfxMessageBox( strMessaggio, MB_ICONERROR );
*/
return;
}
// Selecting a node from sole perimeter.
SelectNodo(p2dPoint);
}
Actually, the message is commented to keep the dialog working.
// This is inside the customization of CButton
void CMyGraphicButton::OnLButtonDown(UINT nFlags, CPoint point)
{
PNT_2D p2dPunto;
CProfiloSuolaDlg* pDlg = (CProfiloSuolaDlg*)GetParent();
m_pVD->MapToViewport(point,p2dPunto);
switch(m_uType)
{
case GRF_SEZIONE:
pDlg->ProcessLBtnDownGraphProfilo(p2dPunto);
break;
case GRF_PERIMETRO:
pDlg->ProcessLBtnDownGraphPerimetro(p2dPunto);
break;
}
CButton::OnLButtonDown(nFlags, point);
}
Since you are handling the button down event in the button handler for the custom control, you don't need to call the base class. Just comment out CButton::OnLButtonDown(nFlags, point).
I know one method of preventing an MFC dialog from closing when the Enter or Esc keys are pressed, but I'd like to know more details of the process and all the common alternative methods for doing so.
Thanks in advance for any help.
When the user presses Enter key in a dialog two things can happen:
The dialog has a default control (see CDialog::SetDefID()). Then a WM_COMMAND with the ID of this control is sent to the dialog.
The dialog does not have a default control. Then WM_COMMAND with ID = IDOK is sent to the dialog.
With the first option, it may happen that the default control has a ID equal to IDOK. Then the results will be the same that in the second option.
By default, class CDialog has a handler for the WM_COMMAND(IDOK) that is to call to CDialog::OnOk(), that is a virtual function, and by default it calls EndDialog(IDOK) that closes the dialog.
So, if you want to avoid the dialog being closed, do one of the following.
Set the default control to other than IDOK.
Set a handler to the WM_COMMAND(IDOK) that does not call EndDialog().
Override CDialog::OnOk() and do not call the base implementation.
About IDCANCEL, it is similar but there is not equivalent SetDefID() and the ESC key is hardcoded. So to avoid the dialog being closed:
Set a handler to the WM_COMMAND(IDCANCEL) that does not call EndDialog().
Override CDialog::OnCancel() and do not call the base implementation.
There is an alternative to the previous answer, which is useful if you wish to still have an OK / Close button. If you override the PreTranslateMessage function, you can catch the use of VK_ESCAPE / VK_RETURN like so:
BOOL MyCtrl::PreTranslateMessage(MSG* pMsg)
{
if( pMsg->message == WM_KEYDOWN )
{
if(pMsg->wParam == VK_RETURN || pMsg->wParam == VK_ESCAPE)
{
return TRUE; // Do not process further
}
}
return CWnd::PreTranslateMessage(pMsg);
}
The answer of #the-forest-and-the-trees is quite good. Except one situation which was addressed by #oneworld. You need to filter messages which are not for dialog window:
BOOL CDialogDemoDlg::PreTranslateMessage(MSG* pMsg)
{
if (pMsg->hwnd == this->m_hWnd && pMsg->message == WM_KEYDOWN)
{
if (pMsg->wParam == VK_RETURN || pMsg->wParam == VK_ESCAPE)
{
return TRUE; // Do not process further
}
}
return CWnd::PreTranslateMessage(pMsg);
}
Remember to add virtual in the header file.
When dealing with Dialog style MFC applications, the framework automatically hard codes a few items that must be overridden to prevent the application from quitting when the Esc or Enter keys are pressed. But there is a very simple way that doesn't require anything special such as implementing PreTranslateMessage() which is very much not recommend.
There are three functions that need to be in place:
The OnCancel() function to override the base class version and not to call it. This prevents the Esc key from closing the app.
The OnOK() function to override the base class version and not to call the base class. This prevents the Enter key from closing the app.
Because you've now prevented the dialog window from being closed you must now implement the OnClose() event handler. This function handler will handle when the Windows "X" button or the system command Close Alt+F4 are clicked. Now in order to close the application, you then call the base class version of one of the other functions OnOK(), OnCancel() if desired, to actually close the app. At this point you now have full control of how the app is closed.
Step 1
In the header, add the three function prototypes.
You can use the Class Wizard if you like to add the WM_CLOSE event handler but it's super simple to just type it in.
// DefaultDialogAppDlg.h
//
class CDefaultDialogAppDlg : public CDialogEx
{
// ... other code
protected:
virtual void OnCancel(){} // inline empty function
virtual void OnOK(){} // inline empty function
public:
afx_msg void OnClose(); // message handler for WM_CLOSE
// ...other code
};
Step 2
In the .cpp file, add the ON_WM_CLOSE() entry to the message map and the definitions for the three functions. Since OnCancel() and OnOK() are generally going to be empty, you could just inline them in the header if you want (see what I did in Step 1?).
The .cpp file will have something like this:
// DefaultDialogAppDlg.cpp
// ... other code
BEGIN_MESSAGE_MAP(CDefaultDialogAppDlg, CDialogEx)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_WM_CLOSE() // WM_CLOSE messages are handled here.
END_MESSAGE_MAP()
// ... other code
void CDefaultDialogAppDlg::OnClose()
{
// TODO: Add exit handling code here
// NOTE: to actually allow the program to end, call the base class
// version of either the OnOK() or OnCancel() function.
//CDialogEx::OnOK(); // returns 1 to theApp object
CDialogEx::OnCancel(); // returns 2 to theApp object
}
I simply override the OnOk event and instead of passing the message to the parent dialog, do nothing.
So it's basically simple as doing so:
void OnOk() override { /*CDialog::OnOK();*/ }
This should prevent the dialog from closing when pressing the return/enter key.
Make sure you don't #define CUSTOM_ID 2 because 2 is already defined for escape and I think 1 is defined for enter? Correct me if i'm wrong.
How can I suppress to close the form when hitting the OK button? I have the following code:
void __fastcall TfrmTillegg_velg::btnOkClick(TObject *Sender)
{
if (exp1)
ShowMessage("Not allowed"); // Don't close form
else if (exp2)
ShowMessage("Not allowed"); // Don't close form
else
{
// Do something here
Close();
}
}
The project is written in Borland c++builder.
If you mean keeping the dialog created by ShowMessage open. then as far as I am aware, you cannot do this. The dialog displayed by ShowMessage will close whenever you click any of its buttons. If you want a popup dialog that will not close in this way, you will need to create a custom form yourself and control its behaviour according to your needs.
Just in case your question is referring to your main form closing, then you do have an explicit call to Close() within your button click event handler above that will cause your form to close whenever both of your exp1 and exp2 conditions are false.
else {
// Do something here
Close(); // THIS WILL CLOSE YOUR MAIN FORM.
}
I have a dialog which I need to show both inside a CPropertySheet and as a standalone dialog. I've chosen not to have 2 separate classes to avoid code redundancy (I make changes a lot in those dialogs, and having to sync 2 classes constantly would be hell), instead when I want to show it as a standalone dialog, I just call CPropertyPage::DoModal. This causes some problems, but I've fixed most of them.
However, some still remain, namely enter and esc don't work. Also pressing tab doesn't change the focus. This makes me think that CPropertyPage eats up all keyboard input, or maybe it tries to pass them to its parent.
Any ideas how I can override that behaviour in the standalone mode?
I believe this would work for you. I don't have a dialog that I can test this with so I am doing this all from memory but I believe you could add a bool that you set when you call DoModal or expose it as a property that you set before the call to DoModal to indicate it is running as a stand alone dialog, then override PreTranslateMessage like this:
CMyPropertyPage::PreTranslateMessage(MSG* pMsg)
{
if (m_runningAsStandalone && pMsg->message == WM_KEYDOWN)
{
UINT key = pMsg->wParam;
switch(pMsg->wParam)
{
case VK_RETURN:
OnOK();
return TRUE;
case VK_ESCAPE:
OnClose();
return TRUE;
}
}
return CPropertyPage::PreTranslateMessage(pMsg);
}
You may also find this link helpful http://support.microsoft.com/kb/125645