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

Textbox LostFocus event fires after Command Button's OnClick event

P: n/a
WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a string.
On the LostFocus event, the textbox formats the string into a preferred
format.

However, if the user presses the "Save" button while the textbox has
the focus, the LostFocus code doesn't run at the right time, so that
the "Save" function is dealing with an incorrectly formatted string and
the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain different
strings but must all be formatted in the correct format. Here is the
function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus

Dim txtTextBox As TextBox = CType(sender, TextBox)

txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward

Aug 7 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Edward,

Why don't you set the enabled property to false on the save button and on
the lostfocus event, enable the save button, and on the gotfocus of each
textbox, set the enabled on the save button to false, until the textbox(es)
are populated?
--
Michael Bragg, President
eSolTec, Inc.
a 501(C)(3) organization
MS Authorized MAR
looking for used laptops for developmentally disabled.
"te********@hotmail.com" wrote:
WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a string.
On the LostFocus event, the textbox formats the string into a preferred
format.

However, if the user presses the "Save" button while the textbox has
the focus, the LostFocus code doesn't run at the right time, so that
the "Save" function is dealing with an incorrectly formatted string and
the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain different
strings but must all be formatted in the correct format. Here is the
function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus

Dim txtTextBox As TextBox = CType(sender, TextBox)

txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward

Aug 7 '06 #2

P: n/a
Try using the textbox's "Validating" event..that's what it is for and should
work.
--
Dennis in Houston
"eSolTec, Inc. 501(c)(3)" wrote:
Edward,

Why don't you set the enabled property to false on the save button and on
the lostfocus event, enable the save button, and on the gotfocus of each
textbox, set the enabled on the save button to false, until the textbox(es)
are populated?
--
Michael Bragg, President
eSolTec, Inc.
a 501(C)(3) organization
MS Authorized MAR
looking for used laptops for developmentally disabled.
"te********@hotmail.com" wrote:
WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a string.
On the LostFocus event, the textbox formats the string into a preferred
format.

However, if the user presses the "Save" button while the textbox has
the focus, the LostFocus code doesn't run at the right time, so that
the "Save" function is dealing with an incorrectly formatted string and
the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain different
strings but must all be formatted in the correct format. Here is the
function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus

Dim txtTextBox As TextBox = CType(sender, TextBox)

txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward
Aug 7 '06 #3

P: n/a

te********@hotmail.com wrote:
[snip]

Thanks, guys, I'll give these a shot.

Edward

Aug 7 '06 #4

P: n/a
You can put a My.Application.DoEvents() call as the first statement in the
Buttons click event. The pending lost focus event will be fired and you can
then proceed with with the save logic.

--
Terry
"te********@hotmail.com" wrote:
WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a string.
On the LostFocus event, the textbox formats the string into a preferred
format.

However, if the user presses the "Save" button while the textbox has
the focus, the LostFocus code doesn't run at the right time, so that
the "Save" function is dealing with an incorrectly formatted string and
the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain different
strings but must all be formatted in the correct format. Here is the
function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus

Dim txtTextBox As TextBox = CType(sender, TextBox)

txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward

Aug 7 '06 #5

P: n/a

no no no.. bad Terry, bad.

-Boo
You can put a My.Application.DoEvents() call as the first statement in
the Buttons click event. The pending lost focus event will be fired
and you can then proceed with with the save logic.

"te********@hotmail.com" wrote:
>WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a
string. On the LostFocus event, the textbox formats the string into a
preferred format.

However, if the user presses the "Save" button while the textbox has
the focus, the LostFocus code doesn't run at the right time, so that
the "Save" function is dealing with an incorrectly formatted string
and the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain
different strings but must all be formatted in the correct format.
Here is the function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus
Dim txtTextBox As TextBox = CType(sender, TextBox)

txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward

Aug 8 '06 #6

P: n/a

Terry wrote:
You can put a My.Application.DoEvents() call as the first statement in the
Buttons click event. The pending lost focus event will be fired and you can
then proceed with with the save logic.
Tried that - didn't work.

Edward

Aug 8 '06 #7

P: n/a

Dennis wrote:
Try using the textbox's "Validating" event..that's what it is for and should
work.
--
Dennis in Houston
Tried that - didn't work. The button's OnClick event still pre-empts
the textbox's Validating event.

Edward

Aug 8 '06 #8

