I just create a dialog-based project in MFC (VS2008) and add OnKeyDown event to the dialog.
When I run the project and press the keys on the keyboard, nothing happens. But, if I remove all the controls from the dialog and rerun the project it works.
What should I do to get key events even when I have controls on the dialog?
Here's a piece of code:
void CgDlg::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
// TODO: Add your message handler code here and/or call default
AfxMessageBox(L"Key down!");
CDialog::OnKeyDown(nChar, nRepCnt, nFlags);
}
When a dialog has controls on it, the dialog itself never gets the focus. It's stolen by the child controls. When you press a button, a WM_KEYDOWN message is sent to the control with focus so your CgDlg::OnKeyDown is never called. Override the dialog's PreTranslateMessage function if you want dialog to handle the WM_KEYDOWN message:
BOOL CgDlg::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message == WM_KEYDOWN )
{
if(pMsg->wParam == VK_DOWN)
{
...
}
else if(pMsg->wParam == ...)
{
...
}
...
else
{
...
}
}
return CDialog::PreTranslateMessage(pMsg);
}
Also see this article on CodeProject: http://www.codeproject.com/KB/dialog/pretransdialog01.aspx
Many of my CDialog apps use OnKeyDown(). As long you only want to receive key presses and draw on the screen (as in make a game), delete the default buttons and static text (the CDialog must be empty) and OnKeyDown() will start working. Once controls are placed on the CDialog, OnKeyDown() will no longer be called.
Related
According to this article, to allow Drop Only on the Target, we have to
Use SubclassDlgItem() to re-route that one message to the dialog object so that all of the handling can be done there.
Mr. DanRollins (the author of the article) also provides an example
class CEditDropNotif : public CEdit
{
virtual BOOL PreTranslateMessage(MSG* pMsg) {
if ( pMsg->message == WM_DROPFILES ) {
GetParent()->SendMessage(WM_DROPFILES, pMsg->wParam, pMsg->lParam);
return TRUE; // eat it
}
return FALSE; // allow default processing
}
};
BOOL CMyDlg::OnInitDialog()
{
...
static CEditDropNotif cEd; // must persist (usually a dlg member)
cEd.SubclassDlgItem( IDC_EDIT1, this );
::DragAcceptFiles( cEd.m_hWnd, true ); // the editbox, not the dialog
...
But I don't understand why Edit control (CEdit) has the Accept Files in the properties window (Visual Studio Resource view), but can't register the message WM_DROPFILES for itself without having to create an inherited class (or it can but I haven't known yet).
I see that we can register the click message for button by the following code
BEGIN_MESSAGE_MAP(CSimpleDlg, CDialogEx)
...
ON_BN_CLICKED(IDC_BTN_01, &CSimpleDlg::OnBnClickedBtn01)
END_MESSAGE_MAP()
Is there a way I can do similar for drag drop event, like
ON_DRAW_DROP(IDC_TXT_01, &CSimpleDlg::OnDragDrop01)//Is exist?
The answer is: Nope.
ON_BN_CLICKED macro maps a member function that handles BN_CLICKED notification sent via WM_COMMAND message. The notifications are sent to control's parent (although MFC has also a "reflection" mechanism that forwards the notifications to controls).
WM_DROPFILES is a general Windows message, not a notification so that's it: if you want to handle it then you have to derive from CEdit.
See also:
Message Categories
Message Reflection for Windows Controls
I'm trying to close dialog box (which is basically derived from propertysheet class) from code. following is my code:
LRESULT CSettingsSheet::OnCloseSettings(WPARAM wParam, LPARAM lParam)
{
EndDialog(IDCANCEL);
return 0;
}
the issue is endDialog terminates not only dialog box but also main application window. what could be the reason for this problem?
BTW i create this dialog box in main window as follow
if(settingsSheet.DoModal() == IDOK)
{
}
else
{
}
ideally i should set this domodal value with IDCANCEL instead of calling end dialog.
Thanks,
Khurram.
You need to send PSM_PRESSBUTTON message to the property sheet window:
Simulates the selection of a property sheet button. You can send this message explicitly or by using the PropSheet_PressButton macro.
PSBTN_CANCEL - Selects the Cancel button.
PSBTN_OK - Selects the OK button. This value is not valid when using the Aero wizard style (PSH_AEROWIZARD).
The MFC has a function for this CPropertySheet::PressButton.
In a certain dialog I would like when the user presses the enter key for it to act as an "apply" button. So far I have at least been able to make the dialog not close upon pressing enter by overriding CWnd::PreTranslateMessage, so currently it just does nothing and I'm not sure how to send apply command from there.
Every dialog should have one and only one button with the BS_DEFPUSHBUTTON style, which indicates to the dialog that this is the button to activate with the Enter key. Usually this is the OK button, but you can make it the Apply button if you want to.
As Mark pointed out above the dialog manager already has all the logic built in to handle the Enter key by invoking the command associated with the default button. You can statically assign the BS_DEFPUSHBUTTON style or handle the DM_GETDEFID message.
The former is trivially easy and the latter is fairly simple to implement. Make sure you set the Default Button property to False for all buttons on your dialog. Now add a message handler for the DM_GETDEFID message. There is no dedicated macro for this message so you have to use the generic handler:
BEGIN_MESSAGE_MAP(CMyDialog, CDialogEx)
...
ON_MESSAGE(DM_GETDEFID, OnGetDefId)
END_MESSAGE_MAP()
The message handler is equally simple and uses the default message handler signature:
LRESULT CMyDialog::OnGetDefId(WPARAM wParam, LPARAM lParam)
{
return MAKELRESULT(ID_APPLY, DC_HASDEFID);
}
The message handler must return a value whose high-order word contains DC_HASDEFID and the low-order word contains the control ID.
If you navigate over the controls of the dialog you will see that the Apply button has the typical default button visual cue while focus is not on another command button. Pressing Enter while a non-button control has the input focus invokes the default button's command handler. No additional code required.
If your intent is to handle the Enter key without dismissing the dialog, you may be going about it incorrectly. Please take a look at this MSDN article. While using PreTranslateMessage should work, it is not the best way to handle these types of events.
You'll need to handle the OnKeyDown message, and handle the VK_RETURN character inside that function.
void MyCtrl::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if(nChar == VK_RETURN)
{
// Do Stuff
return;
}
CWnd::OnKeyDown(nChar, nRepCnt, nFlags);
}
Another way to overwrite the message.
BOOL CMyDialog::PreTranslateMessage(MSG* pMsg)
{
if (pMsg->message == WM_KEYDOWN)
{
switch (pMsg->wParam)
{
case VK_RETURN:
{
UINT nID = ::GetDlgCtrlID(pMsg->hwnd);
if (nID == ID_APPLY)
{
//DO YOUR STUFF HERE
}
}
break;
default:
break;
}
}
return CDialog::PreTranslateMessage(pMsg);
}
Also, you don't need to use PreTranslateMessage if you are using ::OnKeyDown
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.
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
}