Re: Why the delay to close()...? -
03-07-2008
, 08:24 AM
For Lurkers :
There are some BIG caveats when using sleep. As everyone who has used
the web.ocx has learned sleep not only yields to Windows but also to
Paradox itself. When using sleep other paradox events/code can start in
the middle of your running code. This includes user actions such as
clicking a button.
This usually is not an issue but if you are working with tcursors or
setting application global variables you may find the tcursors are
locked or changed or perhaps your system settings have been affected
(for instance: ignorecaseinstringcompares).
Events firing in the midst of your code is more prominent when your code
is running from libraries or other forms. Generally I have seen that
paradox acts more like a multithreaded program when to different forms
or libraries interact with one another. You can use this for your
advantage. For instance if you want to create a pause button for a long
process, placing a Pause button on the same form will not work (not
consistently anyway) but, opening another form with the pause button on
it will.
While I'm on this pedantic lecture.....
Related to this is things I have learned recently about
delayscreenupdates(Yes|No). Delaying screen updates not only delays the
screen display, it actually delays the events that would occur with the
screen changes. So things like newvalue are actually delayed. Let's
say your user has several forms open relating to a company address. One
or two of those forms is using the newvalue event to kick off some
program logic in a library somewhere. Now you have other code working
with a tcursor on the address table and you make changes and post a
record in a scan. If delayscreenupdates is not on then the code fired
by the newvalue event on the form may fire and could conceivably change
some record in the tcursor you are scanning. Or perhaps more
insidiously change something like ignorecaseinlocate or blankAsZero in
the middle of your code.
So the lesson is, if you use sleep() be aware that it may cause odd and
very hard to reproduce problems (as they could be dependent on a
combination of forms being open).
Lesson two: I would suggest *always* turning on delayscreenupdates
during code execution. It makes code run much faster and predictably if
there are forms open.
--
Mark B |