P: n/a
Why?
--
Terry
"GhostInAK" wrote:
>
no no no.. bad Terry, bad.

-Boo
You can put a My.Application.DoEvents() call as the first statement in
the Buttons click event. The pending lost focus event will be fired
and you can then proceed with with the save logic.

"te********@hotmail.com" wrote:
WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a
string. On the LostFocus event, the textbox formats the string into a
preferred format.

However, if the user presses the "Save" button while the textbox has
the focus, the LostFocus code doesn't run at the right time, so that
the "Save" function is dealing with an incorrectly formatted string
and the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain
different strings but must all be formatted in the correct format.
Here is the function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus
Dim txtTextBox As TextBox = CType(sender, TextBox)

txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward


Aug 8 '06 #9

P: n/a
Hmmmm,
Worked for me.
--
Terry
"te********@hotmail.com" wrote:
>
Terry wrote:
You can put a My.Application.DoEvents() call as the first statement in the
Buttons click event. The pending lost focus event will be fired and you can
then proceed with with the save logic.

Tried that - didn't work.

Edward

Aug 8 '06 #10

P: n/a
Hello Terry,

Because it's not guaranteed. The results will be unpredictable.

The proper method, and the mechanism provided to do exactly this, is to use
the validating event.

-Boo
Why?

"GhostInAK" wrote:
>no no no.. bad Terry, bad.

-Boo
>>You can put a My.Application.DoEvents() call as the first statement
in the Buttons click event. The pending lost focus event will be
fired and you can then proceed with with the save logic.

"te********@hotmail.com" wrote:

WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a
string. On the LostFocus event, the textbox formats the string into
a preferred format.

However, if the user presses the "Save" button while the textbox
has the focus, the LostFocus code doesn't run at the right time, so
that the "Save" function is dealing with an incorrectly formatted
string and the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain
different strings but must all be formatted in the correct format.
Here is the function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles
txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus
Dim txtTextBox As TextBox = CType(sender, TextBox)
txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward

Aug 8 '06 #11

P: n/a
Hi Ghost,
Had never heard that (unpredictable) before - is this something
relevent to VS2005? Is it considered a bug? It seems to me that any
language construct that produces 'unpredicable' results should be considered
a bug.
I realize that the validating event is MS's prefered way to do this, the
problem is that there are bugs in this method such as using an escape key to
click the cancel button - does not work properly. Basically, my experience
is that using the validating event really only works if you are willing to
postpone all validation until the user presses the "ok' or 'Save' button. If
you want to validate as the user moves from control to control - the
validating event is a nightmare. Of course, I am no expert and if you have
some knowledge to the contrary or know of some trick, I am all ears!
--
Terry
"GhostInAK" wrote:
Hello Terry,

Because it's not guaranteed. The results will be unpredictable.

The proper method, and the mechanism provided to do exactly this, is to use
the validating event.

-Boo
Why?

"GhostInAK" wrote:
no no no.. bad Terry, bad.

-Boo

You can put a My.Application.DoEvents() call as the first statement
in the Buttons click event. The pending lost focus event will be
fired and you can then proceed with with the save logic.

"te********@hotmail.com" wrote:

WINDOWS FORMS

I've a form that has a textbox that allows the user to enter a
string. On the LostFocus event, the textbox formats the string into
a preferred format.

However, if the user presses the "Save" button while the textbox
has the focus, the LostFocus code doesn't run at the right time, so
that the "Save" function is dealing with an incorrectly formatted
string and the whole caboodle goes splat.

I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain
different strings but must all be formatted in the correct format.
Here is the function that handles this:

Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles
txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus
Dim txtTextBox As TextBox = CType(sender, TextBox)
txtTextBox.Text = FormatArbTime(txtTextBox.Text)

End Sub

Any thoughts?

Edward


Aug 8 '06 #12

P: n/a
Hello Terry,

It's not a bug or something 05-specific. You are attempting to control the
flow of events by massaging the message pump. By it's very nature this is
unpredictable. Any results you have which conform to your expectations are
purely coincidental and not by design.

On an architectural note.. I've always found the overhead of doing field
validation as the user inputs or immediately after they input to be a higher
cost than it's really worth. The ROI just isn't there. It's much easier
to fix any issues with the escape key/cancel button than it is to invent
a whole new validation scheme.

