Keypress Event on Control

[croy]

After setting the keypress event on a textbox control (my
"special" control), and adding code to react to pressing the
Enter key or the "+" key, I see that the reaction is
happening before the control even gets the focus, or so it
appears.

I'm trying to set up the control to act as a close button if
it has the focus and the Enter key is pressed, or to simply
go to the next control if it has the focus and the "+" key
is pressed.

But when the focus is on the control ahead of this one, and
the Enter key is pressed to move to my "special" control,
the form closes, and I never see my special control get the
focus.

Is there any way to make the keypress event for this control
wait until it has the focus AND the Enter key is pressed?

 

[Dirk Goldgar]

In

After setting the keypress event on a textbox control (my
"special" control), and adding code to react to pressing the
Enter key or the "+" key, I see that the reaction is
happening before the control even gets the focus, or so it
appears.

I'm trying to set up the control to act as a close button if
it has the focus and the Enter key is pressed, or to simply
go to the next control if it has the focus and the "+" key
is pressed.

But when the focus is on the control ahead of this one, and
the Enter key is pressed to move to my "special" control,
the form closes, and I never see my special control get the
focus.

Is there any way to make the keypress event for this control
wait until it has the focus AND the Enter key is pressed?

The keystrokes (Enter, Tab) that transfer focus to another control get
passed to the next control's KeyPress event. Here are two different
ways to solve the probem:

1. Use your "special" control's KeyDown event instead of KeyPress. The
KeyDown event fires before the KeyPress event and traps the keycode,
which may be different from the ASCII code.

OR

2. Set your special control's EnterKeyBehavior property (on the Other
tab of its property sheet) to "New Line in Field". Then the Enter key
won't be transferring the focus to the next control, so this control
will get the KeyPress event.

 

[croy]

In

The keystrokes (Enter, Tab) that transfer focus to another control get
passed to the next control's KeyPress event. Here are two different
ways to solve the probem:

1. Use your "special" control's KeyDown event instead of KeyPress. The
KeyDown event fires before the KeyPress event and traps the keycode,
which may be different from the ASCII code.

OR

2. Set your special control's EnterKeyBehavior property (on the Other
tab of its property sheet) to "New Line in Field". Then the Enter key
won't be transferring the focus to the next control, so this control
will get the KeyPress event.

Thanks Dirk. I'll try your KeyDown approach first.

 

[croy]

In

The keystrokes (Enter, Tab) that transfer focus to another control get
passed to the next control's KeyPress event. Here are two different
ways to solve the probem:

1. Use your "special" control's KeyDown event instead of KeyPress. The
KeyDown event fires before the KeyPress event and traps the keycode,
which may be different from the ASCII code.

OR

2. Set your special control's EnterKeyBehavior property (on the Other
tab of its property sheet) to "New Line in Field". Then the Enter key
won't be transferring the focus to the next control, so this control
will get the KeyPress event.

Hmmm. I tried 1 (above), but I'm not seeing any change in
key behavior.

On this field, the last in a row, I decided to let the Enter
key do its normal thing, and put a special use on the "+"
key. The goal is if no fields have been changed, close the
form. But it doesn't seem to work. Still getting "+" in
the field, and form not closing. Here's my code for the
KeyDown event:

Private Sub txtRemark_KeyDown(KeyCode As Integer, Shift As
Integer)

*****
Select Case KeyAscii
Case vbKeyAdd ' ("+")
KeyCode = 0

If Me.NewRecord Then
Me.Undo
DoCmd.Close
End If

End Select

End Sub
*****

I'm guessing at the "KeyCode = 0" part--assuming that is a
way to substitute different data for what would normally be
entered into the field ("+").

Now that I look at the code again, I think my method of
assessing whether or not any fields were updated is off the
mark. But even so, the "+" should not be going into the
field. I must be doing something fundamentally wrong.

Thanks for your reply, by the way. Hopefully I'm getting
closer...

 

[Dirk Goldgar]

In

