Enter Key on Dialogs... 
Author Message
 Enter Key on Dialogs...

There are times when I have a dialog box with say, an edit box for user
entry.  When the user presses the 'enter' key, I don't want that to be
taken as an 'Ok' button, which seems to be the default.  I may want to
perform another function, such as a 'search' function on a database
which then populates a listbox, or other control on the dialog.  What's
the best way or set of MFC functions to look at to achieve this
'override'?

Paul



Mon, 27 Oct 2003 03:00:52 GMT  
 Enter Key on Dialogs...

Quote:
>There are times when I have a dialog box with say, an edit box for user
>entry.  When the user presses the 'enter' key, I don't want that to be
>taken as an 'Ok' button, which seems to be the default.  I may want to
>perform another function, such as a 'search' function on a database
>which then populates a listbox, or other control on the dialog.

Paul,

Does your dialog have a "search" button? If it does, make that the
default button when the focus is on that edit control.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.



Mon, 27 Oct 2003 03:30:30 GMT  
 Enter Key on Dialogs...
This question (or very similar questions) get asked very often. It seems
they are asked nearly once a day.

There are many possible solutions. If there is nothing to be done by the
dialog when the "Ok" button is pushed except to end the dialog, then the
easiest solution is to put the processing you want to do when the enter key
is pressed in the OnOk override and remove the call to CDialog::OnOk from
the override. Then you could simply chage the text of the button to
something more relevant. There are variations of this that would also work.

If you want to make the processing of the enter key to be unique to a
control or controls, then you can process the enter key in classes derived
from the MFC class for the control(s). See:

http://www.cpp.atfreeweb.com/KbdMessagesControls.html


Quote:

> There are times when I have a dialog box with say, an edit box for user
> entry.  When the user presses the 'enter' key, I don't want that to be
> taken as an 'Ok' button, which seems to be the default.  I may want to
> perform another function, such as a 'search' function on a database
> which then populates a listbox, or other control on the dialog.  What's
> the best way or set of MFC functions to look at to achieve this
> 'override'?

> Paul



Mon, 27 Oct 2003 03:29:56 GMT  
 Enter Key on Dialogs...

Quote:

> This question (or very similar questions) get asked very often. It seems
> they are asked nearly once a day.

Thanks for the advice, and I had a feeling it would be a common conundrum to
novices in MFC, of which I am one.  :)  No monaural recordings of the Beatles
here.

Quote:
> There are many possible solutions. If there is nothing to be done by the
> dialog when the "Ok" button is pushed except to end the dialog, then the
> easiest solution is to put the processing you want to do when the enter key
> is pressed in the OnOk override and remove the call to CDialog::OnOk from
> the override. Then you could simply chage the text of the button to
> something more relevant. There are variations of this that would also work.

I had thought of this, but it just didn't seem sporting of me to make the
'OnOk' function do the searching, when I figgered I still wanted it to act as
the dialog terminator from which results would be received by the main program.

Quote:
> If you want to make the processing of the enter key to be unique to a
> control or controls, then you can process the enter key in classes derived
> from the MFC class for the control(s). See:

> http://www.cpp.atfreeweb.com/KbdMessagesControls.html

I'm heading there right now.  Thanks, Sam.

Paul



Mon, 27 Oct 2003 05:33:25 GMT  
 Enter Key on Dialogs...

Quote:

> Does your dialog have a "search" button? If it does, make that the
> default button when the focus is on that edit control.

Actually, yes, that was my thinking, although I was not explicit in my
original post.  This seems the most straightforward, I guess I am unaware of
the API or MFC function which would shift the 'default' mechanism to my
button of choice, but now that I know there is one, I can probably go find
it.

Thanks for the tips, all.

Paul



Mon, 27 Oct 2003 05:36:43 GMT  
 Enter Key on Dialogs...

Quote:
>> Does your dialog have a "search" button? If it does, make that the
>> default button when the focus is on that edit control.

>Actually, yes, that was my thinking, although I was not explicit in my
>original post.  This seems the most straightforward, I guess I am unaware of
>the API or MFC function which would shift the 'default' mechanism to my
>button of choice, but now that I know there is one, I can probably go find
>it.

