Textbox validated event shortcoming?

[Guest]

Hi,

In a .NET 2.0 winforms application, I've got a textbox that, when updated,
uses the validated event to cascade the change to another textbox (along with
another value). This works well if the user does indeed move the cursor to
another textbox, but if the user clicks my "done" toolstripbutton after
making a change in the textbox but without moving the cursor out, the
validated event never fires. I have a pretty bad workaround where in the
"done" event handler, I check to see if the original textbox has the focus,
and if it does, I move the focus to another textbox and put it back. Is there
a better way to handle this situation?

Thanks...

-Ben

 

[RobinS]

When the user clicks the "done" button, invoke Validate yourself. It's just
a method on the form.

Robin S.

 

[Tim Van Wassenhove]

Ben R. schreef:

Hi,

In a .NET 2.0 winforms application, I've got a textbox that, when updated,
uses the validated event to cascade the change to another textbox (along with
another value). This works well if the user does indeed move the cursor to
another textbox, but if the user clicks my "done" toolstripbutton after
making a change in the textbox but without moving the cursor out, the
validated event never fires. I have a pretty bad workaround where in the
"done" event handler, I check to see if the original textbox has the focus,
and if it does, I move the focus to another textbox and put it back. Is there
a better way to handle this situation?

Imho the whole 'Validation' process is broken... (eg: On a TabControl
it's possible to insert invalid data into a DataGridView and select
another tab anyway (the first time you click on the tab, the validating
event will be raised, but if the user clicks again it isn't raised
anymore...)

I would recommend that you implement your validation logic, and run it
whenever the user decides to submit/validate/whatever he wants to do/...

 

[Jeffrey Tan[MSFT]]

Hi Ben,

Yes, I can reproduce this behavior. Actually, this is by design.

.Net Winform Validated event is triggered when that control is in the
process of losing focus. Please refer to the link below for the complete
events order of Validated event:
"Control.Validated Event "
http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.valida
ted.aspx

"When you change the focus by using the keyboard (TAB, SHIFT+TAB, and so
on), by calling the Select or SelectNextControl methods, or by setting the
ContainerControl.ActiveControl property to the current form, focus events
occur in the following order:

Enter
GotFocus
Leave
Validating
Validated
LostFocus

When you change the focus by using the mouse or by calling the Focus
method, focus events occur in the following order:

Enter
GotFocus
LostFocus
Leave
Validating
Validated"

In our scenario, the ToolStripButton clicking does not cause the focus in
the TextBox to change, so the Validated event does not fire. I think this
makes sense: you may have "Cut", "Paste", "Copy" ToolStripButtons in the
ToolStrip as the shortcuts for editing the text in the TextBox, if clicking
any button steals the TextBox focus, it is hard for you to leverage these
ToolStripButtons to edit the TextBox text.

To resolve this problem, you may take Robin's suggestion of calling the
Validated event handler method directly. It is just a normal Form method,
you may call it directly in ToolStripButton.Click event for usage.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks to all three of you. I ended up just calling the form's validate
method, which triggered all necessary validation events.

-Ben

Hi Ben,

Yes, I can reproduce this behavior. Actually, this is by design.

.Net Winform Validated event is triggered when that control is in the
process of losing focus. Please refer to the link below for the complete
events order of Validated event:
"Control.Validated Event "
http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.valida
ted.aspx

"When you change the focus by using the keyboard (TAB, SHIFT+TAB, and so
on), by calling the Select or SelectNextControl methods, or by setting the
ContainerControl.ActiveControl property to the current form, focus events
occur in the following order:

Enter
GotFocus
Leave
Validating
Validated
LostFocus

When you change the focus by using the mouse or by calling the Focus
method, focus events occur in the following order:

Enter
GotFocus
LostFocus
Leave
Validating
Validated"

In our scenario, the ToolStripButton clicking does not cause the focus in
the TextBox to change, so the Validated event does not fire. I think this
makes sense: you may have "Cut", "Paste", "Copy" ToolStripButtons in the
ToolStrip as the shortcuts for editing the text in the TextBox, if clicking
any button steals the TextBox focus, it is hard for you to leverage these
ToolStripButtons to edit the TextBox text.

To resolve this problem, you may take Robin's suggestion of calling the
Validated event handler method directly. It is just a normal Form method,
you may call it directly in ToolStripButton.Click event for usage.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Ben,

Thanks for your feedback!

Yes, Form.Validate method actually inhertis from
ContainerControl.Validate() method, which validates the last child control
that is not validated(the control that is losing focus) and its ancestors
up through, but not including, the current container control.

Ok, if you need further help, please feel free to post. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.