checking for click event during lost focus event 
Author Message
 checking for click event during lost focus event
Hi
Would anyone know how to check to see if the exit button was clicked during the
execution of the lost focus event.  On a particular button, I only want the
routine in lost focus to happen if it wasn't the exit button that made it loose
the focus.  But I am not sure what If statement should surround the routine.
Thanks if you can help!



Sat, 06 Aug 2005 04:32:58 GMT  
 checking for click event during lost focus event

Quote:
>Hi
>Would anyone know how to check to see if the exit button was clicked during the
>execution of the lost focus event.  On a particular button, I only want the
>routine in lost focus to happen if it wasn't the exit button that made it loose
>the focus.  But I am not sure what If statement should surround the routine.
>Thanks if you can help!

Sounds like a weird way of going about it.  The QueryUnload event was
invented for this sort of a thing. It fires as your form is about to
close.

--

Regards, Frank



Sat, 06 Aug 2005 05:08:19 GMT  
 checking for click event during lost focus event
Hi
I guess I should have explained my purpose better. The form has not closed yet.
 I am checking the validity of a text box entry using lost focus.  But when
clicking the exit button, I don't want it to check the text box entry even
though the text box loses focus in that case too.

Paul



Sat, 06 Aug 2005 20:51:18 GMT  
 checking for click event during lost focus event
Paul,

If, on this form, you have more than one control where you need to check the
validity of the contents then I'd suggest that you use the opportunity of
the exit button click to check the validity of all inputs, by themselves
*and* in relationship to each other.  I have found the use of the lostfocus
event a not totally reliable mechanism for validity checking.

        Rob.


Quote:
> Hi
> I guess I should have explained my purpose better. The form has not closed
yet.
>  I am checking the validity of a text box entry using lost focus.  But
when
> clicking the exit button, I don't want it to check the text box entry even
> though the text box loses focus in that case too.

> Paul



Sat, 06 Aug 2005 21:11:57 GMT  
 checking for click event during lost focus event


Quote:
> Paul,

> If, on this form, you have more than one control where you need to check
the
> validity of the contents then I'd suggest that you use the opportunity of
> the exit button click to check the validity of all inputs, by themselves
> *and* in relationship to each other.  I have found the use of the
lostfocus
> event a not totally reliable mechanism for validity checking.

So realized Microsoft!

Thats why they added the "Validate(...)" event to input controls.

LostFocus isn't supposed to be used for that kind og data-
validation.

--
Dag.

Quote:



> > Hi
> > I guess I should have explained my purpose better. The form has not
closed
> yet.
> >  I am checking the validity of a text box entry using lost focus.  But
> when
> > clicking the exit button, I don't want it to check the text box entry
even
> > though the text box loses focus in that case too.

> > Paul



Sat, 06 Aug 2005 21:35:16 GMT  
 checking for click event during lost focus event
Dag,

The 'Validate' event was certainly a significant addition to VB 6 -
unfortunately I'm still using VB 5 here :-(

It's not often that I find something that makes me think I should have
upgraded to VB 6 before it was too late(would have , but was short of cash
at the time, and now I'm not sure I care enough to bother).

Still, generally the 'validate on exit from form' method works, even if it's
a bit clumsy at times!

Quote:
> LostFocus isn't supposed to be used for that kind og data-
> validation.

^

Must be some piece of that strange northern language of yours     ;-b

Rob.


Quote:



> > Paul,

> > If, on this form, you have more than one control where you need to check
> the
> > validity of the contents then I'd suggest that you use the opportunity
of
> > the exit button click to check the validity of all inputs, by themselves
> > *and* in relationship to each other.  I have found the use of the
> lostfocus
> > event a not totally reliable mechanism for validity checking.

> So realized Microsoft!

> Thats why they added the "Validate(...)" event to input controls.

> LostFocus isn't supposed to be used for that kind og data-
> validation.

> --
> Dag.



> > > Hi
> > > I guess I should have explained my purpose better. The form has not
> closed
> > yet.
> > >  I am checking the validity of a text box entry using lost focus.  But
> > when
> > > clicking the exit button, I don't want it to check the text box entry
> even
> > > though the text box loses focus in that case too.

> > > Paul



Sat, 06 Aug 2005 22:20:35 GMT  
 checking for click event during lost focus event


Quote:
> Dag,

> The 'Validate' event was certainly a significant addition to VB 6 -
> unfortunately I'm still using VB 5 here :-(

Sorry!

Didn't realize you vere using VB 5... :-\

--
Dag.



Sat, 06 Aug 2005 23:00:13 GMT  
 checking for click event during lost focus event
<snip>

It sounds a bit a**e about face, but under VB5 field validation is
generally best done in the GotFocus event.



Sun, 07 Aug 2005 01:02:58 GMT  
 checking for click event during lost focus event

Quote:

>So realized Microsoft!

>Thats why they added the "Validate(...)" event to input controls.

I hate that thing myself, but each to his own.

Quote:
>LostFocus isn't supposed to be used for that kind og data-
>validation.

He would have the same problem with the Validate event. It's basically
the same thing as a LostFocus except it  fires before the lostfocus.
Since he wants to NOT validate if the user is going for the exit
button, this is even less suitable for his requirements as lostfocus
is.

Checking MouseDown on the exit button and throwing a flag should do
the trick, while using LostFocus. Then that flag is checked in the
LostFocus of the textbox and if set don't do the validate.
Remember how all the events work when gaining focus to another
control( in this case from a textbox to  the 'exit' command button ).

validate ' on textbox (useless, am i about to click on exit ??)
mousedown ' on commandbutton (here i'm pretty sure i will)
lostfocus ' on textbox (by this time the flag is either set or not)
gotfocus ' on command
mouseup ' on command (execute click..see below)

