473,394 Members | 1,769 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,394 software developers and data experts.

How can I throw out (handle) an ENTER keypress for an AcceptButton?

I have noticed that if a user closes a form via pressing return (either
while the OK button has focus or if AcceptButton is set to OK for the form)
then the "ENTER" keypress event fires ON THE CALLING FORM! This is very bad
for me, because in my application, Form1 responds to an ENTER keypress by
calling Form2. If the user closes Form2 via an ENTER, then Form1 just
reopens it again, kind of trapping the user in Form2 (they can still close
it from the X, of course).

Does anyone know of a way to prevent this? I need to somehow throw out or
"handle" the enter keypress in Form1, but ONLY if it "came from" Form2.

Any help would be appreciated,
AJ
Nov 21 '05 #1
15 3999
you have form1 opening form2 - which has an "ok" button as an acceptbutton -
but when user hits enter key, form 1 opens up form3? does that more
accurately describe it?

if this is the case, have you tried opening form2 modally?

hth,

steve
"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:OR**************@TK2MSFTNGP14.phx.gbl...
|I have noticed that if a user closes a form via pressing return (either
| while the OK button has focus or if AcceptButton is set to OK for the
form)
| then the "ENTER" keypress event fires ON THE CALLING FORM! This is very
bad
| for me, because in my application, Form1 responds to an ENTER keypress by
| calling Form2. If the user closes Form2 via an ENTER, then Form1 just
| reopens it again, kind of trapping the user in Form2 (they can still close
| it from the X, of course).
|
| Does anyone know of a way to prevent this? I need to somehow throw out or
| "handle" the enter keypress in Form1, but ONLY if it "came from" Form2.
|
| Any help would be appreciated,
| AJ
|
|
Nov 21 '05 #2
Adam,
Can you post (or email) an example of this, as I am not able to recreate it.

Using the following:

Public Class Form1
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

Private Sub Form1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles MyBase.KeyPress
If e.KeyChar = ControlChars.Cr Then
Dim dialog As New Form2
dialog.ShowDialog(Me)
dialog.Dispose()
End If
End Sub

End Class

Public Class Form2
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

End Class

I only see Form2 once when I press the Enter key. The above is VS.NET 2003
(.NET 1.1 SP1) on Windows XP SP2.

Form1 is a blank form, I tried both KeyPreview=True & KeyPreview=False.
Form2 only has Button1, Form2.AcceptButton = Button1.

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:OR**************@TK2MSFTNGP14.phx.gbl...
I have noticed that if a user closes a form via pressing return (either
while the OK button has focus or if AcceptButton is set to OK for the
form)
then the "ENTER" keypress event fires ON THE CALLING FORM! This is very
bad
for me, because in my application, Form1 responds to an ENTER keypress by
calling Form2. If the user closes Form2 via an ENTER, then Form1 just
reopens it again, kind of trapping the user in Form2 (they can still close
it from the X, of course).

Does anyone know of a way to prevent this? I need to somehow throw out or
"handle" the enter keypress in Form1, but ONLY if it "came from" Form2.

Any help would be appreciated,
AJ

Nov 21 '05 #3
Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note that
the breakpoint in form1 gets hit! I don't understand why, since enter was
pressed while form2 was open. More importantly, I don't understand how to
prevent it.

p.s. framework v1.1, windows xp-sp2
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ud*************@TK2MSFTNGP10.phx.gbl...
Adam,
Can you post (or email) an example of this, as I am not able to recreate it.
Using the following:

Public Class Form1
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

Private Sub Form1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles MyBase.KeyPress
If e.KeyChar = ControlChars.Cr Then
Dim dialog As New Form2
dialog.ShowDialog(Me)
dialog.Dispose()
End If
End Sub

End Class

Public Class Form2
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

End Class

I only see Form2 once when I press the Enter key. The above is VS.NET 2003
(.NET 1.1 SP1) on Windows XP SP2.

Form1 is a blank form, I tried both KeyPreview=True & KeyPreview=False.
Form2 only has Button1, Form2.AcceptButton = Button1.

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:OR**************@TK2MSFTNGP14.phx.gbl...
I have noticed that if a user closes a form via pressing return (either
while the OK button has focus or if AcceptButton is set to OK for the
form)
then the "ENTER" keypress event fires ON THE CALLING FORM! This is very
bad
for me, because in my application, Form1 responds to an ENTER keypress by calling Form2. If the user closes Form2 via an ENTER, then Form1 just
reopens it again, kind of trapping the user in Form2 (they can still close it from the X, of course).

Does anyone know of a way to prevent this? I need to somehow throw out or "handle" the enter keypress in Form1, but ONLY if it "came from" Form2.

Any help would be appreciated,
AJ


Nov 21 '05 #4
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
Dim f As New Form2
f.ShowDialog() End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter (or
Space) when Form1.Button1 has the focus & doesn't have the focus. Also watch
when there are other controls earlier & later in the tab order on Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus & does
the Click event, Form1.Button1 now has the focus, so Form1.Button1.KeyUp
event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the Form1.Button1.KeyUp
event, or if you do need to handle it, make sure you know when the event is
occurring as part of the Click event or another event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl... Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note
that
the breakpoint in form1 gets hit! I don't understand why, since enter was
pressed while form2 was open. More importantly, I don't understand how to
prevent it.

p.s. framework v1.1, windows xp-sp2

<<snip>>
Nov 21 '05 #5
Jay,

