By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,105 Members | 2,620 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,105 IT Pros & Developers. It's quick & easy.

Validating textbox w/ Cancel button

P: n/a
I have a form w/ a textbox and Cancel button on it. I have a routine to
handle textbox.validating, and I have the form setup so the Cancel
button is the Cancel button.

WHen the user clicks on the cancel button, the textbox.validating is
being called. I don't want it to be since they are exiting the screen
the validation doesn't have to be done.

How can I do that.

Thanks.

Darin

*** Sent via Developersdex http://www.developersdex.com ***
Jul 12 '06 #1
Share this Question
Share on Google+
21 Replies


P: n/a
if you want to exit the form when the user presses cancel then just say, in
the btnCancel click event

Me.Close()

and the form will close
--
-iwdu15
Jul 12 '06 #2

P: n/a
I know that, but the problem is when the user clicks EXIT, the
textbox.validating event is called BEFORE the cancel.click is done, so
the textbox is being validated. It doesn't need to be validated because
the user is exiting.

Darin

*** Sent via Developersdex http://www.developersdex.com ***
Jul 12 '06 #3

P: n/a
Yes, closing the form causes 'validating' to take place. One, remove the
"controlBox" from the form, so the user cant close it that way. Then in the
btnCancel_click event, either set a module level variable like mCanceling to
True and then in the validating event ... If not mCanceling ...
Another approach. in the btnCancel_Click event:
Removehandeler TextBox1.validating, Addressof TextBox1_Validating
--
Terry
"Darin" wrote:
I know that, but the problem is when the user clicks EXIT, the
textbox.validating event is called BEFORE the cancel.click is done, so
the textbox is being validated. It doesn't need to be validated because
the user is exiting.

Darin

*** Sent via Developersdex http://www.developersdex.com ***
Jul 13 '06 #4

P: n/a
"Terry" <Te***@nospam.nospamwrote in message news:90**********************************@microsof t.com...
Yes, closing the form causes 'validating' to take place. One, remove the
"controlBox" from the form, so the user cant close it that way. Then in the
btnCancel_click event, either set a module level variable like mCanceling to
True and then in the validating event ... If not mCanceling ...
Another approach. in the btnCancel_Click event:
Removehandeler TextBox1.validating, Addressof TextBox1_Validating
--
Terry

That doesn't work either, at least not for VB2005. I've been fighting the same problem for some time now. When you click on the
button the validating event fires. If you set e.Cancel=True the button events never fire.

I think that the only way to do this is to grab the mouse coordinates in the validating event, do a WindowFromPoint API call, then
compare the returned HWND to the Cancel Button's Handle. If the handle matched then immediately exit the Validating event without
setting e.Cancel = True.

--
Al Reid
Jul 13 '06 #5

P: n/a
Well it works for me - but one thing I left out - you need to set the cancel
buttons 'causes validation' to false. The following code works as you might
hope:
Public Class Form1
Private mCanceling As Boolean = False

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

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As
System.ComponentModel.CancelEventArgs) Handles TextBox1.Validating
If Not mCanceling Then
If TextBox1.Text.Length < 5 Then
e.Cancel = True
End If
End If
End Sub
End Class
The removehandeler method also works.

Also, as I just discovered, if you set the text box's causesvalidation to
false, you can close the form from the control box without validation taking
place. This really sounds more like a bug to me.

--
Terry
"Al Reid" wrote:
"Terry" <Te***@nospam.nospamwrote in message news:90**********************************@microsof t.com...
Yes, closing the form causes 'validating' to take place. One, remove the
"controlBox" from the form, so the user cant close it that way. Then in the
btnCancel_click event, either set a module level variable like mCanceling to
True and then in the validating event ... If not mCanceling ...
Another approach. in the btnCancel_Click event:
Removehandeler TextBox1.validating, Addressof TextBox1_Validating
--
Terry

That doesn't work either, at least not for VB2005. I've been fighting the same problem for some time now. When you click on the
button the validating event fires. If you set e.Cancel=True the button events never fire.