Paul,

Have a look at Knowledge Base article Q67655 "Changing/Setting the
Default Push Button in a Dialog Box".

Here's the crux of the technique:

1. Send the BM_SETSTYLE message to the current default push button to
   change its border to that of a regular push button.

2. Send a DM_SETDEFID message to the dialog box to change the ID of
   the default push button.

3. Send the BM_SETSTYLE message to the new default push button to
   change its border to that of a default push button.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.



Mon, 27 Oct 2003 06:34:43 GMT  
 Enter Key on Dialogs...
Pablo(tm)

From a philosophical viewpoint, OK is OK, whatever processing it will do
(conceptually) is of course dependent on your app. Ah, the times I have
renamed "OK" to "Search" or "Process" or whatever appropriate, and skipped
the default OnOK-handling - and renamed "Cancel" to "Close". *I* find it
clean, architecturally (c.a 200 b.c. but I *have* been doing maintenance
programming, and is concious about such matters...)

Johan Rosengren
Responsable Informatique
PACTA S.A.


Quote:

> There are times when I have a dialog box with say, an edit box for user
> entry.  When the user presses the 'enter' key, I don't want that to be
> taken as an 'Ok' button, which seems to be the default.  I may want to
> perform another function, such as a 'search' function on a database
> which then populates a listbox, or other control on the dialog.  What's
> the best way or set of MFC functions to look at to achieve this
> 'override'?

> Paul



Mon, 27 Oct 2003 12:27:41 GMT  
 Enter Key on Dialogs...
Yeah, true.
and lots of people rename Cancel to Exit on dialog based apps

Nish


Quote:
> Pablo(tm)

> From a philosophical viewpoint, OK is OK, whatever processing it will do
> (conceptually) is of course dependent on your app. Ah, the times I have
> renamed "OK" to "Search" or "Process" or whatever appropriate, and skipped
> the default OnOK-handling - and renamed "Cancel" to "Close". *I* find it
> clean, architecturally (c.a 200 b.c. but I *have* been doing maintenance
> programming, and is concious about such matters...)

> Johan Rosengren
> Responsable Informatique
> PACTA S.A.



> > There are times when I have a dialog box with say, an edit box for user
> > entry.  When the user presses the 'enter' key, I don't want that to be
> > taken as an 'Ok' button, which seems to be the default.  I may want to
> > perform another function, such as a 'search' function on a database
> > which then populates a listbox, or other control on the dialog.  What's
> > the best way or set of MFC functions to look at to achieve this
> > 'override'?

> > Paul



Mon, 27 Oct 2003 14:46:29 GMT  
 Enter Key on Dialogs...

Quote:

> Pablo(tm)

> From a philosophical viewpoint, OK is OK, whatever processing it will do
> (conceptually) is of course dependent on your app. Ah, the times I have
> renamed "OK" to "Search" or "Process" or whatever appropriate, and skipped
> the default OnOK-handling - and renamed "Cancel" to "Close". *I* find it
> clean, architecturally (c.a 200 b.c. but I *have* been doing maintenance
> programming, and is concious about such matters...)

But the problem I see with this approach, is it makes things extremely easy,
clear and concise.  Isn't it more impressive to have obtuse, complex code with
lots of non-default handling, redirection, indirection, and most important of
all, full of useless features?  I always believed in simplicity and where's
that gotten me?  A dead end job in legacy programming where I'm
'over-experienced' and 'underskilled'.

Sorry, didn't mean to come off bitter.  I do like your approach, though,
seriously.  Besides, my reference books are at home and when I tried
redirecting the default control, I got some strange behaviour, and I could
only find an example of use for the Win32 equivalent of SendDlgItemMessage(),
but what I condsidered to be inadequate explanations of the available
parameters for the MFC version.  Either that, or I just don't know what I'm
doing yet.  Take your pick.

Paul



Tue, 28 Oct 2003 02:34:48 GMT  
 Enter Key on Dialogs...