The debug statements were a great idea. However, I appear to have confused
things with my sample application, which was only designed to illustrate
that Form1 was receiving a KeyUp from a key press that occurred on Form2.
Perhaps you're used to this, but it was an unpleasant surprise for me.

So let me start over with a sample that more closely mirrors my real
application. My app starts with Form1 which has a textbox on it. I want to
display Form2 if the user presses Enter while in the textbox. I'm using the
KeyUp event of the textbox for that. Form2 has an OK button, and has its
AcceptButton set to that OK button. The scenario runs like this:

1. App starts, Form1 is shown, the textbox has focus
2. The user presses Enter. Form2 is then shown modally.
3. The user does his thing on Form2 and then presses Enter, expecting to be
returned to Form1.

Here is the sequence of events for step 3:

a. No KeyDown or KeyPress events fire. Presumably, by setting the
AcceptButton property of Form2, it is now intercepting and "handling" those
events.
b. The Click event of the OK button on Form2 fires, which closes Form2.
c. The KeyUp event of TextBox1 on Form1 fires, which, as described above,
launches Form2.

The user is confused. He pressed enter, he saw Form2 unload, but then it
reloaded immediately. If he presses Enter again, then it repeats (Form2
closes and reopens).

I guess I can work around this by using the KeyDown or KeyPress events. I
don't like them as much as KeyUp, because KeyUp is guaranteed to only fire
once per key press, whereas the others can fire over and over (if the user
holds the button down), but they suddenly seem a lot safer in light of this
issue.

What I was hoping was that there might be some way that I could prevent the
KeyUp event from happening. Not handle it, mind you, because by then I'm in
Form1 and I can't tell a "good" KeyUp from a bad one. But if I could somehow
intercept and clear it, say from the Closing event of my Form2, that would
be cool.

You see, the bigger issue here is how can I defend one window from events
caused by a user who is in another window? Unwanted KeyUp and/or MouseUp
events can be a rude surprise. It would be nice if there was some way for a
form that was closing to say "throw away any outstanding KeyUp or MouseUp
events that have not occurred yet".

Thanks again for your help,
-AJ

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eQ*************@TK2MSFTNGP11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
Dim f As New Form2
f.ShowDialog()

End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter
(or Space) when Form1.Button1 has the focus & doesn't have the focus. Also
watch when there are other controls earlier & later in the tab order on
Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus & does
the Click event, Form1.Button1 now has the focus, so Form1.Button1.KeyUp
event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the Form1.Button1.KeyUp
event, or if you do need to handle it, make sure you know when the event
is occurring as part of the Click event or another event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note
that
the breakpoint in form1 gets hit! I don't understand why, since enter was
pressed while form2 was open. More importantly, I don't understand how to
prevent it.

p.s. framework v1.1, windows xp-sp2

<<snip>>

Nov 21 '05 #6
On Mon, 25 Oct 2004 21:06:46 -0400, Adam J. Schaff wrote:
Jay,

The debug statements were a great idea. However, I appear to have confused
things with my sample application, which was only designed to illustrate
that Form1 was receiving a KeyUp from a key press that occurred on Form2.
Perhaps you're used to this, but it was an unpleasant surprise for me.

So let me start over with a sample that more closely mirrors my real
application. My app starts with Form1 which has a textbox on it. I want to
display Form2 if the user presses Enter while in the textbox. I'm using the
KeyUp event of the textbox for that. Form2 has an OK button, and has its
AcceptButton set to that OK button. The scenario runs like this:

1. App starts, Form1 is shown, the textbox has focus
2. The user presses Enter. Form2 is then shown modally.
3. The user does his thing on Form2 and then presses Enter, expecting to be
returned to Form1.

Here is the sequence of events for step 3:

a. No KeyDown or KeyPress events fire. Presumably, by setting the
AcceptButton property of Form2, it is now intercepting and "handling" those
events.
b. The Click event of the OK button on Form2 fires, which closes Form2.
c. The KeyUp event of TextBox1 on Form1 fires, which, as described above,
launches Form2.

The user is confused. He pressed enter, he saw Form2 unload, but then it
reloaded immediately. If he presses Enter again, then it repeats (Form2
closes and reopens).

I guess I can work around this by using the KeyDown or KeyPress events. I
don't like them as much as KeyUp, because KeyUp is guaranteed to only fire
once per key press, whereas the others can fire over and over (if the user
holds the button down), but they suddenly seem a lot safer in light of this
issue.

What I was hoping was that there might be some way that I could prevent the
KeyUp event from happening. Not handle it, mind you, because by then I'm in
Form1 and I can't tell a "good" KeyUp from a bad one. But if I could somehow
intercept and clear it, say from the Closing event of my Form2, that would
be cool.

You see, the bigger issue here is how can I defend one window from events
caused by a user who is in another window? Unwanted KeyUp and/or MouseUp
events can be a rude surprise. It would be nice if there was some way for a
form that was closing to say "throw away any outstanding KeyUp or MouseUp
events that have not occurred yet".

Thanks again for your help,
-AJ

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eQ*************@TK2MSFTNGP11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
Dim f As New Form2
f.ShowDialog()

End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter
(or Space) when Form1.Button1 has the focus & doesn't have the focus. Also
watch when there are other controls earlier & later in the tab order on
Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus & does
the Click event, Form1.Button1 now has the focus, so Form1.Button1.KeyUp
event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the Form1.Button1.KeyUp
event, or if you do need to handle it, make sure you know when the event
is occurring as part of the Click event or another event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note
that
the breakpoint in form1 gets hit! I don't understand why, since enter was
pressed while form2 was open. More importantly, I don't understand how to
prevent it.