I think that the only way to do this is to grab the mouse coordinates in the validating event, do a WindowFromPoint API call, then
compare the returned HWND to the Cancel Button's Handle. If the handle matched then immediately exit the Validating event without
setting e.Cancel = True.

--
Al Reid
Jul 13 '06 #6

P: n/a
I had tried all of that, *BUT*, I had neglected to set the button's CausesValidation to False. DUH!!!
It does indeed work. I also got the WindowFromPoint approach working as well. Now I can go back and strip that out.

Thanks.

--
Al Reid (who didn't mean to hijack the thread)
"Terry" <Te***@nospam.nospamwrote in message news:70**********************************@microsof t.com...
Well it works for me - but one thing I left out - you need to set the cancel
buttons 'causes validation' to false. The following code works as you might
hope:
Public Class Form1
Private mCanceling As Boolean = False

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

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As
System.ComponentModel.CancelEventArgs) Handles TextBox1.Validating
If Not mCanceling Then
If TextBox1.Text.Length < 5 Then
e.Cancel = True
End If
End If
End Sub
End Class
The removehandeler method also works.

Also, as I just discovered, if you set the text box's causesvalidation to
false, you can close the form from the control box without validation taking
place. This really sounds more like a bug to me.

--
Terry


Jul 13 '06 #7

P: n/a
That doesn't work for me. I am on VB.Net, VS 2003. When I click on the
cancel button it doesn't even get to the cancel.click event until AFTER
it has done the validating.

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
MessageBox.Show("Button1_click")
mCanceling = True
Me.Close()
End Sub

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As
System.ComponentModel.CancelEventArgs) Handles TextBox1.Validating
If Not mCanceling Then
If TextBox1.Text.Length < 5 Then
e.Cancel = True
End If
End If
End Sub

Run the program (make sure the tab stop has the textbox first then the
button), leave the text in textbox to be textbox, click on button, you
will see the message. Run it again, clear out the text in textbox, click
on cancel and you will not see the message - the system is not honoring
the cancel.click because (I guess) the e.cancel=true in _validating.
Darin

*** Sent via Developersdex http://www.developersdex.com ***
Jul 13 '06 #8