On a usability note, I absolutely hate using programs that force me to fix
input errors as I make them.. 95% of the time I dont make input errors..
and when I do it completely breaks my train of thought to have to stop, fix
something, and then move on. I'd rather get a summary of errors when Im
finished and have pressed the OK button.

-Boo
Hi Ghost,
Had never heard that (unpredictable) before - is this something
relevent to VS2005? Is it considered a bug? It seems to me that any
language construct that produces 'unpredicable' results should be
considered
a bug.
I realize that the validating event is MS's prefered way to do this,
the
problem is that there are bugs in this method such as using an escape
key to
click the cancel button - does not work properly. Basically, my
experience
is that using the validating event really only works if you are
willing to
postpone all validation until the user presses the "ok' or 'Save'
button. If
you want to validate as the user moves from control to control - the
validating event is a nightmare. Of course, I am no expert and if you
have
some knowledge to the contrary or know of some trick, I am all ears!
"GhostInAK" wrote:
>Hello Terry,

Because it's not guaranteed. The results will be unpredictable.

The proper method, and the mechanism provided to do exactly this, is
to use the validating event.

-Boo
>>Why?

"GhostInAK" wrote:

no no no.. bad Terry, bad.

-Boo

You can put a My.Application.DoEvents() call as the first
statement in the Buttons click event. The pending lost focus
event will be fired and you can then proceed with with the save
logic.
>
"te********@hotmail.com" wrote:
>
>WINDOWS FORMS
>>
>I've a form that has a textbox that allows the user to enter a
>string. On the LostFocus event, the textbox formats the string
>into a preferred format.
>>
>However, if the user presses the "Save" button while the textbox
>has the focus, the LostFocus code doesn't run at the right time,
>so that the "Save" function is dealing with an incorrectly
>formatted string and the whole caboodle goes splat.
>>
>I like the LostFocus event, because I've got upwards of 14 such
>textboxes on various tabs on the form, which all may contain
>different strings but must all be formatted in the correct
>format. Here is the function that handles this:
>>
>Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
>ByVal e As System.EventArgs) Handles
>txtMonStartArbitrated.LostFocus,
>txtMonEndArbitrated.LostFocus, _
>txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
>txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
>txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
>_
>txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
>txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
>txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus
>Dim txtTextBox As TextBox = CType(sender, TextBox)
>txtTextBox.Text = FormatArbTime(txtTextBox.Text)
>End Sub
>>
>Any thoughts?
>>
>Edward
>>

Aug 9 '06 #13

P: n/a
Hi Ghost,
Thanks for the input. I agree with you on *most* situations where the
user is entering data on a form. Validation can/should wait till the user
indicates that they are done. But, in some cases it can not. The kind of
apps that I work on most of the time fall into this catqagory. Often things
are changing with every keystroke (which is easier to handle) and whenever
the user navigates on the screen. I have never understood why a buttons
click event fires before the active control's lostfocus event, but it does
and going back to VB3, I have used the DoEvents call to handle any pending
lostfocus event. This has worked through VB6. I have not ported anything
to VB 2005 yet and based on what you are telling me, maybe I need to
reconsider how I do this.
Thanks again for taking the time,
--
Terry
"GhostInAK" wrote:
Hello Terry,

It's not a bug or something 05-specific. You are attempting to control the
flow of events by massaging the message pump. By it's very nature this is
unpredictable. Any results you have which conform to your expectations are
purely coincidental and not by design.

On an architectural note.. I've always found the overhead of doing field
validation as the user inputs or immediately after they input to be a higher
cost than it's really worth. The ROI just isn't there. It's much easier
to fix any issues with the escape key/cancel button than it is to invent
a whole new validation scheme.

On a usability note, I absolutely hate using programs that force me to fix
input errors as I make them.. 95% of the time I dont make input errors..
and when I do it completely breaks my train of thought to have to stop, fix
something, and then move on. I'd rather get a summary of errors when Im
finished and have pressed the OK button.

-Boo
Hi Ghost,
Had never heard that (unpredictable) before - is this something
relevent to VS2005? Is it considered a bug? It seems to me that any
language construct that produces 'unpredicable' results should be
considered
a bug.
I realize that the validating event is MS's prefered way to do this,
the
problem is that there are bugs in this method such as using an escape
key to
click the cancel button - does not work properly. Basically, my
experience
is that using the validating event really only works if you are
willing to
postpone all validation until the user presses the "ok' or 'Save'
button. If
you want to validate as the user moves from control to control - the
validating event is a nightmare. Of course, I am no expert and if you
have
some knowledge to the contrary or know of some trick, I am all ears!
"GhostInAK" wrote:
Hello Terry,

