Bypassing Lostfocus

[AndrewMozley]

Feel that this has been asked before, but I don't have a complete solution.

I have a textbox, MyText on form Form1 with a Lostfocus() method which checks to see whether it likes Mytext.value. If it does not, it retains control. However there are circumstances in which I do not want this check to be run, for example if the user clicks on my "Close" button.

To cope with that, I have a flag "Fire_Lostfocus", normally set to .T. Then in the Close.MouseEnter() method I set that flag to .F., and on Close.MouseLeave() I set that to .T.

And this allows me to bypass the code in Textbox.LostFocus.

However there are other cfircumstances in which I also want to allow control to move away from Mytext, without complaint. If for example I have another form, Form2 on the screen at the same time, I want to allow the user to click on Form2, without getting a complaint from Form1.Mytext.Lostfocus().

Grateful for ideas. Andrew

 

[mplaza]

Casually this was discussed in foxite yesterday:

Check one solution:

http://www.foxite.com/archives/0000418644.htm

another way is using unobtrusive form validation - I posted an example here in the same thread:

http://www.foxite.com/archives/0000418787.htm

Marco

 

[Olaf Doschke]

A very common solution is to never disallow cancelling, by checking IF LASTKEY()=27 and in that case don't validate.
Or skip single control validation all over and have a central validation routine.

In case of cancel you should go to a valid state of a record with TABLEREVERT() anyway, but the has buffering as prerequisite and that topic is a little bigger. Anyway, making use of LASTKEY() in valid will allow you to lose focus and you can decide whether to save and what to do with invalid input later on, anyway.

Bye, Olaf.

 

[Mike Lewis]

Actually, Andrew, your predicament is the very reason I tend not to do validation in the LostFocus (or, more appropriately, in the Valid). I do all the validation in a single method (typically called ValidateForm), which I call in the Save button, before committing the data. That way, you don't risk the user getting trapped inside an edit box, and you can deal with the situation where the valid value of one controls depends on the value of another.

By the way, you mentioned that you don't want the LostFocus code to run when the user hits your Close button. Did you know that, if the Close button is on a toolbar, the LostFocus will never run (because toolbar controls never get focus, and the form controls therefore don't lose focus)? You might be able to take advantage of that fact, although it's very much a mixed blessing.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[craigber]

There's a reason a textbox has a Valid event. This is where validation belongs. Simply return .T. to allow the control to lose focus or .F. to remain in the control.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

There's a reason a textbox has a Valid event. This is where validation belongs. Simply return .T. to allow the control to lose focus or .F. to remain in the control.

I agree entirely, Craig, but it doesn't answer Andrew's question. He still needs a way of knowing which control the user is trying to pass focus to, so that he can know whether or not to do the validation. That problem remains the same, regardless of whether he using the Valid or the LostFocus.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Thank you to all those members who made constructive suggestions. To recap, I want to bypass the validation and allow exit from a textbox if the user either clicks on the ‘Close button’ of the form or if he clicks on another menu or different form within the application.

The SYS(1270) - thank you mPlaza - seems very useful. As mentioned I unset and set a Fire_Lostfocus property when the mouse enters and leaves the Close button The code in my Lostfocus() method (could be the Valid() method) now contains.

   *  If he has clicked the 'Close' button, or another form may get focus,
   *  we don't wish to validate this control
   IF !Fire_Lostfocus
      RETURN .T.
      ENDIF

   LOCAL oWhere
   oWhere = SYS(1270)
   IF TYPE("oWhere") <> "O" .OR. TYPE("owhere.parent") = "U" .OR. ;
         owhere.parent.name <> this.Parent.name
      RETURN .T.
      ENDIF
   *  Continue with the normal validation.

This seems to achieve the result – but no doubt it could be improved.

Andrew

 

[Dan Freeman]

The code in my Lostfocus() method (could be the Valid() method)

I could (but won't) argue that it SHOULD (not could) be in Valid().

Valid() and LostFocus() are not interchangeable. Valid() determines whether or not focus is allowed to leave the current control. LostFocus() fires when focus has already left the current control. Those are two very different conditions.

Misusing methods can result in some massive workarounds down the line where you'd have smooth sailing if you'd put the code in the right method in the first place. Work WITH the Fox, not against it.