p.s. framework v1.1, windows xp-sp2

<<snip>>


I created a very small project. It has two forms. On Form1, I placed a
single textbox. It's keyup handler is shown below:

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
Dim f As New Form2
Debug.WriteLine("Form1: TextBox1: KeyUp")
f.ShowDialog()
f.Dispose
End If
End Sub

On Form2 I placed a single button. I then set the AcceptButton propert of
Form2 to be the button. I added the following code to the Button's click
event:

Private Sub Button1_Click(...) Handles Button1.Click
Debug.WriteLine("Form2: Button1: Click")
Me.Close()
End Sub

When I fire up the program, Form1 appears with the textbox having focus
(since it is the only control on the form). I press enter and Form2
appears. I press enter again which causes the button on form2 to be
clicked which closes form2. Form2 immediately reappears!!

The following text appears in the output windows:

Form1: TextBox1: KeyUp
Form2: Button1: Click
Form1: TextBox1: KeyUp

Where is that extra KeyUp event coming from? When I pressed Enter, *FORM2*
had focus, form1 should not have gotten a keypress from form2!!

What appears to be happening is that the AcceptButton is being triggered
when the key goes down, which closes the form, but then the key up occurs
after form2 has been closed so the keyup goes to the only form which has
focus: Form1, which, of course, opens form2 again!

While, perhaps, its behavior is undesired, it is logical. The only
workaround I could think of was by adding a boolean flag that is set right
after form2 is closed and checking that flag on entering the keyup event.
If set, don't show form2 again:

'Global boolean
Dim bForm2JustClosed As Boolean

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
'If Form2 just closed, then ignore this KeyUp for the Enter key
If bForm2JustClosed Then
bForm2JustClosed = False
Exit Sub
End If

Debug.WriteLine("Form1: TextBox1: KeyUp")
Dim f As New Form2
f.ShowDialog()
f.Dispose()

'Form2 just closed so set the flag to indicate this
bForm2JustClosed = True
End If
End Sub

This code seems to work for my simple test app, but whether or not it can
work for you, I don't know. Perhaps another option is in the keyUp event
for the textbox, set focus to some hidden control so that IT receives the
keyup event when form2 is closed then in it's keyup event, restore focus
back to the textbox.

Anyway, just wanted to let you know you are not losing your mind.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
Nov 21 '05 #7
On Mon, 25 Oct 2004 21:06:46 -0400, Adam J. Schaff wrote:
Jay,

The debug statements were a great idea. However, I appear to have confused
things with my sample application, which was only designed to illustrate
that Form1 was receiving a KeyUp from a key press that occurred on Form2.
Perhaps you're used to this, but it was an unpleasant surprise for me.

So let me start over with a sample that more closely mirrors my real
application. My app starts with Form1 which has a textbox on it. I want to
display Form2 if the user presses Enter while in the textbox. I'm using the
KeyUp event of the textbox for that. Form2 has an OK button, and has its
AcceptButton set to that OK button. The scenario runs like this:

1. App starts, Form1 is shown, the textbox has focus
2. The user presses Enter. Form2 is then shown modally.
3. The user does his thing on Form2 and then presses Enter, expecting to be
returned to Form1.

Here is the sequence of events for step 3:

a. No KeyDown or KeyPress events fire. Presumably, by setting the
AcceptButton property of Form2, it is now intercepting and "handling" those
events.
b. The Click event of the OK button on Form2 fires, which closes Form2.
c. The KeyUp event of TextBox1 on Form1 fires, which, as described above,
launches Form2.

The user is confused. He pressed enter, he saw Form2 unload, but then it
reloaded immediately. If he presses Enter again, then it repeats (Form2
closes and reopens).

I guess I can work around this by using the KeyDown or KeyPress events. I
don't like them as much as KeyUp, because KeyUp is guaranteed to only fire
once per key press, whereas the others can fire over and over (if the user
holds the button down), but they suddenly seem a lot safer in light of this
issue.

What I was hoping was that there might be some way that I could prevent the
KeyUp event from happening. Not handle it, mind you, because by then I'm in
Form1 and I can't tell a "good" KeyUp from a bad one. But if I could somehow
intercept and clear it, say from the Closing event of my Form2, that would
be cool.

You see, the bigger issue here is how can I defend one window from events
caused by a user who is in another window? Unwanted KeyUp and/or MouseUp
events can be a rude surprise. It would be nice if there was some way for a
form that was closing to say "throw away any outstanding KeyUp or MouseUp
events that have not occurred yet".

Thanks again for your help,
-AJ

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eQ*************@TK2MSFTNGP11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
Dim f As New Form2
f.ShowDialog()

End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter
(or Space) when Form1.Button1 has the focus & doesn't have the focus. Also
watch when there are other controls earlier & later in the tab order on
Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus & does
the Click event, Form1.Button1 now has the focus, so Form1.Button1.KeyUp
event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the Form1.Button1.KeyUp
event, or if you do need to handle it, make sure you know when the event
is occurring as part of the Click event or another event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note
that
the breakpoint in form1 gets hit! I don't understand why, since enter was
pressed while form2 was open. More importantly, I don't understand how to
prevent it.

p.s. framework v1.1, windows xp-sp2

<<snip>>


I created a very small project. It has two forms. On Form1, I placed a
single textbox. It's keyup handler is shown below:

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
Dim f As New Form2
Debug.WriteLine("Form1: TextBox1: KeyUp")
f.ShowDialog()
f.Dispose
End If
End Sub

