At 00:05 2013-01-31, Jean MAURICE <[email protected]> wrote:
it's the way it works : you can not 'interrupt' the execution of a
method or event. When you execute CLEAR EVENTS, the 'event' is just
added at the top of
Of course you can. A return statement does that. The way that
clear events is documented, it supposedly works the same way but
return to after the read events statement ...
the event stack ... and unstacked at the end of the current method ....
... but as I have found, it works as you stated.
You have a 'if' to test if the app must end, put the rest of the
method in the 'else' ... Hope I am clear.
Now instaed of SYS(1270), can try just to write :
thisform.object_name (ie Thisfom.btnquit). I think it will work. If
yes, it shows that the gotfocus() of the next object is fired before
the lostfocus of the current object ...
Going your way, I wonder if I can put a check in the next
object, say an Exit button, to bypass the validation somehow. Set a
form-level property on whether to do validations to false in GotFocus
or When and check the property before each validation. This seems
messier than what I have worked out.
With my solution, the mess is in the data entry objects'
LostFocus and serves the purpose of bypassing the validation. I much
prefer to have the handling all in one place.
Sincerely,
Gene Wirchenko
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/20130131172334.GDRM1732.priv-edtnes25.telusplanet.net@edtncm02
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
