• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 594
  • Last Modified:

Why is dialog quitting on Enter key press?

I created a dialog-based app using the app wizard.  I removed the OK and Cancel buttons and added my own CBitmapButton buttons, one of which acts as the Exit button.  

If I mouse click on each button, they do as they should - call their associated OnX... routine.  The Tab key lets me change focus to each button.  However, when focus is on a button and the Enter key is pressed, the dialog quits instead of calling the "OnX..." routine for the button with focus.  Can someone explain this?
0
rosborn051498
Asked:
rosborn051498
1 Solution
 
kinkajouCommented:
It sounds like the buttons aren't properly associated with an ID Message/Event.
0
 
rosborn051498Author Commented:
They do respond to mouse clicks - that is, their associated OnX... handlers get called on mouse clicks.  The problem is, the same OnX... handlers don't get called when the Enter key is pressed and a button has focus.
0
 
duneramCommented:
i WAS Not able to recreate your problem, but I did notice that if I set the TabStop attribute on a non button item like a Static Text field.  and then tab thru until neither button is 'focused' and then hit 'enter' that the dialog goes away.   The item on the dialog that has focus, by default is also tied to the 'enter' key.   If the neither button trully has focus and you hit enter, the dialog will close.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
rosborn051498Author Commented:
You did recreate the problem, though.  That's what I'm talking about - neither the OK or Cancel button has focus but Enter closes dialog.  Actually, I can confirm that my button has focus because I'm trapping the SetFocus event for it.  Besides, the OK and cancel buttons were deleted from dialog.

Seems as though the Enter key is not tied to control with focus.
0
 
duneramCommented:
I believe you have one potential answer here.  If I did recreate the problem, I did it by allowing a control (not a button) to have the WS_TABSTOP style.  Thus when using tab to rotate thru the focusable events, you end up with a situation where neither button has focus, yet something does (you just cannot see it).  If you make sure that you don't have the tabstop property set for any of the other controls,  your problem should go away.    You mentioned you were trapping the SetFocus, but perhaps the way to interpret it is that was the last control to have focus.  There is a fair chance that letting a control have WS_TABSTOP that has no event handler is actually passing thru event 0 or IDOK.  Sure enough, if you create a handler for OnOK you will see control pass thru there.
0
 
rosborn051498Author Commented:
There are no other controls.  The only control on the dialog is my CButton-derived, owner-drawn button.  No static, nothing else.

My button has TabStop set.  I know that it has focus when I press Enter because I handle both OnSetFocus and OnKillFocus and only SetFocus is called.

I'm probably overlooking something simple, but I know it's not due to my control not having focus.
0
 
duneramCommented:
You don't necessarily know you have focus.  In windows, there is a period of time when no one has focus (its quick).  You can do a get focus to see if it has but its the sort of thing that has to be trapped/logged and then reviewed to see what happened.
0
 
rosborn051498Author Commented:
Actually, my last post wasn't entirely true.  I have 3 instances of my CButton control on the dialog.  Before pressing Enter, I Tab through them several times to make sure focus "lands" on one of them.  I know it has focus because I process OnSetFocus and change the appearance of the button.  OnKillFocus changes the appearance back.  WHen I hit Enter, one of the buttons definitely has focus.

No offense, but I don't think you know the answer.  I may sound like a beginner, but I am well aware of all of what you've said so far.  I wouldn't post a question after at least some fundamental investigation.
0
 
duneramCommented:
You don't necessarily know you have focus.  In windows, there is a period of time when no one has focus (its quick).  You can do a get focus to see if it has but its the sort of thing that has to be trapped/logged and then reviewed to see what happened.
0
 
duneramCommented:
When you hit the tab key to change focus on a button, is there ever a time when none of your controls have the focus (none of your buttons?)  ?   If so, then there must be a control somewhere else on your dialog, perhaps underneath another one, or off the visible portion of the dialog.
0
 
duneramCommented:
no offense taken.  No I was trying to evaluate your problem based on the information you gave me.   And I was able to reproduce this via two methods, but you have stated  neither of those methods holds true.   so yes I don't have the answer at this point in time.
0
 
duneramCommented:
no offense taken.  No I was trying to evaluate your problem based on the information you gave me.   And I was able to reproduce this via two methods, but you have stated  neither of those methods holds true.   so yes I don't have the answer at this point in time.
0
 
rosborn051498Author Commented:
Sorry for the flame.  The things you pointed out are valid.  However, I did verify all of them and I'm still scratching my head.  I think it might have something to do with not updating the "default" button, which is normally set to the OK button by the dialog creation wizard.  Maybe the OnOK() is being called because MFC still thinks the OK button is the default.  Yet I do have indication that my buttons are getting focus, which I assume would override the default button.



0
 
