f



Using LostFocus instead of Valid

Dear Foxers:

     I have used Valid for validation in my app since the beginning. I
would now like to change it over to using LostFocus since I can not
SetFocus when there is a Valid being executed.

     What is a good way of doing this?

     I have come up with something that works, but it is a kludge.


     I can catch the error easily enough, but there is the issue of
how to keep the focus in the control with the error.

     I have a form property (.oErrorCtl) for the last error control.

     .oErrorCtl is initialised to .null. in the form's .init().

     For a given control, if validation succeeds, .oErrorCtl is set to
..null..

     For a given control, if validation fails, .oErrorCtl is set to
this (which is the error control) and the event processing continues
(which gives focus to the next control).  In the .GotFocus() of the
next control, .oErrorCtl is checked if it is not null, the focus gets
sent back with
          thisform.oErrorCtl.SetFocus()


     Is there a better way?

Sincerely,

Gene Wirchenko
0
Gene
1/28/2013 8:28:56 PM
comp.databases.xbase.fox 802 articles. 0 followers. Post Follow

6 Replies
527 Views

Similar Articles

[PageSpeed] 9

Hi Gene,

>       I have used Valid for validation in my app since the beginning. I
> would now like to change it over to using LostFocus since I can not
> SetFocus when there is a Valid being executed.
>
>       What is a good way of doing this?
>
>       I have come up with something that works, but it is a kludge.
>
>
>       I can catch the error easily enough, but there is the issue of
> how to keep the focus in the control with the error.
>
>       I have a form property (.oErrorCtl) for the last error control.
>
>       .oErrorCtl is initialised to .null. in the form's .init().
>
>       For a given control, if validation succeeds, .oErrorCtl is set to
> .null..
>
>       For a given control, if validation fails, .oErrorCtl is set to
> this (which is the error control) and the event processing continues
> (which gives focus to the next control).  In the .GotFocus() of the
> next control, .oErrorCtl is checked if it is not null, the focus gets
> sent back with
>            thisform.oErrorCtl.SetFocus()
>
>
>       Is there a better way?

I think there is.
The valid event processes a return value.
I've used this feature already in Fox/DOS to implement a "geographical" 
navigation in a form, i.e. if the user presse Up, then focus does not go to the 
previous control (which is may be left of the active control) but to the control 
above the active control etc.

a) logical value:
..T. : validation was ok and focus advandes to the next control
This is the normal behaviour if there is no RETURN statement in the valid 
routine, since foxpro returns .T. from any function without return statement.
..F.: validation was not ok, focus stays in this control and an error message 
appears (this at least was the case in old fox dos)

b) numerical value:
If it is 0, then focus stays in the control. Nothing else (like error message) 
happens-
If it is a positive number, focus advances this number of controls in activation 
order.
If it is a negative number, focus goes back this number of controls.
When the absolute value of the number is larger than there are controls, then 
focus advandes to the first respectively last control in activation order (or 
maybe an error occurs, I don't remember exactly)

c) object name
simply the name of an object, not a string!
If that control exists, focus goes to that control.

Have a look at "Valid event" and "Return" in the help file.
Just have a try since the explanation in the help is quite poor.

Regards

Bernhard Sander
0
Bernhard
1/29/2013 12:59:55 PM
Gene Wirchenko expressed precisely :
> Dear Foxers:
>
>      I have used Valid for validation in my app since the beginning. I
> would now like to change it over to using LostFocus since I can not
> SetFocus when there is a Valid being executed.
>

I think this is wrong-headed. It isn't one or the other.

In the old days, we used Valid for *both* validation and navigation 
because it's the only thing we had.

Now they're separate acts that mean different things. Valid determines 
whether or not focus is allowed to leave the current control. Lostfocus 
happens after focus has left the control, implying that validation has 
been satisfied, and allows you to interfere in normal tab order.

If you need your validation to move focus to (for example) the previous 
control, then RETURN -1 in the Valid method, but it's still an act of 
validation.

They're really very different conditions and using one for the other's 
purpose seems like you're swimming against the tide. You wouldn't use 
Click() to handle a Keypress().

Dan


0
Dan
1/29/2013 6:11:56 PM
On Tue, 29 Jan 2013 13:59:55 +0100, Bernhard Sander <fuchs@kein.spam>
wrote:

[snip]

>Have a look at "Valid event" and "Return" in the help file.
>Just have a try since the explanation in the help is quite poor.

     I know how Valid works.  I have been using it for over a decade.

     The problem is that you can not have more than one Valid method
in the execution chain.  That is why some moved to using LostFocus.  I
have nested forms sometimes and would like to have validation on the
nested form.

Sincerely,

Gene Wirchenko


>
>Regards
>
>Bernhard Sander
0
Gene
1/29/2013 6:30:33 PM
On Tue, 29 Jan 2013 10:11:56 -0800, Dan Freeman <dan@dfapam.com>
wrote:

[snip]

>They're really very different conditions and using one for the other's 
>purpose seems like you're swimming against the tide. You wouldn't use 
>Click() to handle a Keypress().

     It is a limitation of VFP that one can not have a second Valid
being executed while there is another in the call chain.  I sometimes
have a Valid being executed and would then like to have validation on
a nested form.  I can not do that using Valid.  With LostFocus, it is
apparently possible.  I want that flexibility.  My app would be more
user-friendly.

Sincerely,

Gene Wirchenko
0
Gene
1/29/2013 11:07:57 PM
Gene Wirchenko laid this down on his screen :
> On Tue, 29 Jan 2013 10:11:56 -0800, Dan Freeman <dan@dfapam.com>
> wrote:
>
> [snip]
>
>> They're really very different conditions and using one for the other's 
>> purpose seems like you're swimming against the tide. You wouldn't use 
>> Click() to handle a Keypress().
>
>      It is a limitation of VFP that one can not have a second Valid
> being executed while there is another in the call chain.  I sometimes
> have a Valid being executed and would then like to have validation on
> a nested form.  I can not do that using Valid.  With LostFocus, it is
> apparently possible.  I want that flexibility.  My app would be more
> user-friendly.

Seems like you're playing convenient semantics games.

In the VFP object model, valid must return before focus can leave a 
control. You want to use another control in another VFP container to do 
something you're calling validation, and that's fine, but it isn't what 
VFP calls validation.

In that case, your previously described observer pattern is appropriate 
but all behaviors rightly belong in the observer and not in the object 
being observed.

When bypassing VFP's normal tab order processing there won't be any 
convenient way to taking advantage of the tab order processing that 
you're intentionally bypassing. Full kludge ahead!

Dan


0
Dan
1/30/2013 5:50:43 AM
On Tue, 29 Jan 2013 21:50:43 -0800, Dan Freeman <dan@dfapam.com>
wrote:

>Gene Wirchenko laid this down on his screen :
>> On Tue, 29 Jan 2013 10:11:56 -0800, Dan Freeman <dan@dfapam.com>
>> wrote:
>>
>> [snip]
>>
>>> They're really very different conditions and using one for the other's 
>>> purpose seems like you're swimming against the tide. You wouldn't use 
>>> Click() to handle a Keypress().
>>
>>      It is a limitation of VFP that one can not have a second Valid
>> being executed while there is another in the call chain.  I sometimes
>> have a Valid being executed and would then like to have validation on
>> a nested form.  I can not do that using Valid.  With LostFocus, it is
>> apparently possible.  I want that flexibility.  My app would be more
>> user-friendly.
>
>Seems like you're playing convenient semantics games.

     I have no idea what you are talking about.

>In the VFP object model, valid must return before focus can leave a 
>control. You want to use another control in another VFP container to do 
>something you're calling validation, and that's fine, but it isn't what 
>VFP calls validation.

     No.  As I stated, the validation is done in the same control's
LostFocus.  It is only the SetFocus that is elsewhere.

>In that case, your previously described observer pattern is appropriate 
>but all behaviors rightly belong in the observer and not in the object 
>being observed.
>
>When bypassing VFP's normal tab order processing there won't be any 
>convenient way to taking advantage of the tab order processing that 
>you're intentionally bypassing. Full kludge ahead!

     Someone else, on ProFox, was nice enough to point out that I
should use nodefault in the LostFocus to cancel the focus change. That
works nicely.

Sincerely,

Gene Wirchenko
0
Gene
1/30/2013 8:19:40 PM
Reply: