473,707 Members | 2,362 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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 4044
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*****@cascod ev.com> wrote in message
news:OR******** ******@TK2MSFTN GP14.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.KeyPressE ventArgs) Handles MyBase.KeyPress
If e.KeyChar = ControlChars.Cr Then
Dim dialog As New Form2
dialog.ShowDial og(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(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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=Fals e.
Form2 only has Button1, Form2.AcceptBut ton = Button1.

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascod ev.com> wrote in message
news:OR******** ******@TK2MSFTN GP14.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

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

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

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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******** *****@TK2MSFTNG P10.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.KeyPressE ventArgs) Handles MyBase.KeyPress
If e.KeyChar = ControlChars.Cr Then
Dim dialog As New Form2
dialog.ShowDial og(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(B yVal sender As System.Object, ByVal e As System.EventArg s) 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=Fals e.
Form2 only has Button1, Form2.AcceptBut ton = Button1.

Hope this helps
Jay

"Adam J. Schaff" <as*****@cascod ev.com> wrote in message
news:OR******** ******@TK2MSFTN GP14.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Debug.WriteLine ("Click", "Button1")
Dim f As New Form2
f.ShowDialog() End Sub

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

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

Private Sub Button1_KeyPres s(ByVal sender As Object, ByVal e As
System.Windows. Forms.KeyPressE ventArgs) Handles Button1.KeyPres s
Debug.WriteLine ("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDo wn(ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) Handles Button1.MouseDo wn
Debug.WriteLine ("MouseDown" , "Button1")
End Sub

Private Sub Button1_MouseUp (ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) 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.K eyUp
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.K eyUp
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*****@cascod ev.com> wrote in message
news:ub******** ******@TK2MSFTN GP10.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

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

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

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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******** *****@TK2MSFTNG P11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

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

End Sub

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

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

Private Sub Button1_KeyPres s(ByVal sender As Object, ByVal e As
System.Windows. Forms.KeyPressE ventArgs) Handles Button1.KeyPres s
Debug.WriteLine ("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDo wn(ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) Handles Button1.MouseDo wn
Debug.WriteLine ("MouseDown" , "Button1")
End Sub

Private Sub Button1_MouseUp (ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) 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.K eyUp
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.K eyUp
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*****@cascod ev.com> wrote in message
news:ub******** ******@TK2MSFTN GP10.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

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

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

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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******** *****@TK2MSFTNG P11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

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

End Sub

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

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

Private Sub Button1_KeyPres s(ByVal sender As Object, ByVal e As
System.Windows. Forms.KeyPressE ventArgs) Handles Button1.KeyPres s
Debug.WriteLine ("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDo wn(ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) Handles Button1.MouseDo wn
Debug.WriteLine ("MouseDown" , "Button1")
End Sub

Private Sub Button1_MouseUp (ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) 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.K eyUp
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.K eyUp
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*****@cascod ev.com> wrote in message
news:ub******** ******@TK2MSFTN GP10.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

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

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

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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 bForm2JustClose d 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 bForm2JustClose d Then
bForm2JustClose d = 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
bForm2JustClose d = 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_lunch meat_[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******** *****@TK2MSFTNG P11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

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

End Sub

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

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

Private Sub Button1_KeyPres s(ByVal sender As Object, ByVal e As
System.Windows. Forms.KeyPressE ventArgs) Handles Button1.KeyPres s
Debug.WriteLine ("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDo wn(ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) Handles Button1.MouseDo wn
Debug.WriteLine ("MouseDown" , "Button1")
End Sub

Private Sub Button1_MouseUp (ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) 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.K eyUp
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.K eyUp
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*****@cascod ev.com> wrote in message
news:ub******** ******@TK2MSFTN GP10.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

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

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

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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 bForm2JustClose d 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 bForm2JustClose d Then
bForm2JustClose d = 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
bForm2JustClose d = 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_lunch meat_[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****@adelphi a.net> wrote in message
news:ej******** ******@TK2MSFTN GP15.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******** *****@TK2MSFTNG P11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

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

End Sub

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

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

Private Sub Button1_KeyPres s(ByVal sender As Object, ByVal e As
System.Windows. Forms.KeyPressE ventArgs) Handles Button1.KeyPres s
Debug.WriteLine ("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDo wn(ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) Handles Button1.MouseDo wn
Debug.WriteLine ("MouseDown" , "Button1")
End Sub

Private Sub Button1_MouseUp (ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) 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.K eyUp 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.K eyUp 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*****@cascod ev.com> wrote in message
news:ub******** ******@TK2MSFTN GP10.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

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

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

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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****@adelphi a.net> wrote in message
news:ej******** ******@TK2MSFTN GP15.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******** *****@TK2MSFTNG P11.phx.gbl...
Adam,
To see why it happens add the following code to Form1:

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

End Sub

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

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

Private Sub Button1_KeyPres s(ByVal sender As Object, ByVal e As
System.Windows. Forms.KeyPressE ventArgs) Handles Button1.KeyPres s
Debug.WriteLine ("KeyPress", "Button1")
End Sub

Private Sub Button1_MouseDo wn(ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) Handles Button1.MouseDo wn
Debug.WriteLine ("MouseDown" , "Button1")
End Sub

Private Sub Button1_MouseUp (ByVal sender As Object, ByVal e As
System.Windows. Forms.MouseEven tArgs) 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.K eyUp 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.K eyUp 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*****@cascod ev.com> wrote in message
news:ub******** ******@TK2MSFTN GP10.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(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim f As New Form2
f.ShowDialog()
End Sub

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

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

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) 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

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

Similar topics

3
19714
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 TextBox, the application executes the click event of the last button selected instead of the keypress event of the TextBox. Any key event happen in my form, even the keypreview event is ignored. The propertie AcceptsReturn is set to false and...
0
1429
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. best regards..
7
5715
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 the User hits the "Enter" button the focus will move to the next Tab item (i.e. the Check Box). Likewise on the Check Box but obviously if a Command Button has the focus, it will initiate the Click event I have set the Forms CancelButton to the...
4
1540
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
3651
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 numbers and I also capture the Enter key to move focus to the next control. The forms work fine if only one form is opened. If both forms are opened and I then switch to the form that was opened first the keypress event does not capture the enter...
2
13501
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 'clicked' when Enter is pressed in the text box. I can't set the form's AcceptButton property to the toolStripButton - it doesn't allow toolStripButtons to be set as the AcceptButton. As a last resort, I could create a keypress event handler for...
2
4707
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 task for the user by allowing the data to bw added in database when "HE PRESSED ENTER KEY AFTER ENTERING THE DETAILS" how can make a button as default button and that button is should be
3
5515
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 (as well as other controls). The textbox is set for multiline, so it *should* accept an Enter Key to move down to the next line. However, I'm finding that if I put the control onto a form which has a default Accept button set, then pressing...
3
5594
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 jump from text box 1 to text box 2. Any ideas
0
8787
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9289
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
9060
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9001
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7921
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5939
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4712
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3151
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
2096
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.