info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Using LostFocus instead of Valid
8 views
Skip to first unread message
Gene Wirchenko
Jan 28, 2013, 3:28:56 PM1/28/13
to
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
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
Bernhard Sander
Jan 29, 2013, 7:59:55 AM1/29/13
to
Hi Gene,
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
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
Dan Freeman
Jan 29, 2013, 1:11:56 PM1/29/13
to
Gene Wirchenko expressed precisely :
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
> 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.
>
> 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.
>
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
Gene Wirchenko
Jan 29, 2013, 1:30:33 PM1/29/13
to
On Tue, 29 Jan 2013 13:59:55 +0100, Bernhard Sander <fu...@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
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.
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
Gene Wirchenko
Jan 29, 2013, 6:07:57 PM1/29/13
to
On Tue, 29 Jan 2013 10:11:56 -0800, Dan Freeman <d...@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
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().
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
Dan Freeman
Jan 30, 2013, 12:50:43 AM1/30/13
to
Gene Wirchenko laid this down on his screen :
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
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
Gene Wirchenko
Jan 30, 2013, 3:19:40 PM1/30/13
to
On Tue, 29 Jan 2013 21:50:43 -0800, Dan Freeman <d...@dfapam.com>
>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
wrote:
>Gene Wirchenko laid this down on his screen :
>> On Tue, 29 Jan 2013 10:11:56 -0800, Dan Freeman <d...@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.
>Gene Wirchenko laid this down on his screen :
>> On Tue, 29 Jan 2013 10:11:56 -0800, Dan Freeman <d...@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.
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!
should use nodefault in the LostFocus to cancel the focus change. That
works nicely.
Sincerely,
Gene Wirchenko
0 new messages