Hello, you could do this:
In your dialog class, override the OnOK function. Make it do nothing, or make
it do whatever you want, but DON'T call the CDialog::OnOK. Now for you OK
button on the dialog, change the ID to something like IDC_OK, and remove the
default check (using the resource editor). Map IDC_OK to a function like
OnOKButton()
and call CDialog::OnOk with it. Now you can use your overriden OnOK function to
do whatever processing you want when enter is depressed.

Ed

Quote:

> This question (or very similar questions) get asked very often. It seems
> they are asked nearly once a day.

> There are many possible solutions. If there is nothing to be done by the
> dialog when the "Ok" button is pushed except to end the dialog, then the
> easiest solution is to put the processing you want to do when the enter key
> is pressed in the OnOk override and remove the call to CDialog::OnOk from
> the override. Then you could simply chage the text of the button to
> something more relevant. There are variations of this that would also work.

> If you want to make the processing of the enter key to be unique to a
> control or controls, then you can process the enter key in classes derived
> from the MFC class for the control(s). See:

> http://www.cpp.atfreeweb.com/KbdMessagesControls.html



> > There are times when I have a dialog box with say, an edit box for user
> > entry.  When the user presses the 'enter' key, I don't want that to be
> > taken as an 'Ok' button, which seems to be the default.  I may want to
> > perform another function, such as a 'search' function on a database
> > which then populates a listbox, or other control on the dialog.  What's
> > the best way or set of MFC functions to look at to achieve this
> > 'override'?

> > Paul



Tue, 28 Oct 2003 04:01:03 GMT  
 Enter Key on Dialogs...

Quote:

> Now for you OK
> button on the dialog, change the ID to something like IDC_OK, and remove the
> default check (using the resource editor). Map IDC_OK to a function like
> OnOKButton()
> and call CDialog::OnOk with it. Now you can use your overriden OnOK function to
> do whatever processing you want when enter is depressed.

Why do I change the id to IDC_OK?  I did a quick test by simply overriding the OnOK
function (and not calling CDialog::OnOk) and everything worked fine.  Am I in for
some unexpected behaviour?

Paul



Tue, 28 Oct 2003 05:19:32 GMT  
 Enter Key on Dialogs...
Why is that better than the following:

(1) Remove the "default" style from the "Ok" button and leave whatever
processing is needed in the IDOK handler (I think Paul said he already had
some processing in his OnOk)

(2) Make another button the default

Also, using this technique, I think there would need to be at least one
additional step; another button would need to be created that would be made
the default button; right? Also, how would the overriden OnOK function be
executed? Perhaps it would be executed by the other button.



Quote:
> Hello, you could do this:
> In your dialog class, override the OnOK function. Make it do nothing, or
make
> it do whatever you want, but DON'T call the CDialog::OnOK. Now for you OK
> button on the dialog, change the ID to something like IDC_OK, and remove
the
> default check (using the resource editor). Map IDC_OK to a function like
> OnOKButton()
> and call CDialog::OnOk with it. Now you can use your overriden OnOK
function to
> do whatever processing you want when enter is depressed.

> Ed


> > This question (or very similar questions) get asked very often. It seems
> > they are asked nearly once a day.

> > There are many possible solutions. If there is nothing to be done by the
> > dialog when the "Ok" button is pushed except to end the dialog, then the
> > easiest solution is to put the processing you want to do when the enter
key
> > is pressed in the OnOk override and remove the call to CDialog::OnOk
from
> > the override. Then you could simply chage the text of the button to
> > something more relevant. There are variations of this that would also
work.

> > If you want to make the processing of the enter key to be unique to a
> > control or controls, then you can process the enter key in classes
derived
> > from the MFC class for the control(s). See:

> > http://www.cpp.atfreeweb.com/KbdMessagesControls.html



> > > There are times when I have a dialog box with say, an edit box for
user
> > > entry.  When the user presses the 'enter' key, I don't want that to be
> > > taken as an 'Ok' button, which seems to be the default.  I may want to
> > > perform another function, such as a 'search' function on a database
> > > which then populates a listbox, or other control on the dialog.
What's
> > > the best way or set of MFC functions to look at to achieve this
> > > 'override'?

