old annoying bug or a feature?

Hi,

In order to validate user's imput, I place in Valid Event
of Textbox some code, wich calls a form for data lookup or
entering new data in related tables. Depending on lookup
results, the focus stays in the Texbox or jumps to other
controls with a help of RETURN n command. This seems to be
very clear and convenient, but...

If in some other form, launched from Valid Event, there is
a SetFocus Method - the error comes: SetFocus method can
not be called within Valid Event.

But SetFocus is called in other form! And what more, in a
way can be several more form calls that has nothind to do
with the first one, but the error comes nevertheless :(

I wonder, if MS will ever fix this annoyance or it is
treated like a feature?

Vitas

Anders
Fri Nov 28 08:50:13 CST 2003

It's treated like an immutable fact of life. Set a flag in Valid and let
LostFocus handle it when the flag is up.
-Anders


"Vitas V" <vitvas@delfi.lt> wrote in message
news:088001c3b5a6$3aea5460$a301280a@phx.gbl...
> Hi,
>
> In order to validate user's imput, I place in Valid Event
> of Textbox some code, wich calls a form for data lookup or
> entering new data in related tables. Depending on lookup
> results, the focus stays in the Texbox or jumps to other
> controls with a help of RETURN n command. This seems to be
> very clear and convenient, but...
>
> If in some other form, launched from Valid Event, there is
> a SetFocus Method - the error comes: SetFocus method can
> not be called within Valid Event.
>
> But SetFocus is called in other form! And what more, in a
> way can be several more form calls that has nothind to do
> with the first one, but the error comes nevertheless :(
>
> I wonder, if MS will ever fix this annoyance or it is
> treated like a feature?
>
> Vitas

Igor
Sat Nov 29 16:28:09 CST 2003

Hi, Anders!
You wrote on Fri, 28 Nov 2003 15:50:13 +0100:

AA> It's treated like an immutable fact of life. Set a flag in Valid and
AA> let LostFocus handle it when the flag is up.

Or just move all the validation code to LostFocus and replace RETURN
0/RETURN .F. with NODEFAULT - effect will be the same - focus will stay in
this control.

--
WBR, Igor

Anders
Sun Nov 30 05:42:50 CST 2003

Hi
Igor
That's definitely possible but I don't know of possible side-effects. One
can also just remove any SetFocus calls in the stack and use a KEYBOARD
REPLICATE('{TAB}', n) or RETURN n.
-Anders

"Igor Korolyov" <k1i2v3@km.ru> wrote in message
news:Oj8zU1wtDHA.3436@tk2msftngp13.phx.gbl...
> Hi, Anders!
> You wrote on Fri, 28 Nov 2003 15:50:13 +0100:
>
> AA> It's treated like an immutable fact of life. Set a flag in Valid and
> AA> let LostFocus handle it when the flag is up.
>
> Or just move all the validation code to LostFocus and replace RETURN
> 0/RETURN .F. with NODEFAULT - effect will be the same - focus will stay in
> this control.
>
> --
> WBR, Igor
>
>

vitvas
Sun Nov 30 06:46:08 CST 2003

Hi,

it works but not always. When you call other Form from LostFocus (e.g
for Lookup), and validate depending on results to let the focus go or
stay in control - NODEFAULT have no effect.

Also it is rather difficult to create a generic Validation class based
on LostFocus Event, where the cursor depending on results should stay
in control or go to next or secont to next or previous Control in Tab.
In Valid Event you can do it quite easy and elegant with RETURN n.

Vitas

"Igor Korolyov" <k1i2v3@km.ru> wrote in message news:<Oj8zU1wtDHA.3436@tk2msftngp13.phx.gbl>...
....
>
> Or just move all the validation code to LostFocus and replace RETURN
> 0/RETURN .F. with NODEFAULT - effect will be the same - focus will stay in
> this control.

Igor
Mon Dec 01 10:41:06 CST 2003

Hi, Vitas!
You wrote on 30 Nov 2003 04:46:08 -0800:

VV> it works but not always. When you call other Form from LostFocus (e.g
VV> for Lookup), and validate depending on results to let the focus go or
VV> stay in control - NODEFAULT have no effect.

Don't have any problems with this scenario! I call other form, and then,
depending of what user select there (or not select by pressing Cancel
button) I can stay in this control. I don't see one case, when NODEFAULT
won't work...

VV> Also it is rather difficult to create a generic Validation class based
VV> on LostFocus Event,

Hmm, don't see any problems here. BTW I have my validation code in my
textbox class, and it IS as generic, as it can - all info is placed in my
properties... I use a sotr of validation to check if some entered value
(either some object "code" or "naim") exist in reference table most of the
cases, but don't think there will be any problems with other types of
validation...

VV> where the cursor depending on results should stay in control or go to
VV> next or secont to next or previous Control in Tab. In Valid Event you
VV> can do it quite easy and elegant with RETURN n.

Yes it is handy to use RETURN 0 to stay and RETURN 3 to move to the 3-d
control after current, BUT if it is impossible to use SetFocus (in other
forms!!! But called by this validation code) - then I'll prefer to stay with
my LostFocus :)

--
WBR, Igor

Igor
Mon Dec 01 10:48:14 CST 2003

Hi, Anders!
You wrote on Sun, 30 Nov 2003 12:42:50 +0100:

AA> That's definitely possible but I don't know of possible side-effects.

I don't see one :)

AA> One can also just remove any SetFocus calls in the stack and use a
AA> KEYBOARD REPLICATE('{TAB}', n) or RETURN n.

To move to another control on the same form!
BUT the problem is, that you call some other form from your Valid event
code - and in that "other" form you may have SetFocus()!!! Don't you want to
tell me not to use SetFocus() at all? In any form, because this form may be
called from some other control's Valid event...

--
WBR, Igor