validate vs LostFocus events VB 6.0

microsoft.public.vb.general.discussion

27 Dec 2005 9:08 PM

When a control is given a validate event, does the lost focus event still
fire after validation? That is what is happening to me, and I thought if I
set Cancel = true inside the validate sub that the lostFocus event wouldn't
fire. Any Ideas?

wb

27 Dec 2005 11:16 PM

MikeD

"WB" <none> wrote in message news:emET2nyCGHA.1816@TK2MSFTNGP11.phx.gbl...
> When a control is given a validate event, does the lost focus event still
> fire after validation? That is what is happening to me, and I thought if
> I
> set Cancel = true inside the validate sub that the lostFocus event
> wouldn't
> fire.

Your thinking is correct. If Cancel is set to True in the Validate event,
then LostFocus should not fire (control shouldn't lose focus). If Cancel is
not set to True, then LostFocus will fire after the Validate event.

Post the code you're using to test this. My guess is that you're
programmatically setting focus (with SetFocus or Sendkeys tab, for example)
or you're using MsgBox statements (which can interfere with proper firing of
events). Instead of MsgBox statements, use Debug.Print to print to the
Immediate window.

Also, are you sure the Validate event is even firing? Verify the
CausesValidation property is True for all other controls, unless there are
specific controls you don't want getting focus to cause the control about to
lose focus to fire its Validate event. For example, if you have a Cancel
button, you probably wouldn't want to perform validation.

IMO (and I know is one shared by many others), neither LostFocus nor
Validate are good for validating data. Or maybe a more appropriate way of
putting it is that both can be troublesome. Usually, when using LostFocus or
Validate and validation fails, you show a MsgBox. That can be annoying
and/or disruptive (the user might not be looking at the screen, but instead
is reading from some source for the data being entered).

Instead, perform all validation for everything at a single, appropriate
time, for example, perhaps immediately before saving. Say you have a Save
button to do this. Write a ValidateData procedure that you call from
cmdSave_Click. If ValidateData returns False, exit the Click procedure.
This allows you to inform the user of *all* controls that have invalid data
at once AND keeps your code more organized since you've got all the validate
code in one procedure rather than in many (perhaps dozens of) event
procedures. You can do things like change the backcolor of any controls
which contain invalid data so the user can easily see these things need
attention. You might assign a tooltip for the control which explains what's
wrong with the data. You might even have a Label control that provides help
or status information, which you update as controls get focus. There's all
kind of ways you can provide assistance to the user as to what needs fixed
and why that are better than throwing up MsgBoxes.

--
Mike
Microsoft MVP Visual Basic

28 Dec 2005 6:22 PM

Wow, thanks for the great response. Yes, I am using a msgbox when the
validation fails. From there the code seems to jump into the lostFocus
whether I setFocus or not.

I will look into your suggestions. For now, I have removed all the code
from the lost focus event and put it inside the validation event.

WB

Show quoteHide quote

"MikeD" <nob***@nowhere.edu> wrote in message
news:ON6sluzCGHA.3528@TK2MSFTNGP12.phx.gbl...
>
> "WB" <none> wrote in message news:emET2nyCGHA.1816@TK2MSFTNGP11.phx.gbl...
> > When a control is given a validate event, does the lost focus event
still
> > fire after validation? That is what is happening to me, and I thought
if
> > I
> > set Cancel = true inside the validate sub that the lostFocus event
> > wouldn't
> > fire.
>
> Your thinking is correct. If Cancel is set to True in the Validate event,
> then LostFocus should not fire (control shouldn't lose focus). If Cancel
is
> not set to True, then LostFocus will fire after the Validate event.
>
> Post the code you're using to test this. My guess is that you're
> programmatically setting focus (with SetFocus or Sendkeys tab, for
example)
> or you're using MsgBox statements (which can interfere with proper firing
of
> events). Instead of MsgBox statements, use Debug.Print to print to the
> Immediate window.
>
> Also, are you sure the Validate event is even firing? Verify the
> CausesValidation property is True for all other controls, unless there are
> specific controls you don't want getting focus to cause the control about
to
> lose focus to fire its Validate event. For example, if you have a Cancel
> button, you probably wouldn't want to perform validation.
>
> IMO (and I know is one shared by many others), neither LostFocus nor
> Validate are good for validating data. Or maybe a more appropriate way of
> putting it is that both can be troublesome. Usually, when using LostFocus
or
> Validate and validation fails, you show a MsgBox. That can be annoying
> and/or disruptive (the user might not be looking at the screen, but
instead
> is reading from some source for the data being entered).
>
> Instead, perform all validation for everything at a single, appropriate
> time, for example, perhaps immediately before saving. Say you have a Save
> button to do this. Write a ValidateData procedure that you call from
> cmdSave_Click. If ValidateData returns False, exit the Click procedure.
> This allows you to inform the user of *all* controls that have invalid
data
> at once AND keeps your code more organized since you've got all the
validate
> code in one procedure rather than in many (perhaps dozens of) event
> procedures. You can do things like change the backcolor of any controls
> which contain invalid data so the user can easily see these things need
> attention. You might assign a tooltip for the control which explains
what's
> wrong with the data. You might even have a Label control that provides
help
> or status information, which you update as controls get focus. There's all
> kind of ways you can provide assistance to the user as to what needs fixed
> and why that are better than throwing up MsgBoxes.
>
>
> --
> Mike
> Microsoft MVP Visual Basic
>
>
>
>
>