As an added measure...
After a mousedown the user may move off the button before letting the
muousebutton up, having changed his mind.
So the exit code that the button performs should be in Mouse_Up
instead of Click. and the X and Y parameters checked against  > 0 and
< width and heigth respectively. If they are not within the command
button's span, then exit the code and/or call the lostfocus event of
the textbox explicitly. This should work just fine i think.

With all that said, i still think it's much better to have a submit
button and do the validation of all controls on that event.

--

Regards, Frank



Sun, 07 Aug 2005 02:02:26 GMT  
 checking for click event during lost focus event

Quote:

> >So realized Microsoft!

> >Thats why they added the "Validate(...)" event to input controls.

> I hate that thing myself, but each to his own.

> >LostFocus isn't supposed to be used for that kind og data-
> >validation.

> He would have the same problem with the Validate event. It's basically
> the same thing as a LostFocus except it  fires before the lostfocus.
> Since he wants to NOT validate if the user is going for the exit
> button, this is even less suitable for his requirements as lostfocus
> is.

Actually not, Frank!

Because you set: "cmdExit.CausesValidation = False"

...And you get *exactly the behaviour the OP wanted.
That's why the Validate-event is more flexible to use.

You can select which controls that *don't* trigger
validation events...

--
Dag.



Sun, 07 Aug 2005 16:11:20 GMT  
 checking for click event during lost focus event


<snip>

Quote:
>With all that said, i still think it's much better to have a submit
>button and do the validation of all controls on that event.

That can be a bit painful for the user ...

I find that validating the last field in the GotFocus event of
controls generally does the trick

Another method is simulate all controls so there is effectively no
LostFocus event ...



Sun, 07 Aug 2005 17:17:07 GMT  
 checking for click event during lost focus event
Jerry,

I'm not sure in this context what you mean by simulate - could you please
explain.

Thanks,

        Rob.


Quote:


> <snip>
> >With all that said, i still think it's much better to have a submit
> >button and do the validation of all controls on that event.

> That can be a bit painful for the user ...

> I find that validating the last field in the GotFocus event of
> controls generally does the trick

> Another method is simulate all controls so there is effectively no
> LostFocus event ...



Sun, 07 Aug 2005 18:49:24 GMT  
 checking for click event during lost focus event
On Wed, 19 Feb 2003 10:49:24 GMT, "Rob Strover"

Quote:

>Jerry,

>I'm not sure in this context what you mean by simulate - could you please
>explain.

>Thanks,

Sure,

One method is to have a load of Labels instead of Textboxes, and just
one Textbox that you move around the screen

Labels have a Click event - but cannot take Focus

Another is to paint directly on the face of the Form, using PSet, Line
etc - or one of the convenient APIs like DrawEdge that Windows uses
itself for drawing components
I've created whole screens of 'buttons' like that
- in fact a fairly hefty App with effectively no controls whatsoever

None of this is really 'the Windows way'
- but who cares ...

Generally I tend to use the GotFocus event of controls to validate the
input from the prior control
- and for ill-behaved things like CommandButtons I tend to 'roll my
own' from a UserControl

However part (but not all) of the reason for this is because I use VB5
(for commercial reasons - and sheer cussedness) and that does not have
the Validate Event