P: n/a
Just a follow-up. The thing that this approach does not allow (unless I've one again neglected the obvious) is using the escape key
to trigger the form cancel. If I hit the escape, the validation event fires and since the mCanceling is not True, the validation
error gets displayed before the form closes.

My final solution, unless someone has a better suggestion, is to change the Validating event to the Leave event and detecting
whether the cancel button had been clicked in the Leave event and exiting if it was. This way both the escape key and the cancel
button closes the form without causing the validation to occur.

The code to tell if the cancel button has been clicked is:

///////

Public Declare Function WindowFromPoint Lib "user32" (ByVal p As POINTAPI) As IntPtr

Public Structure POINTAPI

Dim X As Integer

Dim Y As Integer

End Structure

Private Function CancelButtonClicked() As Boolean

Dim p As New POINTAPI

p.X = Form.MousePosition.X

p.Y = Form.MousePosition.Y

Dim HWnd As IntPtr = WindowFromPoint(p)

If HWnd = CType(Me.CancelButton, Button).Handle Then

Return True

Else

Return False

End If

End Function

\\\\\\\\\\\\

--
Al Reid

"Al Reid" <ar*****@reidDASHhome.comwrote in message news:uA**************@TK2MSFTNGP05.phx.gbl...
I had tried all of that, *BUT*, I had neglected to set the button's CausesValidation to False. DUH!!!
It does indeed work. I also got the WindowFromPoint approach working as well. Now I can go back and strip that out.

Thanks.

--
Al Reid (who didn't mean to hijack the thread)
"Terry" <Te***@nospam.nospamwrote in message news:70**********************************@microsof t.com...
Well it works for me - but one thing I left out - you need to set the cancel
buttons 'causes validation' to false. The following code works as you might
hope:
Public Class Form1
Private mCanceling As Boolean = False

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

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As
System.ComponentModel.CancelEventArgs) Handles TextBox1.Validating
If Not mCanceling Then
If TextBox1.Text.Length < 5 Then
e.Cancel = True
End If
End If
End Sub
End Class
The removehandeler method also works.

Also, as I just discovered, if you set the text box's causesvalidation to
false, you can close the form from the control box without validation taking
place. This really sounds more like a bug to me.

--
Terry


Jul 13 '06 #9

P: n/a
Hi Al,
Hmmm, I just tried the 'escape' key and it works fine! The form cancels
and the 'validating' event is skipped. Sounds like you have something else
going on.
--
Terry
"Al Reid" wrote:
Just a follow-up. The thing that this approach does not allow (unless I've one again neglected the obvious) is using the escape key
to trigger the form cancel. If I hit the escape, the validation event fires and since the mCanceling is not True, the validation
error gets displayed before the form closes.

My final solution, unless someone has a better suggestion, is to change the Validating event to the Leave event and detecting
whether the cancel button had been clicked in the Leave event and exiting if it was. This way both the escape key and the cancel
button closes the form without causing the validation to occur.

The code to tell if the cancel button has been clicked is:

///////

Public Declare Function WindowFromPoint Lib "user32" (ByVal p As POINTAPI) As IntPtr

Public Structure POINTAPI

Dim X As Integer

Dim Y As Integer

End Structure

Private Function CancelButtonClicked() As Boolean

Dim p As New POINTAPI

p.X = Form.MousePosition.X

p.Y = Form.MousePosition.Y

Dim HWnd As IntPtr = WindowFromPoint(p)

If HWnd = CType(Me.CancelButton, Button).Handle Then

Return True

Else

Return False

End If

End Function

\\\\\\\\\\\\

--
Al Reid

"Al Reid" <ar*****@reidDASHhome.comwrote in message news:uA**************@TK2MSFTNGP05.phx.gbl...
I had tried all of that, *BUT*, I had neglected to set the button's CausesValidation to False. DUH!!!
It does indeed work. I also got the WindowFromPoint approach working as well. Now I can go back and strip that out.

Thanks.

--
Al Reid (who didn't mean to hijack the thread)
"Terry" <Te***@nospam.nospamwrote in message news:70**********************************@microsof t.com...
Well it works for me - but one thing I left out - you need to set the cancel
buttons 'causes validation' to false. The following code works as you might
hope:
Public Class Form1
Private mCanceling As Boolean = False
>
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
mCanceling = True
Me.Close()
End Sub
>
Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As
System.ComponentModel.CancelEventArgs) Handles TextBox1.Validating
If Not mCanceling Then
If TextBox1.Text.Length < 5 Then
e.Cancel = True
End If
End If
End Sub
End Class
The removehandeler method also works.
>
Also, as I just discovered, if you set the text box's causesvalidation to
false, you can close the form from the control box without validation taking
place. This really sounds more like a bug to me.
>
--
>
>
Terry
>
>


Jul 13 '06 #10

P: n/a
Are you sure you have set the Cancel button's 'CausesValidation' to False?
--
Terry
"Darin" wrote:
That doesn't work for me. I am on VB.Net, VS 2003. When I click on the
cancel button it doesn't even get to the cancel.click event until AFTER
it has done the validating.

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
MessageBox.Show("Button1_click")
mCanceling = True
Me.Close()
End Sub

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As
System.ComponentModel.CancelEventArgs) Handles TextBox1.Validating
If Not mCanceling Then
If TextBox1.Text.Length < 5 Then
e.Cancel = True
End If
End If
End Sub

Run the program (make sure the tab stop has the textbox first then the
button), leave the text in textbox to be textbox, click on button, you
will see the message. Run it again, clear out the text in textbox, click
on cancel and you will not see the message - the system is not honoring
the cancel.click because (I guess) the e.cancel=true in _validating.
Darin

*** Sent via Developersdex http://www.developersdex.com ***
Jul 13 '06 #11

P: n/a
I guess I'm going to have to start with a new project and try it. The
users have "required" several features such as navigation with the enter key
instead of tab and also that all of the text gets selected upon entering a
field, etc. The form's KeyPreview is set to True so that I can handle key
events on the form... Somewhere in all of that, something must be getting
crossed up.

I always get the weird ones. For example, I have another application that
uses a wedge type barcode reader. If I type the info and press enter it
works. If I use a wand type reader, it works. If I connect a gun type, the
program fails and the cursor jumps to a text box that has it's TabStop
property set to False. If I do a debug.Print in the Form's Keypress event
all three methods display the exact same key codes.

Oh well, that's what keeps it interesting.

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message
news:EF**********************************@microsof t.com...
Hi Al,
Hmmm, I just tried the 'escape' key and it works fine! The form cancels
and the 'validating' event is skipped. Sounds like you have something
else
going on.
--
Terry


Jul 13 '06 #12

P: n/a
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown event
instead of the KeyPress event. They don't receive the same things! here is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which I
will have to look into. If you figure it out first, let me know.

--
Terry
"Al Reid" wrote:
I guess I'm going to have to start with a new project and try it. The
users have "required" several features such as navigation with the enter key
instead of tab and also that all of the text gets selected upon entering a
field, etc. The form's KeyPreview is set to True so that I can handle key
events on the form... Somewhere in all of that, something must be getting
crossed up.

I always get the weird ones. For example, I have another application that
uses a wedge type barcode reader. If I type the info and press enter it
works. If I use a wand type reader, it works. If I connect a gun type, the
program fails and the cursor jumps to a text box that has it's TabStop
property set to False. If I do a debug.Print in the Form's Keypress event
all three methods display the exact same key codes.

Oh well, that's what keeps it interesting.

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message
news:EF**********************************@microsof t.com...
Hi Al,
Hmmm, I just tried the 'escape' key and it works fine! The form cancels
and the 'validating' event is skipped. Sounds like you have something
else
going on.
--
Terry


Jul 14 '06 #13

P: n/a
Terry,

I guess we have a similar background. 26 years in computing and used VB
since Version 2.

I don't do anything with the barcode data in the KeyPress event. I use it
to catch and handle the "enter" key. I guess I could inspect the data in
the KeyDown event to see if there is a difference. I just don't know what
key code combination could direct focus to a text box control that should
never receive focus since the TabStop property is false and there is no
other code that sets focus to the textbox. The textbox is also ReadOnly.
It's frustrating!!!

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message
news:78**********************************@microsof t.com...
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown
event
instead of the KeyPress event. They don't receive the same things! here
is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data
to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which
I
will have to look into. If you figure it out first, let me know.

--
Terry

>>

Jul 14 '06 #14

P: n/a
Hi Al,
Nearly 40 years for me since my first college FORTRAN IV class! My, how
the years fly!
Well, one of the keys you would not see in either the keypress or keydown
events is the tab key, which of course will move the focus. Why it would
stop on a textbox with tabstop property set to False - I have no idea, unless
it is a behavior of the container its in. As far as the 'gun', it may be
better to write a console app. to read its output.
--
Terry
"Al Reid" wrote:
Terry,

I guess we have a similar background. 26 years in computing and used VB
since Version 2.

I don't do anything with the barcode data in the KeyPress event. I use it
to catch and handle the "enter" key. I guess I could inspect the data in
the KeyDown event to see if there is a difference. I just don't know what
key code combination could direct focus to a text box control that should
never receive focus since the TabStop property is false and there is no
other code that sets focus to the textbox. The textbox is also ReadOnly.
It's frustrating!!!

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message
news:78**********************************@microsof t.com...
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown
event
instead of the KeyPress event. They don't receive the same things! here
is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data
to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which
I
will have to look into. If you figure it out first, let me know.

--
Terry

>


Jul 14 '06 #15

P: n/a

Well, I finally solved the barcode scanner problem. The gun was putting out a LF after the CR and in the KeyDown event it showed up
as a Keys.Down (Down Arrow) and some how (and I never figured this one out) the next control in the tab order, regardless of the
TabStop property, got focus. I reprogrammed the device to only send the CR and now the problem is solved.

As far as the original validation issue, I started a new project (VB2005) and tried your approach It works except that pressing the
Esc key still causes the validation event to fire.

Form.CancelButton = Button1
Form.CausesValidation = False

Button1.CausesValidation = False

Public Class Form1
Private mblnCancel As Boolean

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles
TextBox1.Validating
If Not mblnCancel Then
Dim dteDate As DateTime
If DateTime.TryParse(TextBox1.Text, dteDate) Then
TextBox1.Text = dteDate.ToShortDateString
Else
MsgBox("Please enter a valid date.")
e.Cancel = True
End If
End If
End Sub

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

End Class

What am I missing?

--
Al Reid
"Terry" <Te***@nospam.nospamwrote in message news:76**********************************@microsof t.com...
Hi Al,
Nearly 40 years for me since my first college FORTRAN IV class! My, how
the years fly!
Well, one of the keys you would not see in either the keypress or keydown
events is the tab key, which of course will move the focus. Why it would
stop on a textbox with tabstop property set to False - I have no idea, unless
it is a behavior of the container its in. As far as the 'gun', it may be
better to write a console app. to read its output.
--
Terry
"Al Reid" wrote:
Terry,

I guess we have a similar background. 26 years in computing and used VB
since Version 2.

I don't do anything with the barcode data in the KeyPress event. I use it
to catch and handle the "enter" key. I guess I could inspect the data in
the KeyDown event to see if there is a difference. I just don't know what
key code combination could direct focus to a text box control that should
never receive focus since the TabStop property is false and there is no
other code that sets focus to the textbox. The textbox is also ReadOnly.
It's frustrating!!!

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message
news:78**********************************@microsof t.com...
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown
event
instead of the KeyPress event. They don't receive the same things! here
is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data
to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which
I
will have to look into. If you figure it out first, let me know.
>
--
Terry
>
>
>>

Jul 14 '06 #16

P: n/a
Yes, this is very frustrating! I tried to recreate what I did yesterday and
ended up having the same problem you are having! I did figure it out though
I don't remember having done this yesterday - but I must of - your going to
love this - set the text box's causesvalidation to False! I need to look
into this further. Maybe the only thing that should cause validation is the
OKButton and then do all the validating - I will let you know what I discover.

--
Terry
"Al Reid" wrote:
>
Well, I finally solved the barcode scanner problem. The gun was putting out a LF after the CR and in the KeyDown event it showed up
as a Keys.Down (Down Arrow) and some how (and I never figured this one out) the next control in the tab order, regardless of the
TabStop property, got focus. I reprogrammed the device to only send the CR and now the problem is solved.

As far as the original validation issue, I started a new project (VB2005) and tried your approach It works except that pressing the
Esc key still causes the validation event to fire.

Form.CancelButton = Button1
Form.CausesValidation = False

Button1.CausesValidation = False

Public Class Form1
Private mblnCancel As Boolean

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles
TextBox1.Validating
If Not mblnCancel Then
Dim dteDate As DateTime
If DateTime.TryParse(TextBox1.Text, dteDate) Then
TextBox1.Text = dteDate.ToShortDateString
Else
MsgBox("Please enter a valid date.")
e.Cancel = True
End If
End If
End Sub

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

End Class

What am I missing?

--
Al Reid
"Terry" <Te***@nospam.nospamwrote in message news:76**********************************@microsof t.com...
Hi Al,
Nearly 40 years for me since my first college FORTRAN IV class! My, how
the years fly!
Well, one of the keys you would not see in either the keypress or keydown
events is the tab key, which of course will move the focus. Why it would
stop on a textbox with tabstop property set to False - I have no idea, unless
it is a behavior of the container its in. As far as the 'gun', it may be
better to write a console app. to read its output.
--
Terry
"Al Reid" wrote:
Terry,
>
I guess we have a similar background. 26 years in computing and used VB
since Version 2.
>
I don't do anything with the barcode data in the KeyPress event. I use it
to catch and handle the "enter" key. I guess I could inspect the data in
the KeyDown event to see if there is a difference. I just don't know what
key code combination could direct focus to a text box control that should
never receive focus since the TabStop property is false and there is no
other code that sets focus to the textbox. The textbox is also ReadOnly.
It's frustrating!!!
>
--
Al Reid
>
"Terry" <Te***@nospam.nospamwrote in message
news:78**********************************@microsof t.com...
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown
event
instead of the KeyPress event. They don't receive the same things! here
is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data
to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which
I
will have to look into. If you figure it out first, let me know.

--
Terry


>
>
>
>


Jul 14 '06 #17

P: n/a
Hi Al,
There is another property at the form level that affects how this stuff
works - AutoValidate. I have come to the belief that the problem we are
seeing with the escape key is a bug. According to the documentation: "The
cancel button for a form is the button control that is clicked whenever the
user presses the ESC key." Which says to me the behavior s/b the same! I am
going to start a new thread - calling it a bug and see what happens.
--
Terry
"Al Reid" wrote:
>
Well, I finally solved the barcode scanner problem. The gun was putting out a LF after the CR and in the KeyDown event it showed up
as a Keys.Down (Down Arrow) and some how (and I never figured this one out) the next control in the tab order, regardless of the
TabStop property, got focus. I reprogrammed the device to only send the CR and now the problem is solved.

As far as the original validation issue, I started a new project (VB2005) and tried your approach It works except that pressing the
Esc key still causes the validation event to fire.

Form.CancelButton = Button1
Form.CausesValidation = False

Button1.CausesValidation = False

Public Class Form1
Private mblnCancel As Boolean

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles
TextBox1.Validating
If Not mblnCancel Then
Dim dteDate As DateTime
If DateTime.TryParse(TextBox1.Text, dteDate) Then
TextBox1.Text = dteDate.ToShortDateString
Else
MsgBox("Please enter a valid date.")
e.Cancel = True
End If
End If
End Sub

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

End Class

What am I missing?

--
Al Reid
"Terry" <Te***@nospam.nospamwrote in message news:76**********************************@microsof t.com...
Hi Al,
Nearly 40 years for me since my first college FORTRAN IV class! My, how
the years fly!
Well, one of the keys you would not see in either the keypress or keydown
events is the tab key, which of course will move the focus. Why it would
stop on a textbox with tabstop property set to False - I have no idea, unless
it is a behavior of the container its in. As far as the 'gun', it may be
better to write a console app. to read its output.
--
Terry
"Al Reid" wrote:
Terry,
>
I guess we have a similar background. 26 years in computing and used VB
since Version 2.
>
I don't do anything with the barcode data in the KeyPress event. I use it
to catch and handle the "enter" key. I guess I could inspect the data in
the KeyDown event to see if there is a difference. I just don't know what
key code combination could direct focus to a text box control that should
never receive focus since the TabStop property is false and there is no
other code that sets focus to the textbox. The textbox is also ReadOnly.
It's frustrating!!!
>
--
Al Reid
>
"Terry" <Te***@nospam.nospamwrote in message
news:78**********************************@microsof t.com...
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown
event
instead of the KeyPress event. They don't receive the same things! here
is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data
to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which
I
will have to look into. If you figure it out first, let me know.

--
Terry


>
>
>
>


Jul 14 '06 #18

P: n/a
Terry,

I tried the same scenario in VB6 and found that it works the way one would expect AND there is no need for the mCancel flag either.
Does look like a bug or perhaps and Undocumented System Feature!

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message news:CB**********************************@microsof t.com...
Hi Al,
There is another property at the form level that affects how this stuff
works - AutoValidate. I have come to the belief that the problem we are
seeing with the escape key is a bug. According to the documentation: "The
cancel button for a form is the button control that is clicked whenever the
user presses the ESC key." Which says to me the behavior s/b the same! I am
going to start a new thread - calling it a bug and see what happens.
--
Terry
"Al Reid" wrote:

Well, I finally solved the barcode scanner problem. The gun was putting out a LF after the CR and in the KeyDown event it
showed up
as a Keys.Down (Down Arrow) and some how (and I never figured this one out) the next control in the tab order, regardless of the
TabStop property, got focus. I reprogrammed the device to only send the CR and now the problem is solved.

As far as the original validation issue, I started a new project (VB2005) and tried your approach It works except that pressing
the
Esc key still causes the validation event to fire.

Form.CancelButton = Button1
Form.CausesValidation = False

Button1.CausesValidation = False

Public Class Form1
Private mblnCancel As Boolean

Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles
TextBox1.Validating
If Not mblnCancel Then
Dim dteDate As DateTime
If DateTime.TryParse(TextBox1.Text, dteDate) Then
TextBox1.Text = dteDate.ToShortDateString
Else
MsgBox("Please enter a valid date.")
e.Cancel = True
End If
End If
End Sub

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

End Class

What am I missing?

--
Al Reid
"Terry" <Te***@nospam.nospamwrote in message news:76**********************************@microsof t.com...
Hi Al,
Nearly 40 years for me since my first college FORTRAN IV class! My, how
the years fly!
Well, one of the keys you would not see in either the keypress or keydown
events is the tab key, which of course will move the focus. Why it would
stop on a textbox with tabstop property set to False - I have no idea, unless
it is a behavior of the container its in. As far as the 'gun', it may be
better to write a console app. to read its output.
--
Terry
>
>
"Al Reid" wrote:
>
Terry,

I guess we have a similar background. 26 years in computing and used VB
since Version 2.

I don't do anything with the barcode data in the KeyPress event. I use it
to catch and handle the "enter" key. I guess I could inspect the data in
the KeyDown event to see if there is a difference. I just don't know what
key code combination could direct focus to a text box control that should
never receive focus since the TabStop property is false and there is no
other code that sets focus to the textbox. The textbox is also ReadOnly.
It's frustrating!!!

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message
news:78**********************************@microsof t.com...
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown
event
instead of the KeyPress event. They don't receive the same things! here
is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data
to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which
I
will have to look into. If you figure it out first, let me know.
>
--
Terry
>
>
>>


Jul 14 '06 #19

P: n/a
Hi Al,
Don't know if you have been following the thread I started about the
escape key "bug", but if you search this community for "CancelButton vs
Escape Key", you can see the result including the work around for the escape
key. Also note that the "trick" to closing the form is not keeping a
seperate "canceling" flag, but to put "e.cancel=False" in the forms closing
event.
--
Terry
"Al Reid" wrote:
Terry,

I tried the same scenario in VB6 and found that it works the way one would expect AND there is no need for the mCancel flag either.
Does look like a bug or perhaps and Undocumented System Feature!

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message news:CB**********************************@microsof t.com...
Hi Al,
There is another property at the form level that affects how this stuff
works - AutoValidate. I have come to the belief that the problem we are
seeing with the escape key is a bug. According to the documentation: "The
cancel button for a form is the button control that is clicked whenever the
user presses the ESC key." Which says to me the behavior s/b the same! I am
going to start a new thread - calling it a bug and see what happens.
--
Terry
"Al Reid" wrote:
>
Well, I finally solved the barcode scanner problem. The gun was putting out a LF after the CR and in the KeyDown event it
showed up
as a Keys.Down (Down Arrow) and some how (and I never figured this one out) the next control in the tab order, regardless of the
TabStop property, got focus. I reprogrammed the device to only send the CR and now the problem is solved.
>
As far as the original validation issue, I started a new project (VB2005) and tried your approach It works except that pressing
the
Esc key still causes the validation event to fire.
>
Form.CancelButton = Button1
Form.CausesValidation = False
>
Button1.CausesValidation = False
>
Public Class Form1
Private mblnCancel As Boolean
>
Private Sub TextBox1_Validating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles
TextBox1.Validating
If Not mblnCancel Then
Dim dteDate As DateTime
If DateTime.TryParse(TextBox1.Text, dteDate) Then
TextBox1.Text = dteDate.ToShortDateString
Else
MsgBox("Please enter a valid date.")
e.Cancel = True
End If
End If
End Sub
>
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
mblnCancel = True
Me.Close()
End Sub
>
End Class
>
What am I missing?
>
--
Al Reid
>
>
"Terry" <Te***@nospam.nospamwrote in message news:76**********************************@microsof t.com...
Hi Al,
Nearly 40 years for me since my first college FORTRAN IV class! My, how
the years fly!
Well, one of the keys you would not see in either the keypress or keydown
events is the tab key, which of course will move the focus. Why it would
stop on a textbox with tabstop property set to False - I have no idea, unless
it is a behavior of the container its in. As far as the 'gun', it may be
better to write a console app. to read its output.
--
Terry


"Al Reid" wrote:

Terry,
>
I guess we have a similar background. 26 years in computing and used VB
since Version 2.
>
I don't do anything with the barcode data in the KeyPress event. I use it
to catch and handle the "enter" key. I guess I could inspect the data in
the KeyDown event to see if there is a difference. I just don't know what
key code combination could direct focus to a text box control that should
never receive focus since the TabStop property is false and there is no
other code that sets focus to the textbox. The textbox is also ReadOnly.
It's frustrating!!!
>
--
Al Reid
>
"Terry" <Te***@nospam.nospamwrote in message
news:78**********************************@microsof t.com...
Hi again Al,
On the barcode reader problem. Maybe you should be using the KeyDown
event
instead of the KeyPress event. They don't receive the same things! here
is
a line copied from the documentation: "The KeyPress event is not raised by
noncharacter keys; however, the noncharacter keys do raise the KeyDown and
KeyUp events." My guess is that the gun is sending some noncharacter data
to
you. I am new to VB .net comming from VB6, but that was also the case in
VB6. Also in the docs on KeyDown there is a mention of "IsInputKey" which
I
will have to look into. If you figure it out first, let me know.

--
Terry


>
>
>
>
>
>
>


Jul 18 '06 #20

P: n/a
Terry,

Yes I've been following it. I added the code to handle the esc key per the "bug" thread and it works. However, after I removed the
"canceling" flag and added the "e.cancel=False" to the form's FormClosing event, I once again see the validation when clicking on
the cancel button, but the form then closes after displaying the validation error. I think it works better with the canceling flag.

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message news:4E**********************************@microsof t.com...
Hi Al,
Don't know if you have been following the thread I started about the
escape key "bug", but if you search this community for "CancelButton vs
Escape Key", you can see the result including the work around for the escape
key. Also note that the "trick" to closing the form is not keeping a
seperate "canceling" flag, but to put "e.cancel=False" in the forms closing
event.
--
Terry
"Al Reid" wrote:
Terry,

I tried the same scenario in VB6 and found that it works the way one would expect AND there is no need for the mCancel flag
either.
Does look like a bug or perhaps and Undocumented System Feature!

--
Al Reid

Jul 18 '06 #21

P: n/a
Ok, I remember now, you are using a modal msgbox in your validation code. In
this case, you will need the mCanceling flag. If you were using an
errorprovider, then the error would be set, the focus would be returned to
the textbox, the form closing event would then fire and it changes the cancel
flag to false and the form closes. Its only because of the messagebox that
you need to keep the flag.
--
Terry
"Al Reid" wrote:
Terry,

Yes I've been following it. I added the code to handle the esc key per the "bug" thread and it works. However, after I removed the
"canceling" flag and added the "e.cancel=False" to the form's FormClosing event, I once again see the validation when clicking on
the cancel button, but the form then closes after displaying the validation error. I think it works better with the canceling flag.

--
Al Reid

"Terry" <Te***@nospam.nospamwrote in message news:4E**********************************@microsof t.com...
Hi Al,
Don't know if you have been following the thread I started about the
escape key "bug", but if you search this community for "CancelButton vs
Escape Key", you can see the result including the work around for the escape
key. Also note that the "trick" to closing the form is not keeping a
seperate "canceling" flag, but to put "e.cancel=False" in the forms closing
event.
--
Terry
"Al Reid" wrote:
Terry,
>
I tried the same scenario in VB6 and found that it works the way one would expect AND there is no need for the mCancel flag
either.
Does look like a bug or perhaps and Undocumented System Feature!
>
--
Al Reid
>


Jul 18 '06 #22

This discussion thread is closed

Replies have been disabled for this discussion.