Because it's not guaranteed. The results will be unpredictable.

The proper method, and the mechanism provided to do exactly this, is
to use the validating event.

-Boo

Why?

"GhostInAK" wrote:

no no no.. bad Terry, bad.

-Boo

You can put a My.Application.DoEvents() call as the first
statement in the Buttons click event. The pending lost focus
event will be fired and you can then proceed with with the save
logic.

"te********@hotmail.com" wrote:

WINDOWS FORMS
>
I've a form that has a textbox that allows the user to enter a
string. On the LostFocus event, the textbox formats the string
into a preferred format.
>
However, if the user presses the "Save" button while the textbox
has the focus, the LostFocus code doesn't run at the right time,
so that the "Save" function is dealing with an incorrectly
formatted string and the whole caboodle goes splat.
>
I like the LostFocus event, because I've got upwards of 14 such
textboxes on various tabs on the form, which all may contain
different strings but must all be formatted in the correct
format. Here is the function that handles this:
>
Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
ByVal e As System.EventArgs) Handles
txtMonStartArbitrated.LostFocus,
txtMonEndArbitrated.LostFocus, _
txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
_
txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus
Dim txtTextBox As TextBox = CType(sender, TextBox)
txtTextBox.Text = FormatArbTime(txtTextBox.Text)
End Sub
>
Any thoughts?
>
Edward
>


Aug 9 '06 #14

P: n/a
Edward,
- What does your OnClick event look like?

Are you overriding the OnClick method or are you handling the Click event
itself?

If you are overriding the OnClick method are you calling the MyBase.OnClick
first, last or not calling it?

- Which version of .NET?

Using code similar in .NET 2.0 (VS 2005) to:

Private Sub TextBox1_LostFocus(ByVal sender As Object, ByVal e As
System.EventArgs) Handles TextBox1.LostFocus
Debug.WriteLine("TextBox1_LostFocus", Application.ProductName)
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Debug.WriteLine("Button1_Click", Application.ProductName)
End Sub

I am not able to reproduce the problem.
Using a custom button similar to:

Public Class Button
Inherits System.Windows.Forms.Button

Protected Overrides Sub OnClick(ByVal e As System.EventArgs)
Debug.WriteLine("OnClick", Application.ProductName)
MyBase.OnClick(e)
End Sub

End Class

I am not able to reproduce the problem (again in .NET 2.0).

- Which OS?

The above were tested on Windows XP Pro 32bit.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
<te********@hotmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...
| WINDOWS FORMS
|
| I've a form that has a textbox that allows the user to enter a string.
| On the LostFocus event, the textbox formats the string into a preferred
| format.
|
| However, if the user presses the "Save" button while the textbox has
| the focus, the LostFocus code doesn't run at the right time, so that
| the "Save" function is dealing with an incorrectly formatted string and
| the whole caboodle goes splat.
|
| I like the LostFocus event, because I've got upwards of 14 such
| textboxes on various tabs on the form, which all may contain different
| strings but must all be formatted in the correct format. Here is the
| function that handles this:
|
| Private Sub txtTimeStartAndEndArbitrated(ByVal sender As Object,
| ByVal e As System.EventArgs) Handles txtMonStartArbitrated.LostFocus,
| txtMonEndArbitrated.LostFocus, _
| txtTueStartArbitrated.LostFocus, txtTueEndArbitrated.LostFocus, _
| txtWedStartArbitrated.LostFocus, txtWedEndArbitrated.LostFocus, _
| txtThurStartArbitrated.LostFocus, txtThurEndArbitrated.LostFocus,
| _
| txtFriStartArbitrated.LostFocus, txtFriEndArbitrated.LostFocus, _
| txtSatStartArbitrated.LostFocus, txtSatEndArbitrated.LostFocus, _
| txtSunStartArbitrated.LostFocus, txtSunEndArbitrated.LostFocus
|
| Dim txtTextBox As TextBox = CType(sender, TextBox)
|
| txtTextBox.Text = FormatArbTime(txtTextBox.Text)
|
| End Sub
|
| Any thoughts?
|
| Edward
|
Aug 10 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.