Entry

Why should I use the new 'Validate' event of VB6 controls instead of the 'LostFocus' event or is there another way?

May 16th, 2002 08:53
Jason Stracner,

*Shortcut problems*
When a textbox has the focus and the user presses a keyboard
combination that will trigger a command button's click
event to fire.  For example if the caption was 
"&Click here" then the keyboard shortcut 'Alt+C' would 
fire the click event.  The events will fire in this strange
and likely unexpected order:
   1. Text1_Validate
   2. Command1_Click
   3. Text1_LostFocus
  *The 'DoEvents' workaround*
If you place the vb command "DoEvents" as the first line of
the command button's click event or the user simply clicks
on the command button with out the "DoEvents" present then 
the events will fire in the expected order:
   1. Text1_Validate
   2. Text1_LostFocus
   3. Command1_Click
  *Problems with LostFocus and MsgBox*
However if the Validate event of the textbox produces a
message box using the "MsgBox" command or the command
button's click event produces a message box and there
is no "DoEvent" command present in the first line of the 
command button's click event then the "LostFocus" event 
will NOT be fired at all.
  *Why Validate is better*
Notice that the "Validate" event will almost always run
before any other events are processed.  If you want to 
protect your data and ensure that certain validation 
rules are applied to a piece of text contained in a textbox
you might not want to rely on the textbox's "LostFocus"
event.  I recommend the "Validate" event be used in it's 
place.
  *Validate is better but not the best - try "Change"*
There is one big problem with using the "Validate" event,
and for that matter the "LostFocus" event, to ensure that
the data in a textbox has truly been validated.  The problem
lies in the situation where a command button's "Default"
property has been set to 'true'.  If this is the case and
the textbox has the focus and the user presses the "Enter"
key then neither the "Validate" or "LostFocus" events are
fired.  Similarly, the "Cancel" property of a command button
works in the same way but for the "Esc" key.  For these
situations you have three options to truly ensure valid
data has been entered.  The first two are to either make 
sure that you never use these properties - or work out some 
code that will test the text that is in the textbox after 
every change.  You could use either the "Change" or 
"KeyPress" events to do this testing.  Testing this way is 
quite different from using the "Validate" or "LostFocus" 
and can be quite complex.  The last and maybe the best 
alternative might be to force the validation events for 
all textboxes to run at the beginning of the click event 
of the command button that has been marked as "Default".
  *Conclusion*
I recommend avoiding the "LostFocus" event and using the
"Validate" event whenever possible and making sure you
force one last validation on any command button marked
as "Default".  You can do this by calling all the textboxes 
"Validation" events directly 
(e.g.: 
Text1_Validate True
Text2_Validate True
Text3_Validate True
) before possessing the click event for the any command 
button marked as "Default".