"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 ***
>

"Al Reid" wrote:

> "Terry" <Terry@nospam.nospam> wrote in message news:9059256D-E5C4-41D7-B702-667305E23EA4@microsoft.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
>
>
>

"Terry" <Terry@nospam.nospam> wrote in message news:70E9A54F-85F3-49D4-AB1E-6EAFC54FCCE9@microsoft.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
>
>

"Al Reid" <arei***@reidDASHhome.com> wrote in message news:uAhLRUppGHA.2328@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" <Terry@nospam.nospam> wrote in message news:70E9A54F-85F3-49D4-AB1E-6EAFC54FCCE9@microsoft.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
> >
> >
>
>

"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" <arei***@reidDASHhome.com> wrote in message news:uAhLRUppGHA.2328@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" <Terry@nospam.nospam> wrote in message news:70E9A54F-85F3-49D4-AB1E-6EAFC54FCCE9@microsoft.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
> > >
> > >
> >
> >
>
>
>

"Terry" <Terry@nospam.nospam> wrote in message
news:EFEE22CF-A2CD-47BC-B07C-17D8D3B10904@microsoft.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
>
>

"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" <Terry@nospam.nospam> wrote in message
> news:EFEE22CF-A2CD-47BC-B07C-17D8D3B10904@microsoft.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
> >
> >
>
>
>

"Terry" <Terry@nospam.nospam> wrote in message
news:785ACE72-1ED6-4D48-B6A6-EEEECB00E729@microsoft.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
>
>
>>

"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" <Terry@nospam.nospam> wrote in message
> news:785ACE72-1ED6-4D48-B6A6-EEEECB00E729@microsoft.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
> >
> >
> >>
>
>
>

"Terry" <Terry@nospam.nospam> wrote in message news:762A1633-BA78-489B-B659-E1BFDBA06C0F@microsoft.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" <Terry@nospam.nospam> wrote in message
> > news:785ACE72-1ED6-4D48-B6A6-EEEECB00E729@microsoft.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
> > >
> > >
> > >>
> >
> >
> >

"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" <Terry@nospam.nospam> wrote in message news:762A1633-BA78-489B-B659-E1BFDBA06C0F@microsoft.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" <Terry@nospam.nospam> wrote in message
> > > news:785ACE72-1ED6-4D48-B6A6-EEEECB00E729@microsoft.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
> > > >
> > > >
> > > >>
> > >
> > >
> > >
>
>
>

"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" <Terry@nospam.nospam> wrote in message news:762A1633-BA78-489B-B659-E1BFDBA06C0F@microsoft.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" <Terry@nospam.nospam> wrote in message
> > > news:785ACE72-1ED6-4D48-B6A6-EEEECB00E729@microsoft.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
> > > >
> > > >
> > > >>
> > >
> > >
> > >
>
>
>

"Terry" <Terry@nospam.nospam> wrote in message news:CB94213D-B3E8-4E8F-BF6A-ED70A69BDBAD@microsoft.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" <Terry@nospam.nospam> wrote in message news:762A1633-BA78-489B-B659-E1BFDBA06C0F@microsoft.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" <Terry@nospam.nospam> wrote in message
> > > > news:785ACE72-1ED6-4D48-B6A6-EEEECB00E729@microsoft.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
> > > > >
> > > > >
> > > > >>
> > > >
> > > >
> > > >
> >
> >
> >

"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" <Terry@nospam.nospam> wrote in message news:CB94213D-B3E8-4E8F-BF6A-ED70A69BDBAD@microsoft.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" <Terry@nospam.nospam> wrote in message news:762A1633-BA78-489B-B659-E1BFDBA06C0F@microsoft.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" <Terry@nospam.nospam> wrote in message
> > > > > news:785ACE72-1ED6-4D48-B6A6-EEEECB00E729@microsoft.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
> > > > > >
> > > > > >
> > > > > >>
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>

"Terry" <Terry@nospam.nospam> wrote in message news:4E7BABDE-1173-4143-83FE-972A7D38A1BA@microsoft.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
> >

"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" <Terry@nospam.nospam> wrote in message news:4E7BABDE-1173-4143-83FE-972A7D38A1BA@microsoft.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
> > >
>
>
>

"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 ***
>