On Form2 I placed a single button. I then set the AcceptButton propert of
Form2 to be the button. I added the following code to the Button's click
event:

Private Sub Button1_Click(...) Handles Button1.Click
Debug.WriteLine("Form2: Button1: Click")
Me.Close()
End Sub

When I fire up the program, Form1 appears with the textbox having focus
(since it is the only control on the form). I press enter and Form2
appears. I press enter again which causes the button on form2 to be
clicked which closes form2. Form2 immediately reappears!!

The following text appears in the output windows:

Form1: TextBox1: KeyUp
Form2: Button1: Click
Form1: TextBox1: KeyUp

Where is that extra KeyUp event coming from? When I pressed Enter, *FORM2*
had focus, form1 should not have gotten a keypress from form2!!

What appears to be happening is that the AcceptButton is being triggered
when the key goes down, which closes the form, but then the key up occurs
after form2 has been closed so the keyup goes to the only form which has
focus: Form1, which, of course, opens form2 again!

While, perhaps, its behavior is undesired, it is logical. The only
workaround I could think of was by adding a boolean flag that is set right
after form2 is closed and checking that flag on entering the keyup event.
If set, don't show form2 again:

'Global boolean
Dim bForm2JustClosed As Boolean

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
'If Form2 just closed, then ignore this KeyUp for the Enter key
If bForm2JustClosed Then
bForm2JustClosed = False
Exit Sub
End If

Debug.WriteLine("Form1: TextBox1: KeyUp")
Dim f As New Form2
f.ShowDialog()
f.Dispose()

'Form2 just closed so set the flag to indicate this
bForm2JustClosed = True
End If
End Sub

This code seems to work for my simple test app, but whether or not it can
work for you, I don't know. Perhaps another option is in the keyUp event
for the textbox, set focus to some hidden control so that IT receives the
keyup event when form2 is closed then in it's keyup event, restore focus
back to the textbox.

Anyway, just wanted to let you know you are not losing your mind.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
Nov 21 '05 #8
Adam,
2. The user presses Enter. Form2 is then shown modally.
What causes Form2 to be shown, please provide actual code or email me an
actual sample of your code if you need to.

Thanks
Jay

"Adam J. Schaff" <ab****@adelphia.net> wrote in message
news:ej**************@TK2MSFTNGP15.phx.gbl... Jay,

The debug statements were a great idea. However, I appear to have confused
things with my sample application, which was only designed to illustrate
that Form1 was receiving a KeyUp from a key press that occurred on Form2.
Perhaps you're used to this, but it was an unpleasant surprise for me.

So let me start over with a sample that more closely mirrors my real
application. My app starts with Form1 which has a textbox on it. I want to
display Form2 if the user presses Enter while in the textbox. I'm using
the KeyUp event of the textbox for that. Form2 has an OK button, and has
its AcceptButton set to that OK button. The scenario runs like this:

1. App starts, Form1 is shown, the textbox has focus
2. The user presses Enter. Form2 is then shown modally.
3. The user does his thing on Form2 and then presses Enter, expecting to
be returned to Form1.

Here is the sequence of events for step 3:

a. No KeyDown or KeyPress events fire. Presumably, by setting the
AcceptButton property of Form2, it is now intercepting and "handling"
those events.
b. The Click event of the OK button on Form2 fires, which closes Form2.
c. The KeyUp event of TextBox1 on Form1 fires, which, as described above,
launches Form2.

The user is confused. He pressed enter, he saw Form2 unload, but then it
reloaded immediately. If he presses Enter again, then it repeats (Form2
closes and reopens).

I guess I can work around this by using the KeyDown or KeyPress events. I
don't like them as much as KeyUp, because KeyUp is guaranteed to only fire
once per key press, whereas the others can fire over and over (if the user
holds the button down), but they suddenly seem a lot safer in light of
this issue.

What I was hoping was that there might be some way that I could prevent
the KeyUp event from happening. Not handle it, mind you, because by then
I'm in Form1 and I can't tell a "good" KeyUp from a bad one. But if I
could somehow intercept and clear it, say from the Closing event of my
Form2, that would be cool.

You see, the bigger issue here is how can I defend one window from events
caused by a user who is in another window? Unwanted KeyUp and/or MouseUp
events can be a rude surprise. It would be nice if there was some way for
a form that was closing to say "throw away any outstanding KeyUp or
MouseUp events that have not occurred yet".

Thanks again for your help,
-AJ

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eQ*************@TK2MSFTNGP11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
Dim f As New Form2
f.ShowDialog()

End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter
(or Space) when Form1.Button1 has the focus & doesn't have the focus.
Also watch when there are other controls earlier & later in the tab order
on Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus &
does the Click event, Form1.Button1 now has the focus, so
Form1.Button1.KeyUp event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the
Form1.Button1.KeyUp event, or if you do need to handle it, make sure you
know when the event is occurring as part of the Click event or another
event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note
that
the breakpoint in form1 gets hit! I don't understand why, since enter
was
pressed while form2 was open. More importantly, I don't understand how
to
prevent it.

p.s. framework v1.1, windows xp-sp2

<<snip>>


Nov 21 '05 #9
Adam,
2. The user presses Enter. Form2 is then shown modally.
What causes Form2 to be shown, please provide actual code or email me an
actual sample of your code if you need to.

Thanks
Jay

"Adam J. Schaff" <ab****@adelphia.net> wrote in message
news:ej**************@TK2MSFTNGP15.phx.gbl... Jay,

The debug statements were a great idea. However, I appear to have confused
things with my sample application, which was only designed to illustrate
that Form1 was receiving a KeyUp from a key press that occurred on Form2.
Perhaps you're used to this, but it was an unpleasant surprise for me.

So let me start over with a sample that more closely mirrors my real
application. My app starts with Form1 which has a textbox on it. I want to
display Form2 if the user presses Enter while in the textbox. I'm using
the KeyUp event of the textbox for that. Form2 has an OK button, and has
its AcceptButton set to that OK button. The scenario runs like this:

1. App starts, Form1 is shown, the textbox has focus
2. The user presses Enter. Form2 is then shown modally.
3. The user does his thing on Form2 and then presses Enter, expecting to
be returned to Form1.

Here is the sequence of events for step 3:

a. No KeyDown or KeyPress events fire. Presumably, by setting the
AcceptButton property of Form2, it is now intercepting and "handling"
those events.
b. The Click event of the OK button on Form2 fires, which closes Form2.
c. The KeyUp event of TextBox1 on Form1 fires, which, as described above,
launches Form2.

The user is confused. He pressed enter, he saw Form2 unload, but then it
reloaded immediately. If he presses Enter again, then it repeats (Form2
closes and reopens).

I guess I can work around this by using the KeyDown or KeyPress events. I
don't like them as much as KeyUp, because KeyUp is guaranteed to only fire
once per key press, whereas the others can fire over and over (if the user
holds the button down), but they suddenly seem a lot safer in light of
this issue.

What I was hoping was that there might be some way that I could prevent
the KeyUp event from happening. Not handle it, mind you, because by then
I'm in Form1 and I can't tell a "good" KeyUp from a bad one. But if I
could somehow intercept and clear it, say from the Closing event of my
Form2, that would be cool.

You see, the bigger issue here is how can I defend one window from events
caused by a user who is in another window? Unwanted KeyUp and/or MouseUp
events can be a rude surprise. It would be nice if there was some way for
a form that was closing to say "throw away any outstanding KeyUp or
MouseUp events that have not occurred yet".

Thanks again for your help,
-AJ

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eQ*************@TK2MSFTNGP11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
Dim f As New Form2
f.ShowDialog()

End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter
(or Space) when Form1.Button1 has the focus & doesn't have the focus.
Also watch when there are other controls earlier & later in the tab order
on Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus &
does the Click event, Form1.Button1 now has the focus, so
Form1.Button1.KeyUp event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the
Form1.Button1.KeyUp event, or if you do need to handle it, make sure you
know when the event is occurring as part of the Click event or another
event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note
that
the breakpoint in form1 gets hit! I don't understand why, since enter
was
pressed while form2 was open. More importantly, I don't understand how
to
prevent it.

p.s. framework v1.1, windows xp-sp2

<<snip>>


Nov 21 '05 #10
On Tue, 26 Oct 2004 10:01:53 -0500, Jay B. Harlow [MVP - Outlook] wrote:
Adam,
2. The user presses Enter. Form2 is then shown modally.


What causes Form2 to be shown, please provide actual code or email me an
actual sample of your code if you need to.


Jay, Form2 is being shown in the KeyUp event of the textbox on form1.

I think my simple example illustrates what is happening. It seems that the
AcceptButton on form2 is occuring on the KeyDown. It closes and the KeyUp
occurs when the textbox has regained focus.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
Nov 21 '05 #11
On Tue, 26 Oct 2004 10:01:53 -0500, Jay B. Harlow [MVP - Outlook] wrote:
Adam,
2. The user presses Enter. Form2 is then shown modally.


What causes Form2 to be shown, please provide actual code or email me an
actual sample of your code if you need to.


Jay, Form2 is being shown in the KeyUp event of the textbox on form1.

I think my simple example illustrates what is happening. It seems that the
AcceptButton on form2 is occuring on the KeyDown. It closes and the KeyUp
occurs when the textbox has regained focus.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
Nov 21 '05 #12
Chris: yes, you have it right. Glad to know I'm not just going crazy.

Jay: Chris's sample illustrates it. But I don't want to waste any more of
your time. I was kinda hoping that someone would just come out and say "oh
yeah, when closing forms, I always issue a <insert magic statement here> to
prevent leftover events from plummeting back to the calling form". The fact
that you didn't immediately grock what I was asking tells me that this isn't
a common problem with a ready solution. So I'll just work around it. Oh
well. As always, thanks for listening!

"Chris Dunaway" <"dunawayc[[at]_lunchmeat_sbcglobal[dot]]net"> wrote in
message news:di******************************@40tude.net.. .
On Tue, 26 Oct 2004 10:01:53 -0500, Jay B. Harlow [MVP - Outlook] wrote:
Adam,
2. The user presses Enter. Form2 is then shown modally.


What causes Form2 to be shown, please provide actual code or email me an
actual sample of your code if you need to.


Jay, Form2 is being shown in the KeyUp event of the textbox on form1.

I think my simple example illustrates what is happening. It seems that
the
AcceptButton on form2 is occuring on the KeyDown. It closes and the KeyUp
occurs when the textbox has regained focus.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.

Nov 21 '05 #13
Bingo. You got it. Unfortunately, I don't think your flag work-around will
suffice for my needs. If the user closes Form2 via the X or a Cancel button,
then naturally no extra KeyUp will occur, and your flag variable will remain
True and will reject a later, valid, Enter pressed while the user is on
Form1. The only way I can see it working is with timers (yuck) or if Form2
knew about Form1 and set the flag itself (also yuck).

The other, focus-based work around is a neat idea, I'll play with it and see
if I can make it work.

Thanks for your help,
AJ

"Chris Dunaway" <"dunawayc[[at]_lunchmeat_sbcglobal[dot]]net"> wrote in
message news:5f*****************************@40tude.net...
On Mon, 25 Oct 2004 21:06:46 -0400, Adam J. Schaff wrote:
Jay,

The debug statements were a great idea. However, I appear to have
confused
things with my sample application, which was only designed to illustrate
that Form1 was receiving a KeyUp from a key press that occurred on Form2.
Perhaps you're used to this, but it was an unpleasant surprise for me.

So let me start over with a sample that more closely mirrors my real
application. My app starts with Form1 which has a textbox on it. I want
to
display Form2 if the user presses Enter while in the textbox. I'm using
the
KeyUp event of the textbox for that. Form2 has an OK button, and has its
AcceptButton set to that OK button. The scenario runs like this:

1. App starts, Form1 is shown, the textbox has focus
2. The user presses Enter. Form2 is then shown modally.
3. The user does his thing on Form2 and then presses Enter, expecting to
be
returned to Form1.

Here is the sequence of events for step 3:

a. No KeyDown or KeyPress events fire. Presumably, by setting the
AcceptButton property of Form2, it is now intercepting and "handling"
those
events.
b. The Click event of the OK button on Form2 fires, which closes Form2.
c. The KeyUp event of TextBox1 on Form1 fires, which, as described above,
launches Form2.

The user is confused. He pressed enter, he saw Form2 unload, but then it
reloaded immediately. If he presses Enter again, then it repeats (Form2
closes and reopens).

I guess I can work around this by using the KeyDown or KeyPress events. I
don't like them as much as KeyUp, because KeyUp is guaranteed to only
fire
once per key press, whereas the others can fire over and over (if the
user
holds the button down), but they suddenly seem a lot safer in light of
this
issue.

What I was hoping was that there might be some way that I could prevent
the
KeyUp event from happening. Not handle it, mind you, because by then I'm
in
Form1 and I can't tell a "good" KeyUp from a bad one. But if I could
somehow
intercept and clear it, say from the Closing event of my Form2, that
would
be cool.

You see, the bigger issue here is how can I defend one window from events
caused by a user who is in another window? Unwanted KeyUp and/or MouseUp
events can be a rude surprise. It would be nice if there was some way for
a
form that was closing to say "throw away any outstanding KeyUp or MouseUp
events that have not occurred yet".

Thanks again for your help,
-AJ

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eQ*************@TK2MSFTNGP11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter
(or Space) when Form1.Button1 has the focus & doesn't have the focus.
Also
watch when there are other controls earlier & later in the tab order on
Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus &
does
the Click event, Form1.Button1 now has the focus, so Form1.Button1.KeyUp
event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the
Form1.Button1.KeyUp
event, or if you do need to handle it, make sure you know when the event
is occurring as part of the Click event or another event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
Jay,
To reproduce, create a new vb.net winforms app with two forms. Place a
button on each form.
Add this code to form1:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Stop
End Sub
Add this code to form2:

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.AcceptButton = Button1
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Me.Close()
End Sub

Run the app, click the button on form1. Form2 opens, press Enter. Note
that
the breakpoint in form1 gets hit! I don't understand why, since enter
was
pressed while form2 was open. More importantly, I don't understand how
to
prevent it.

p.s. framework v1.1, windows xp-sp2
<<snip>>


I created a very small project. It has two forms. On Form1, I placed a
single textbox. It's keyup handler is shown below:

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
Dim f As New Form2
Debug.WriteLine("Form1: TextBox1: KeyUp")
f.ShowDialog()
f.Dispose
End If
End Sub

On Form2 I placed a single button. I then set the AcceptButton propert of
Form2 to be the button. I added the following code to the Button's click
event:

Private Sub Button1_Click(...) Handles Button1.Click
Debug.WriteLine("Form2: Button1: Click")
Me.Close()
End Sub

When I fire up the program, Form1 appears with the textbox having focus
(since it is the only control on the form). I press enter and Form2
appears. I press enter again which causes the button on form2 to be
clicked which closes form2. Form2 immediately reappears!!

The following text appears in the output windows:

Form1: TextBox1: KeyUp
Form2: Button1: Click
Form1: TextBox1: KeyUp

Where is that extra KeyUp event coming from? When I pressed Enter,
*FORM2*
had focus, form1 should not have gotten a keypress from form2!!

What appears to be happening is that the AcceptButton is being triggered
when the key goes down, which closes the form, but then the key up occurs
after form2 has been closed so the keyup goes to the only form which has
focus: Form1, which, of course, opens form2 again!

While, perhaps, its behavior is undesired, it is logical. The only
workaround I could think of was by adding a boolean flag that is set right
after form2 is closed and checking that flag on entering the keyup event.
If set, don't show form2 again:

'Global boolean
Dim bForm2JustClosed As Boolean

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
'If Form2 just closed, then ignore this KeyUp for the Enter key
If bForm2JustClosed Then
bForm2JustClosed = False
Exit Sub
End If

Debug.WriteLine("Form1: TextBox1: KeyUp")
Dim f As New Form2
f.ShowDialog()
f.Dispose()

'Form2 just closed so set the flag to indicate this
bForm2JustClosed = True
End If
End Sub

