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

Validating Integer Problems....

P: n/a

Hi Experts !

I have a Winform Program in C# / .NET 2.0

I would like to ensure that a value in a TextBox is a valid Int32 when user
get out of it (TextBox loose focus)

BUT : The "Validating" Event of a TextBox does NOT fire when user click on
controls like ToolStripButton, ToolStripMenu,.. (in fact Validating event is
fired AFTER the Click event of the ToolStripButton, so it's too late to
check...)

In this kind of case, does it mean that a programmer using .NET MUST check
at more than one place that the value in a given TextBox is a valid Integer
? (Once in the validating event, and Once in EACH ToolStripButton(menu,..)
Click) ???

If no : HOW CAN I DO to check if a TextBox have a valid Int32 value when
TextBox loose focus AND when user click on a ToolStripButton (or menu)
?????????

If yes : How can MS think that it's a good programming practice and modern
to check the same basic and simple thing at different places in the same
form. Why this kind of problem in the "Third version of their very last
programming language" ?

Any solution is welcome and will save me a lot of headache..

Steph
Nov 9 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I would go in a different direction, I will not let the user enter
non-numeric values

There are several ways of doing this and IIRC in 2.0 you have something to
force this.

Anyway, you can use the KeyDown event to reject the invalid keys.

additionally you can derive from Textbox and override CreateParams

"TheSteph" wrote:
>
Hi Experts !

I have a Winform Program in C# / .NET 2.0

I would like to ensure that a value in a TextBox is a valid Int32 when user
get out of it (TextBox loose focus)

BUT : The "Validating" Event of a TextBox does NOT fire when user click on
controls like ToolStripButton, ToolStripMenu,.. (in fact Validating event is
fired AFTER the Click event of the ToolStripButton, so it's too late to
check...)

In this kind of case, does it mean that a programmer using .NET MUST check
at more than one place that the value in a given TextBox is a valid Integer
? (Once in the validating event, and Once in EACH ToolStripButton(menu,..)
Click) ???

If no : HOW CAN I DO to check if a TextBox have a valid Int32 value when
TextBox loose focus AND when user click on a ToolStripButton (or menu)
?????????

If yes : How can MS think that it's a good programming practice and modern
to check the same basic and simple thing at different places in the same
form. Why this kind of problem in the "Third version of their very last
programming language" ?

Any solution is welcome and will save me a lot of headache..

Steph
Nov 9 '06 #2

P: n/a
Anyway, you can use the KeyDown event to reject the invalid keys.

All sample code I found accept numbers like 9999999999 that are build from
correct keys but are not valid Int32 values...

Moreover I have some "encoding helper" job to do while validating the
final value : Example : 12,3456,789.25 should be accepted and transformed to
123.456.789,25 ( "," is decimal sep here). This kind of things can be done
only at Validating time. hence the problem remains with controls like
ToolStripButtons.

The things I can't understand is that Controls have a Validating event
that is not guaranteed to be fired when user click on other controls (like
ToolStripButton,.)...unbelivable... Imagine a click event on a control that
is not guaranteed to be fired when user click the control. unreliable so
unusable from a professional standpoint..

Thanks for your help, I keep searching a validating solution. The best is
maybe to wait until VS "Hawaii" to be done...

Steph.

"ignacio machin" <ig***********@discussions.microsoft.comwrote in message
news:81**********************************@microsof t.com...
I would go in a different direction, I will not let the user enter
non-numeric values

There are several ways of doing this and IIRC in 2.0 you have something to
force this.

Anyway, you can use the KeyDown event to reject the invalid keys.

additionally you can derive from Textbox and override CreateParams

"TheSteph" wrote:

Hi Experts !

I have a Winform Program in C# / .NET 2.0

I would like to ensure that a value in a TextBox is a valid Int32 when
user
get out of it (TextBox loose focus)

BUT : The "Validating" Event of a TextBox does NOT fire when user click
on
controls like ToolStripButton, ToolStripMenu,.. (in fact Validating
event is
fired AFTER the Click event of the ToolStripButton, so it's too late to
check...)

In this kind of case, does it mean that a programmer using .NET MUST
check
at more than one place that the value in a given TextBox is a valid
Integer
? (Once in the validating event, and Once in EACH
ToolStripButton(menu,..)
Click) ???

If no : HOW CAN I DO to check if a TextBox have a valid Int32 value when
TextBox loose focus AND when user click on a ToolStripButton (or menu)
?????????

If yes : How can MS think that it's a good programming practice and
modern
to check the same basic and simple thing at different places in the same
form. Why this kind of problem in the "Third version of their very last
programming language" ?

Any solution is welcome and will save me a lot of headache..

Steph


Nov 10 '06 #3

P: n/a
Hi,

What make u think that it will be different in "hawaii" ?
you can do validation in the KeyDown, the ugliest one would be trying to
convert it to Int32 and handling the exception.

Take a look at CausesValidation though.

"TheSteph" wrote:
Anyway, you can use the KeyDown event to reject the invalid keys.

All sample code I found accept numbers like 9999999999 that are build from
correct keys but are not valid Int32 values...

Moreover I have some "encoding helper" job to do while validating the
final value : Example : 12,3456,789.25 should be accepted and transformed to
123.456.789,25 ( "," is decimal sep here). This kind of things can be done
only at Validating time. hence the problem remains with controls like
ToolStripButtons.

The things I can't understand is that Controls have a Validating event
that is not guaranteed to be fired when user click on other controls (like
ToolStripButton,.)...unbelivable... Imagine a click event on a control that
is not guaranteed to be fired when user click the control. unreliable so
unusable from a professional standpoint..

Thanks for your help, I keep searching a validating solution. The best is
maybe to wait until VS "Hawaii" to be done...

Steph.

"ignacio machin" <ig***********@discussions.microsoft.comwrote in message
news:81**********************************@microsof t.com...
I would go in a different direction, I will not let the user enter
non-numeric values

There are several ways of doing this and IIRC in 2.0 you have something to
force this.

Anyway, you can use the KeyDown event to reject the invalid keys.

additionally you can derive from Textbox and override CreateParams

"TheSteph" wrote:
>
Hi Experts !
>
>
>
I have a Winform Program in C# / .NET 2.0
>
>
>
I would like to ensure that a value in a TextBox is a valid Int32 when
user
get out of it (TextBox loose focus)
>
>
>
BUT : The "Validating" Event of a TextBox does NOT fire when user click
on
controls like ToolStripButton, ToolStripMenu,.. (in fact Validating
event is
fired AFTER the Click event of the ToolStripButton, so it's too late to
check...)
>
>
>
In this kind of case, does it mean that a programmer using .NET MUST
check
at more than one place that the value in a given TextBox is a valid
Integer
? (Once in the validating event, and Once in EACH
ToolStripButton(menu,..)
Click) ???
>
>
>
If no : HOW CAN I DO to check if a TextBox have a valid Int32 value when
TextBox loose focus AND when user click on a ToolStripButton (or menu)
?????????
>
>
>
If yes : How can MS think that it's a good programming practice and
modern
to check the same basic and simple thing at different places in the same
form. Why this kind of problem in the "Third version of their very last
programming language" ?
>
>
>
Any solution is welcome and will save me a lot of headache..
>
>
>
Steph
>
>
>


Nov 10 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.