30 Dec 2005 8:14 AM

David J Mark

"WB" <none> wrote in message news:OqZijv9CGHA.740@TK2MSFTNGP12.phx.gbl...
> Wow, thanks for the great response. Yes, I am using a msgbox when the
> validation fails. From there the code seems to jump into the lostFocus
> whether I setFocus or not.

Of course it does. The msgbox steals the focus from the form.

>
> I will look into your suggestions. For now, I have removed all the code
> from the lost focus event and put it inside the validation event.

BTW, the last thing you want to do on losing focus to a dialog control is
pop up a message box. Jarring. Validate on applying the dialog. Nothing
really matters until the user clicks OK or Apply (or switches tabs in a
property sheet.)

Show quoteHide quote

>
> WB
>
> "MikeD" <nob***@nowhere.edu> wrote in message
> news:ON6sluzCGHA.3528@TK2MSFTNGP12.phx.gbl...
>>
>> "WB" <none> wrote in message
>> news:emET2nyCGHA.1816@TK2MSFTNGP11.phx.gbl...
>> > When a control is given a validate event, does the lost focus event
> still
>> > fire after validation? That is what is happening to me, and I thought
> if
>> > I
>> > set Cancel = true inside the validate sub that the lostFocus event
>> > wouldn't
>> > fire.
>>
>> Your thinking is correct. If Cancel is set to True in the Validate
>> event,
>> then LostFocus should not fire (control shouldn't lose focus). If Cancel
> is
>> not set to True, then LostFocus will fire after the Validate event.
>>
>> Post the code you're using to test this. My guess is that you're
>> programmatically setting focus (with SetFocus or Sendkeys tab, for
> example)
>> or you're using MsgBox statements (which can interfere with proper firing
> of
>> events). Instead of MsgBox statements, use Debug.Print to print to the
>> Immediate window.
>>
>> Also, are you sure the Validate event is even firing? Verify the
>> CausesValidation property is True for all other controls, unless there
>> are
>> specific controls you don't want getting focus to cause the control about
> to
>> lose focus to fire its Validate event. For example, if you have a Cancel
>> button, you probably wouldn't want to perform validation.
>>
>> IMO (and I know is one shared by many others), neither LostFocus nor
>> Validate are good for validating data. Or maybe a more appropriate way of
>> putting it is that both can be troublesome. Usually, when using LostFocus
> or
>> Validate and validation fails, you show a MsgBox. That can be annoying
>> and/or disruptive (the user might not be looking at the screen, but
> instead
>> is reading from some source for the data being entered).
>>
>> Instead, perform all validation for everything at a single, appropriate
>> time, for example, perhaps immediately before saving. Say you have a Save
>> button to do this. Write a ValidateData procedure that you call from
>> cmdSave_Click. If ValidateData returns False, exit the Click procedure.
>> This allows you to inform the user of *all* controls that have invalid
> data
>> at once AND keeps your code more organized since you've got all the
> validate
>> code in one procedure rather than in many (perhaps dozens of) event
>> procedures. You can do things like change the backcolor of any controls
>> which contain invalid data so the user can easily see these things need
>> attention. You might assign a tooltip for the control which explains
> what's
>> wrong with the data. You might even have a Label control that provides
> help
>> or status information, which you update as controls get focus. There's
>> all
>> kind of ways you can provide assistance to the user as to what needs
>> fixed
>> and why that are better than throwing up MsgBoxes.
>>
>>
>> --
>> Mike
>> Microsoft MVP Visual Basic
>>
>>
>>
>>
>>
>
>