This code seems to work for my simple test app, but whether or not it can
work for you, I don't know. Perhaps another option is in the keyUp event
for the textbox, set focus to some hidden control so that IT receives the
keyup event when form2 is closed then in it's keyup event, restore focus
back to the textbox.

Anyway, just wanted to let you know you are not losing your mind.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.

Nov 21 '05 #14
On Tue, 26 Oct 2004 22:05:53 -0400, Adam J. Schaff wrote:
Bingo. You got it. Unfortunately, I don't think your flag work-around will
suffice for my needs. If the user closes Form2 via the X or a Cancel button,
then naturally no extra KeyUp will occur, and your flag variable will remain
True and will reject a later, valid, Enter pressed while the user is on
Good point! I didn't think of that.

The other, focus-based work around is a neat idea, I'll play with it and see
if I can make it work.


I didn't try it, but it could work. Good Luck!

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
Nov 21 '05 #15
Solved it. I kept looking for a single event that would work, but if I use
TWO events then I can work around it. After all, the issue is an extra KeyUp
event showing up out of the blue (as far as Form1 is concerned, anyway). So
I handle KeyDown (which only fires for key presses that occurred while Form1
has focus!) and set a flag:

mKeyDownJustFired = True

and then I handle KeyUp and say:
If mKeyDownJustFired Then 'avoid extraneous KeyUp events that leaked down
from another form
mKeyDownJustFired = False
<code to launch Form2>
End If

Works like a charm.

"Adam J. Schaff" <ab****@adelphia.net> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
Bingo. You got it. Unfortunately, I don't think your flag work-around will
suffice for my needs. If the user closes Form2 via the X or a Cancel button, then naturally no extra KeyUp will occur, and your flag variable will remain True and will reject a later, valid, Enter pressed while the user is on
Form1. The only way I can see it working is with timers (yuck) or if Form2
knew about Form1 and set the flag itself (also yuck).

The other, focus-based work around is a neat idea, I'll play with it and see if I can make it work.

Thanks for your help,
AJ

"Chris Dunaway" <"dunawayc[[at]_lunchmeat_sbcglobal[dot]]net"> wrote in
message news:5f*****************************@40tude.net...
On Mon, 25 Oct 2004 21:06:46 -0400, Adam J. Schaff wrote:
Jay,

The debug statements were a great idea. However, I appear to have
confused
things with my sample application, which was only designed to illustrate that Form1 was receiving a KeyUp from a key press that occurred on Form2. Perhaps you're used to this, but it was an unpleasant surprise for me.

So let me start over with a sample that more closely mirrors my real
application. My app starts with Form1 which has a textbox on it. I want
to
display Form2 if the user presses Enter while in the textbox. I'm using
the
KeyUp event of the textbox for that. Form2 has an OK button, and has its AcceptButton set to that OK button. The scenario runs like this:

1. App starts, Form1 is shown, the textbox has focus
2. The user presses Enter. Form2 is then shown modally.
3. The user does his thing on Form2 and then presses Enter, expecting to be
returned to Form1.

Here is the sequence of events for step 3:

a. No KeyDown or KeyPress events fire. Presumably, by setting the
AcceptButton property of Form2, it is now intercepting and "handling"
those
events.
b. The Click event of the OK button on Form2 fires, which closes Form2.
c. The KeyUp event of TextBox1 on Form1 fires, which, as described above, launches Form2.

The user is confused. He pressed enter, he saw Form2 unload, but then it reloaded immediately. If he presses Enter again, then it repeats (Form2
closes and reopens).

I guess I can work around this by using the KeyDown or KeyPress events. I don't like them as much as KeyUp, because KeyUp is guaranteed to only
fire
once per key press, whereas the others can fire over and over (if the
user
holds the button down), but they suddenly seem a lot safer in light of
this
issue.

What I was hoping was that there might be some way that I could prevent
the
KeyUp event from happening. Not handle it, mind you, because by then I'm in
Form1 and I can't tell a "good" KeyUp from a bad one. But if I could
somehow
intercept and clear it, say from the Closing event of my Form2, that
would
be cool.

You see, the bigger issue here is how can I defend one window from events caused by a user who is in another window? Unwanted KeyUp and/or MouseUp events can be a rude surprise. It would be nice if there was some way for a
form that was closing to say "throw away any outstanding KeyUp or MouseUp events that have not occurred yet".

Thanks again for your help,
-AJ

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message news:eQ*************@TK2MSFTNGP11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Click", "Button1")
> Dim f As New Form2
> f.ShowDialog()
End Sub

Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
Debug.WriteLine("KeyUp", "Button1")
End Sub