rosborn051498Author Commented:
Interesting point:
I put the IDOK button back on and it's being called whenever Enter is hit (because it's the default button).  When I try to make one of my buttons the default, it removes the owner-draw attribute.  Seems they are mutually exclusive.  I'm investigating why.  If you find it, let me know.
0
 
PriyeshCommented:
Rosborn..
           You said you have removed your OK and Cancel buttons. I too have come across such a situation when my dialog will just disappear when i press the enter key. I don't know why.. maybe if i can trap it by seeing the WM_KEYDOWN for dialog or so.. but i shall tell u how i tackled the situation.. please try this on a separate dialog and verify for u'rself. Don't remove the default OK button this time. just set the visibility off and also disable the button through the properties.. And try pressing enter key when u launch this dialog.. (be careful, if u started with a new dialog based app, u might have the cancel button with focus and this might cause u'r dialog disappear even after u disabled the ok button. Just remove the cancel button or place some more buttons as u have CBitmapbutton objects in u'r case.. ) Try this and i will be glad if u let me know abt any progress.. I think  even if the OK button is not there, the CDialog OnOK is called for enter key in the dialog.. Anyway.. tell me u'r view abt this and if this technique solves u'r problem, we both are happy..
       Good luck..
0
 
rosborn051498Author Commented:
The dialog ends without handling OnKeyDown().  Also, if I set the IDOK button to disabled and hit enter, it doesn't quit but it beeps at me.  Beter, but not quite there.  My buttons still don't fire their On() events.  I really think it has something to do with an owner-drawn button not getting full focus.  Like I said, owner-draw and Default are mutually exclusive.  Has to be related to this problem.
0
 
rosborn051498Author Commented:
See above comment for rejection reason.
0
 
duneramCommented:
Rosborn, just a quick side, have you tried handling  CWnd::OnSysKeyDown or CWnd::OnSysChar ?  
0
 
rosborn051498Author Commented:
Interesting twist #23:
Here's further evidence that button gets focus:
When I set focus to a button and press space bar, it does as expected and calls the On() function for the button with focus.  Again, Enter doesn't do this.
0
 
rosborn051498Author Commented:
I'm handling PreTranslateMessage and dumping pMsg->message to debug window (TRACE).  I get WM_KEYDOWN and WM_KEYUP.  However, I also handle OnKeyDown, but don't get that.  CDialog is trapping the Enter key and translating it for me.
0
 
rosborn051498Author Commented:
I'm handling PreTranslateMessage and dumping pMsg->message to debug window (TRACE).  I get WM_KEYDOWN and WM_KEYUP.  However, I also handle OnKeyDown, but don't get that.  CDialog is trapping the Enter key and translating it for me.
0
 
duneramCommented:
i WENT and rebuilt a app from scratch. I deleted the OK and Cancel buttons.  I made 3 owner drawn buttons.  And noticed the behaviour.  Then I created the OK and Cancel buttons.  Also went to classwizard and created the handlers for them.   Next I went back to the dialog and removed the OK & Cancel buttons.   I went back to the handlers and stuck in this sort of code:

void CDdeddDlg::OnOK()
{
      char x[400];
      // TODO: Add extra validation here
      wsprintf(x,"OnOK %#0x\n", GetFocus());
      MessageBox(x,"OnOK",MB_OK);
}


in the dialog, I have no default push button:

    CONTROL         "Button1",IDC_BUTTON1,"Button",BS_OWNERDRAW | WS_TABSTOP,
                    64,45,50,14
    CONTROL         "Button2",IDC_BUTTON2,"Button",BS_OWNERDRAW | WS_TABSTOP,
                    80,20,50,14
    CONTROL         "Button3",IDC_BUTTON3,"Button",BS_OWNERDRAW | WS_TABSTOP,
                    7,24,50,14


Now when I hit the enter key, the dialog control passes thru this handler, I see my message box.  This seems to happen regardless of which one had the focus.   When I do a get focus, the control that has the focus gives me the value from the GetFocus api. You may see the same effect if the 'esc' key is entered too.  Hitting 'esc' triggers the cancel handler.

By doing the above stuff, I can identify which control has the focus and catch the 'enter key' event.
0
 
rosborn051498Author Commented:
Okay, that will work.  You earned it.  Still don't know why it doesn't work as expected, but this is an acceptable kluge.  Thanks for your help.
0
 
ritchiepCommented:
Future readers may also want to check out MSKB Q122489 "How to Disable Default Pushbutton Handling for MFC Dialog":
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q122489
0
 
JeanChretienCommented:
Also, future readers will want to make sure "default button" is unchecked on all buttons.  I had a headache trying to figure out why OnOK() was NOT called by default.  I thought enter always called it, no matter what the default button was.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now