Hmmm. I tried 1 (above), but I'm not seeing any change in
key behavior.

On this field, the last in a row, I decided to let the Enter
key do its normal thing, and put a special use on the "+"
key. The goal is if no fields have been changed, close the
form. But it doesn't seem to work. Still getting "+" in
the field, and form not closing. Here's my code for the
KeyDown event:

Private Sub txtRemark_KeyDown(KeyCode As Integer, Shift As
Integer)

*****
Select Case KeyAscii
Case vbKeyAdd ' ("+")
KeyCode = 0

If Me.NewRecord Then
Me.Undo
DoCmd.Close
End If

End Select

End Sub
*****

I'm guessing at the "KeyCode = 0" part--assuming that is a
way to substitute different data for what would normally be
entered into the field ("+").

Now that I look at the code again, I think my method of
assessing whether or not any fields were updated is off the
mark. But even so, the "+" should not be going into the
field. I must be doing something fundamentally wrong.

Thanks for your reply, by the way. Hopefully I'm getting
closer...

Your code references the name KeyAscii, but that's not the name of the
key argument passed to the KeyDown event. KeyDown receives the KeyCode
argument; not "KeyAscii" because it's not an ASCII code. If you had
Option Explicit set, as you should <waggles finger admonishingly>, your
code wouldn't have compiled and you'd have seen what's wrong.

This version of the code works just fine for me:

'----- start of amended code -----
Private Sub txtRemark_KeyDown(KeyCode As Integer, Shift As Integer)

Select Case KeyCode
Case vbKeyAdd ' ("+")
KeyCode = 0

If Me.NewRecord Then
Me.Undo
DoCmd.Close acForm, Me.Name, acSaveNo
End If

End Select

End Sub
'----- end of amended code -----

Note that the Sub's header line will probably have been broken onto two
lines by the newsreader, but was originally on one line.

By the way, as written, this code will only close the form if it is on a
new record. If that's not what you want, you must take the DoCmd.Close
statement out of the "If Me.NewRecord" block.

 

[croy]

In



Your code references the name KeyAscii, but that's not the name of the
key argument passed to the KeyDown event. KeyDown receives the KeyCode
argument; not "KeyAscii" because it's not an ASCII code. If you had
Option Explicit set, as you should <waggles finger admonishingly>, your
code wouldn't have compiled and you'd have seen what's wrong.

This version of the code works just fine for me:

'----- start of amended code -----
Private Sub txtRemark_KeyDown(KeyCode As Integer, Shift As Integer)

Select Case KeyCode
Case vbKeyAdd ' ("+")
KeyCode = 0

If Me.NewRecord Then
Me.Undo
DoCmd.Close acForm, Me.Name, acSaveNo
End If

End Select

End Sub
'----- end of amended code -----

Note that the Sub's header line will probably have been broken onto two
lines by the newsreader, but was originally on one line.

By the way, as written, this code will only close the form if it is on a
new record. If that's not what you want, you must take the DoCmd.Close
statement out of the "If Me.NewRecord" block.

You're fast! <g> I rescinded my message because I realized
the KeyAscii mistake... but not fast enought to beat you!

Sorry to run you around needlessly, but thanks for the
reinforcement. I think I'm on my way again.


Oh, by the way, what is the "Shift as Integer" part of the
argument? Something to do with the Shift key, or shifting
something around?

 

[Dirk Goldgar]

In

Oh, by the way, what is the "Shift as Integer" part of the
argument? Something to do with the Shift key, or shifting
something around?

It's a bit mask reflecting the state of the Shift, Alt, and Control
keys. It allows you to distinguish, for example, among A, Shift+A,
Alt+A, Ctrl+A, Ctrl+Alt+A, etc.

There used to be a more complete discussion of it in the online help,
but I can't find it any more, so it may have been dropped from the
files. However, my help file's "KeyDown Event" topic includes an
example that shows how to interrogate the Shift argument to tell whether
one of those keys was pressed.