> > > Paul



Tue, 28 Oct 2003 05:48:41 GMT  
 Enter Key on Dialogs...


Quote:


> > Pablo(tm)

<snip>

Quote:

> But the problem I see with this approach, is it makes things extremely
easy,
> clear and concise.  Isn't it more impressive to have obtuse, complex code
with
> lots of non-default handling, redirection, indirection, and most important
of
> all, full of useless features?  I always believed in simplicity and
where's
> that gotten me?  A dead end job in legacy programming where I'm
> 'over-experienced' and 'underskilled'.

Then you ought to appreciate clean code in the legacy project at least :-)
Actually, as it is so easy to write obtuse code, noone except fresh
programmers and students are impressed.

As you have expressed yourself being age-handicapped (that is, a young
fart), you are *supposed* to have crummy jobs until you reach a mature age
(that is, older than your project leader).

Quote:
> Sorry, didn't mean to come off bitter.  I do like your approach, though,
> seriously.  Besides, my reference books are at home and when I tried
> redirecting the default control, I got some strange behaviour, and I could
> only find an example of use for the Win32 equivalent of

SendDlgItemMessage(),

Quote:
> but what I condsidered to be inadequate explanations of the available
> parameters for the MFC version.  Either that, or I just don't know what
I'm
> doing yet.  Take your pick.

There are many ways to skin a cat (some including closed boxes where the cat
is both skinned and unskinned until you look).

In Win32, there is no  notion of "OK"-buttons, that is an MFC-construct,
even though default buttons are of course there. For me, and for that
reason, the OK-button is just a convenient default button, with some
default-handling that is not always appropriate.

Johan Rosengren
Responsable Informatique
PACTA S.A.



Tue, 28 Oct 2003 17:13:20 GMT  
 Enter Key on Dialogs...
Hello. My answer assumed that you still want an OK button. By changing its ID and
unchecking it as the default, and mapping it to a handler that you create, and calling
CDialog::OnOK() within it, you get the normal modal closure for ONLY when the OK button
is depressed. Your override of OnOK, meanwhile, is still mapped to IDOK, so everytime
you press enter in your dialog, your overriden OnOK handler is called, and this is
where you would do whatever you wanted to do when enter was pressed in a control. First
you override OnOK in your dialog class. Then you make the other changes. I'm assuming
that you want an OK button to close the dialog and write to your dialog class's member
variables, and that you also want specific things to happen when enter is depressed,
and an overidden OnOK still mapped to IDOK is perfect for this. If all you've done is
comment out the CDialog::OnOK() call in your overriden OnOK function, then you will
have problems with DDX function updates. Specifically, the call to CDialog::OnOK() ends
up calling UpdateData with a TRUE, which causes the DDX functions to write (and
validate) the control values to the dialog's member variables.

Ed

Quote:


> > Now for you OK
> > button on the dialog, change the ID to something like IDC_OK, and remove the
> > default check (using the resource editor). Map IDC_OK to a function like
> > OnOKButton()
> > and call CDialog::OnOk with it. Now you can use your overriden OnOK function to
> > do whatever processing you want when enter is depressed.

> Why do I change the id to IDC_OK?  I did a quick test by simply overriding the OnOK
> function (and not calling CDialog::OnOk) and everything worked fine.  Am I in for
> some unexpected behaviour?

> Paul



Wed, 29 Oct 2003 02:08:57 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Enter key on dialog embedded in dialog not doing OnOK

2. Enter key cause dialog app to exit

3. Trapping ESC, ENTER key for dialogs

4. Enter key on dialogs

5. Disabling Enter key on Dialog Based Application

6. Enter key causes dialog app to exit

7. enter key and dialog box

8. Disable Enter Key on Dialog Box

9. how to capture the ENTER key in dialog window?

10. trapping the enter key in a dialog app

11. Enter Key behaviour in Dialog

12. Dialog closes on Enter Key Down

 

 
Powered by phpBB® Forum Software