MFC Have enter key act as "apply" button - c++

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

Related

how to end dialog box(i.e propertysheet) programmatically

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.

CPropertyPage derived dialog doesn't close on Esc when showing as a standalone dialog

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

How do I use Dialog resources in Win32?

Without resources I can create my UI with a complex array of CreateWindow() and CreateWindowEx(), and WndProc() to process my events.
I noticed if I right-click in the resource view and click "add resource", I can draw a dialog box with all the controls. This would save me a huge amount of time if I could draw the interface like I normally do with C#.
After I've drawn the interface with the resource editor, how do I then create the window from code? Can someone provide a very simple example with a button, and show how to handle a WM_COMMAND event on that button please?
Also, is this generally how people create the GUI? Is there any loss in flexible to do this way? Even in C# I often have to supplement designer-generated UI with my own code-generated UI, but the majority of the time I'm quite happy to use designer.
After creating the dialog in the resource editor, call CreateDialog(modeless dialog;you need to dispatch the messages manually just like when you use CreateWindow) or DialogBox(modal dialog; the function does not return until you close the dialog. it does the dispatching for you) to make the dialog show up. Just like you pass in the window proc to RegisterClass, you pass the dialog proc to those functions for the dialog call back. An example of DialogProc looks likes this:
BOOL DialogProc( HWND hDlg, UINT iMessage, WPARAM wParam, LPARAM lParam ){
switch( iMessage ){
case WM_COMMAND:
switch( LOWORD( wParam ) ){
case BTOK:
MessageBox( hDlg, "Hello, World!", NULL, NULL );
return TRUE;
break;
}
break;
}
return FALSE;
}
This is a basic way of creating a dialog. More sophisticated method would normally involve OOP, usually wrapping each resource( button, window, etc) as a C++ object or using MFC.
If you have placed your button or any control on some dialog, that control is already in created state. For handling the messages of these child controls on this dialog , you have to override OnCommand Method in the class which is implementing your dialog.
For Example:
//CDialog_ControlDlg is my Dialog class derived from CDialog
//IDC_BUTTON_SAMPLE is the ID of the button which was palced on the dialog in the resource Editor..
BOOL CDialog_ControlDlg::OnCommand(WPARAM wParam,LPARAM lparam){
int iNotiFicationMsg=HIWORD(wParam);//This is thenotification Msg from the child control
int iCommandId=LOWORD(wParam);//And Control ID of the Child control which caused that Msg
BOOL result=FALSE;
switch(iCommandId){
case IDC_BUTTON_SAMPLE:
if(iNotiFicationMsg==BN_CLICKED)
{
//Your Code for handling this type of Msg for this control..
}
break;
default:
{
//Specific Code;
}
return result;
}
}

Why doesn't OnKeyDown catch key events in a dialog-based MFC project?

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.

EN_MSGFILTER, can't prevent message propogation

I have a dialog with a rich-text control. The dialog wants to intercept right-click events on the control; in some cases the dialog should do its own functionality and block the message reaching the control, in other cases it should let the control receive the message.
So I have:
ON_NOTIFY(EN_MSGFILTER, IDC_RICHTEXT, OnRichTextMsgfilter)
void CMyDialog::OnRichTextMsgfilter(NMHDR *pNMHDR, LRESULT *pResult)
{
MSGFILTER *pMsgFilter = reinterpret_cast<MSGFILTER *>(pNMHDR);
*pResult = 0;
if (pMsgFilter->msg == WM_RBUTTONUP)
{
if(...)
*pResult=1;
}
}
I step through the code and pResult is set when it should be, but the control still gets the message. Looking at MSDN it says:
If the control should process the
event, the message returns a zero
value. If the control should ignore
the event, the message returns a
nonzero value.
But the defined message handler signature has no return... I am assuming that's what *pResult is for. Is that not true? If so how do I achieve this?
So i've tried to reproduce this behavior in a simple dialog based app and i really can't -- however, i'm not sure what it is that intercepting the right button message is trying to solve.
That said the following code completely blocks the Left button mouse clicks in my testing (If this returns TRUE the control does not respond to left clicks - however focus will get set to the control on the initial click down and that is more a window manager issue than the control itself)
void CTestDlg::OnMsgfilterRichedit1(NMHDR* pNMHDR, LRESULT* pResult)
{
MSGFILTER *pMsgFilter = reinterpret_cast<MSGFILTER *>(pNMHDR);
if (pMsgFilter->msg == WM_LBUTTONUP || pMsgFilter->msg == WM_LBUTTONDOWN)
{
*pResult = TRUE;
return;
}
*pResult = FALSE;
}
If i change *pResult = TRUE to *pResult = FALSE then the left clicks start working again.
It could be that you want to catch and filter out the WM_RBUTTONDOWN rather than WM_RBUTTONUP to do what you intend, but since i'm unsure what functionality you are trying to filter out i can't say for sure.
The WM_RBUTTONDOWN is stil getting through...