Author |
Message |
Rockfrdc #1 / 17
|
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 |
|
|
Frank Ad #2 / 17
|
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 |
|
|
Rockfrdc #3 / 17
|
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 |
|
|
Rob Strove #4 / 17
|
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 |
|
|
Dag Sund #5 / 17
|
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 |
|
|
Rob Strove #6 / 17
|
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 |
|
|
Dag Sund #7 / 17
|
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 |
|
|
J Fren #8 / 17
|
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 |
|
|
Frank Ad #9 / 17
|
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 |
|
|
Dag Sund #10 / 17
|
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 |
|
|
J Fren #11 / 17
|
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 |
|
|
Rob Strove #12 / 17
|
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 |
|
|
J Fren #13 / 17
|
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 |
|
|
Rob Strove #14 / 17
|
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 |
|
|
John Clevelan #15 / 17
|
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 |
|
|