Also I hate distributing OCXes - so when I need something like a
TabStrip - I simply make my own

www.iss.u-net.com/eTabSim.htm    is a good example

The thing is that Windows itself is really a 'simulation', it is just
a chunk of screen on which pretty illustrations are painted, and the
'core' intercepts all mouse clicks and decides which 'control' the
event should be sent to.

Often it is simply easier to create one's own 'things', as they behave
exactly as you want them to
- rather than working round the bizarre behaviour of MS things

Anyway I'm rambling ...



Sun, 07 Aug 2005 20:00:34 GMT  
 checking for click event during lost focus event
Jerry,

Thanks for the explanation.

It sounds like what a couple of people here did with VB 1 & 2 before the 3-D
controls were available.  Also I did a little of the painting type approach
with VB 3, but I got most of that code from one of my colleagues, who was a
MS Basic expert for some years before VB arrived.  I guess most of us got
lazier in that regard when Microsoft provided reliable 3-D controls (ie. not
related to threed.vbx/ocx).

        Rob.


Quote:
> On Wed, 19 Feb 2003 10:49:24 GMT, "Rob Strover"

> >Jerry,

> >I'm not sure in this context what you mean by simulate - could you please
> >explain.

> >Thanks,

> Sure,

> One method is to have a load of Labels instead of Textboxes, and just
> one Textbox that you move around the screen

> Labels have a Click event - but cannot take Focus

> Another is to paint directly on the face of the Form, using PSet, Line
> etc - or one of the convenient APIs like DrawEdge that Windows uses
> itself for drawing components
> I've created whole screens of 'buttons' like that
> - in fact a fairly hefty App with effectively no controls whatsoever

> None of this is really 'the Windows way'
> - but who cares ...

> Generally I tend to use the GotFocus event of controls to validate the
> input from the prior control
> - and for ill-behaved things like CommandButtons I tend to 'roll my
> own' from a UserControl

> However part (but not all) of the reason for this is because I use VB5
> (for commercial reasons - and sheer cussedness) and that does not have
> the Validate Event

> Also I hate distributing OCXes - so when I need something like a
> TabStrip - I simply make my own

> www.iss.u-net.com/eTabSim.htm    is a good example

> The thing is that Windows itself is really a 'simulation', it is just
> a chunk of screen on which pretty illustrations are painted, and the
> 'core' intercepts all mouse clicks and decides which 'control' the
> event should be sent to.

> Often it is simply easier to create one's own 'things', as they behave
> exactly as you want them to
> - rather than working round the bizarre behaviour of MS things

> Anyway I'm rambling ...



Sun, 07 Aug 2005 21:09:19 GMT  
 checking for click event during lost focus event

: Paul,
:
: If, on this form, you have more than one control where you need to
check the
: validity of the contents then I'd suggest that you use the opportunity
of
: the exit button click to check the validity of all inputs, by
themselves
: *and* in relationship to each other.  I have found the use of the
lostfocus
: event a not totally reliable mechanism for validity checking.
:
:         Rob.

I use VB6 and this seems to work:

Private Sub Text1_LostFocus()
   If Screen.ActiveControl.Name = "Command1" Then Exit Sub
   'LostFocus code
   '
   '
End Sub

I don't have VB5 so I don't know if the sequence in which the events
occur would allow this to work.  In VB6, I believe the exit button
becomes the ActiveControl before the LostFocus event fires in the
textbox. I almost always use the method of validating in the exit
button, as you suggest, so I don't really know if there are drawbacks to
the method of testing the ActiveControl in the LostFocus event.  Am I
missing something?

:

: > Hi
: > I guess I should have explained my purpose better. The form has not
closed
: yet.
: >  I am checking the validity of a text box entry using lost focus.
But
: when
: > clicking the exit button, I don't want it to check the text box
entry even
: > though the text box loses focus in that case too.
: >
: > Paul
:
:



Mon, 08 Aug 2005 01:06:19 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Form close event occurs before lost focus event

2. lost focus and got focus event

3. CommandBarComboBox Change event (content not saved when losing focus)

4. Lost focus event combo box

5. lost focus event occurs when user selects menu option

6. Force lost focus event to text box

7. Help! Getting Extra Lost Focus() events

8. Lost Focus Event (HELP!)

9. MDI child forms and control lost-focus events

10. lost focus event problem when using access keys

11. Lost Focus Event

12. No lost focus event

 

 
Powered by phpBB® Forum Software