Private Sub Button1_KeyDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyEventArgs) Handles Button1.KeyDown
Debug.WriteLine("KeyDown", "Button1")
End Sub

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
Debug.WriteLine("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseDown
Debug.WriteLine("MouseDown", "Button1")
End Sub

Private Sub Button1_MouseUp(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles Button1.MouseUp
Debug.WriteLine("MouseUp", "Button1")
End Sub
Run your form. Watch the debug messages, especially when you press Enter (or Space) when Form1.Button1 has the focus & doesn't have the focus.
Also
watch when there are other controls earlier & later in the tab order on Form1.

Assuming there are no other controls on Form1:

When Form1.Button1 does not have the focus, Button1 gains the focus &
does
the Click event, Form1.Button1 now has the focus, so Form1.Button1.KeyUp event is raised.

When Form1.Button1 does have the focus, Button1 raises its KeyDown &
KeyPress event, then the Click event, followed by the KeyUp event.

MouseDown, Click, and MouseUp events happen in a similar order.

IMHO Preventing it seems rather easy, Don't handle the
Form1.Button1.KeyUp
event, or if you do need to handle it, make sure you know when the event is occurring as part of the Click event or another event...

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascodev.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
> Jay,
> To reproduce, create a new vb.net winforms app with two forms. Place a> button on each form.
> Add this code to form1:
> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
> System.EventArgs) Handles Button1.Click
> Dim f As New Form2
> f.ShowDialog()
> End Sub
>
> Private Sub Button1_KeyUp(ByVal sender As Object, ByVal e As
> System.Windows.Forms.KeyEventArgs) Handles Button1.KeyUp
> Stop
> End Sub
>
>
> Add this code to form2:
>
> Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
> System.EventArgs) Handles MyBase.Load
> Me.AcceptButton = Button1
> End Sub
>
> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
> System.EventArgs) Handles Button1.Click
> Me.Close()
> End Sub
>
> Run the app, click the button on form1. Form2 opens, press Enter. Note> that
> the breakpoint in form1 gets hit! I don't understand why, since enter
> was
> pressed while form2 was open. More importantly, I don't understand how> to
> prevent it.
>
> p.s. framework v1.1, windows xp-sp2
>
>
<<snip>>


I created a very small project. It has two forms. On Form1, I placed a
single textbox. It's keyup handler is shown below:

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
Dim f As New Form2
Debug.WriteLine("Form1: TextBox1: KeyUp")
f.ShowDialog()
f.Dispose
End If
End Sub

On Form2 I placed a single button. I then set the AcceptButton propert of Form2 to be the button. I added the following code to the Button's click event:

Private Sub Button1_Click(...) Handles Button1.Click
Debug.WriteLine("Form2: Button1: Click")
Me.Close()
End Sub

When I fire up the program, Form1 appears with the textbox having focus
(since it is the only control on the form). I press enter and Form2
appears. I press enter again which causes the button on form2 to be
clicked which closes form2. Form2 immediately reappears!!

The following text appears in the output windows:

Form1: TextBox1: KeyUp
Form2: Button1: Click
Form1: TextBox1: KeyUp

Where is that extra KeyUp event coming from? When I pressed Enter,
*FORM2*
had focus, form1 should not have gotten a keypress from form2!!

What appears to be happening is that the AcceptButton is being triggered
when the key goes down, which closes the form, but then the key up occurs after form2 has been closed so the keyup goes to the only form which has
focus: Form1, which, of course, opens form2 again!

While, perhaps, its behavior is undesired, it is logical. The only
workaround I could think of was by adding a boolean flag that is set right after form2 is closed and checking that flag on entering the keyup event. If set, don't show form2 again:

'Global boolean
Dim bForm2JustClosed As Boolean

Private Sub TextBox1_KeyUp(...) Handles TextBox1.KeyUp
If e.KeyCode = Keys.Enter Then
'If Form2 just closed, then ignore this KeyUp for the Enter key
If bForm2JustClosed Then
bForm2JustClosed = False
Exit Sub
End If

Debug.WriteLine("Form1: TextBox1: KeyUp")
Dim f As New Form2
f.ShowDialog()
f.Dispose()

'Form2 just closed so set the flag to indicate this
bForm2JustClosed = True
End If
End Sub

This code seems to work for my simple test app, but whether or not it can work for you, I don't know. Perhaps another option is in the keyUp event for the textbox, set focus to some hidden control so that IT receives the keyup event when form2 is closed then in it's keyup event, restore focus
back to the textbox.

Anyway, just wanted to let you know you are not losing your mind.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.


Nov 21 '05 #16

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Jose Egea | last post by:
Hello: I'm trying to execute a function when the user press Enter key in a TextBox. But something is happening in my form because after pressing a button, when I press the Enter key in the...
0
by: Coder | last post by:
hi, i am using a c# windows application. i want to handle some keypress events like ctrl+A, shift+enter, etc.. is it easy to handle only one keypress; as KeyPressEventArgs e;... e.KeyPress. ...
7
by: Doug Bell | last post by:
Hi, I have just built a small application with a form that has one Text Box and one Check Box and a couple of Command Buttons. What I am trying to achieve is that if the Text Box has focus and...
4
by: alien2_51 | last post by:
I have a form with several buttons, I'd like to default to a specific button on the Enter keypress event, How would I do this...?
3
by: JAG711 | last post by:
I have 2 mdi childforms which are database input forms. Each form has the usual add/delete/edit/save buttons and a few textboxes. I capture the keypress events on the textboxes to allow only...
2
by: matthewr | last post by:
In Internet Explorer, for example, when you hit return in the address bar, the Go button is pressed. In my program, I have a toolstrip with a textbox and button. How do I ensure the button is...
2
by: sravan_reddy001 | last post by:
i had designed a win app(an address book) when the user wants to enter the contact he will type in all the details and "HE SHOULD CLICK ON THE ADDENTRY BUTTON PROVIDED" i want to simplify this...
3
by: Simon Verona | last post by:
Sorry for the repost, but this group seems to be more "active" than the group that I posted my question, and it's probably as valid here as there! I have a usercontrol, which contains a textbox...
3
by: chris52672 | last post by:
If I have text box 1 (Password Enter) and I have text box 2 (Password Reneter). After text has been entered in text box 1 and the enter key is pressed to make text box 2 active (the curser will...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.