Board index » cppbuilder » Trapping <ENTER> Key

Trapping <ENTER> Key


2005-08-26 11:51:11 PM
cppbuilder67
I have a simple application with a Form and a third party
dot matrix display (Ziegler). I have set the form's
KeyPreview to 'true' and use its OnKeyPress to grab
characters for the display. When alpha characters are
pressed, the go into the display message buffer. When the
<ENTER>key is pressed, I start the display. OK -- all's
fine.
But then I placed a Button on the Form to allow a 'Pause'
feature. Now when the user presses the <ENTER>key the
Button grabs focus and I can't see or trap <ENTER>in the
OnKeyPress handler any more. The Button does not need focus
because it simply toggles the Pause mode on or off with a
mouse click.
Is there some way to block this focus-grabbing property of
the Button which interferes with the key trapping in
OnKeyPress? Or do I have to create a new type of Button
component?
Any suggestions welcome!
 
 

Re:Trapping <ENTER> Key

"C. Bond" < XXXX@XXXXX.COM >wrote in message
Quote
But then I placed a Button on the Form to allow a 'Pause'
feature. Now when the user presses the <ENTER>key the
Button grabs focus and I can't see or trap <ENTER>in the
OnKeyPress handler any more.
Is the Button's 'Default' property set to true? When the 'Default' property
is true, TButton intercepts the <ENTER>key before the form does.
Gambit
 

Re:Trapping <ENTER> Key

Remy Lebeau (TeamB) wrote:
Quote
"C. Bond" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>But then I placed a Button on the Form to allow a 'Pause'
>feature. Now when the user presses the <ENTER>key the
>Button grabs focus and I can't see or trap <ENTER>in the
>OnKeyPress handler any more.

Is the Button's 'Default' property set to true? When the 'Default' property
is true, TButton intercepts the <ENTER>key before the form does.

Gambit
Thanks for your response. I checked the situation with a little more attention
to detail and found the following:
1) When a TButton is placed on a Form, the Default property is 'false'. In my
case, this property is false and stays false, even after the component has
grabbed Focus.
2) The TButton grabs Focus when is is first clicked (not when the user presses
the <ENTER>key, as I stated above). However, when the TButton is clicked and
grabs focus, the <ENTER>key is no longer passed to the OnKeyPress handler.
So the problem remains that once I click the TButton, I can no longer trap the
<ENTER>key from the Form's OnKeyPress handler. I checked the TButton's Default
property both before and after the TButton has focus, and it remains 'false' in
either case. I don't know if this behavior (interfering with key trapping) has
anything to do with Focus, but the TButton does not need any Focus to do its
job, and I can't find any way to workaround the problem.
 

{smallsort}

Re:Trapping <ENTER> Key

"C. Bond" < XXXX@XXXXX.COM >wrote in message
Quote
So the problem remains that once I click the TButton, I can no
longer trap the <ENTER>key from the Form's OnKeyPress
handler.
As it should be. That is how TButton is designed to work. As long as the
button remains focused, it acts as if the Default property were set to true.
One way to prevent it is to manually remove the focus after the button has
been clicked.
Quote
I don't know if this behavior (interfering with key trapping)
has anything to do with Focus
It does.
Quote
but the TButton does not need any Focus to do its job
Have you considered using a non-windowed button instead, such as
TSpeedButton? TSpeedButton derives from TGraphicControl instead of
TWinControl. Graphical controls cannot receive focus at all.
Gambit
 

Re:Trapping <ENTER> Key

Remy Lebeau (TeamB) wrote:
Quote
"C. Bond" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>So the problem remains that once I click the TButton, I can no
>longer trap the <ENTER>key from the Form's OnKeyPress
>handler.

As it should be. That is how TButton is designed to work. As long as the
button remains focused, it acts as if the Default property were set to true.
I'm not sure I understand why this is "should be" behavior (acting as if
theDefault property were true, even when it is still false.). However, I accept
that it is designed behavior.
Quote
One way to prevent it is to manually remove the focus after the button has
been clicked.
How? I did try several things, such as trying to force the Active control tothe
Form, removing the TButton as a Tab stop, but nothing seemed to work.
Quote
Have you considered using a non-windowed button instead, such as
TSpeedButton? TSpeedButton derives from TGraphicControl instead of
TWinControl. Graphical controls cannot receive focus at all.
This looks like the best solution! Using a TButton in the first place was kindof
a knee-jerk reaction on my part. I expected to just drop it on the form
and did not consider any interaction with the Form's OnKeyPress handler.
Thanks.
Quote
Gambit
 

Re:Trapping <ENTER> Key

"C. Bond" < XXXX@XXXXX.COM >wrote in message
Quote
This looks like the best solution! Using a TButton in the first place was
kindof
a knee-jerk reaction on my part. I expected to just drop it on the form
and did not consider any interaction with the Form's OnKeyPress handler.
Did you try calling SetFocus() on another control, or the form itself?
Gambit
 

Re:Trapping <ENTER> Key

Remy Lebeau (TeamB) wrote:
Quote
Did you try calling SetFocus() on another control, or the form itself?

Gambit
Both. That was the first thing I tried. I found that Button1->SetFocus() always
gives focus to the TButton (and if there are other TButtons you can switch
focus freely from one to the other), but once a TButton has focus
Form1->SetFocus() seems to do nothing. I haven't found any way to pry the Focus
loose from the TButton to the Form once it's there. This is confusing because
the document seems to imply that the Form->SetFocus() should remove focus from
other components.
By the way, I'm using C++Builder version 5.
I suppose if I understood the reasoning behind some of the VCL implementation
decisions I could do a better job of troubleshooting this. I thought that there
would be a way to simply monitor any keypress from the OnKeyPress handler, once
the KeyPreview was set to true. This is clearly not the case.
Any other suggestions?