DataEase for Windows use POST to launch functions. For those of you that doesn't know the difference between POST and SEND in Windows I will offer a simple explanation.

POST means fire and forget and leave it all to windows.
SEND means - "Hello man, I want a signature for that!" i.e. hand shake or more like hand holding ;-)

The benefit of POST is that things will not "hang" around and wait for things which is kind of important in a event driven Operating System, the drawback being that you can't control the firing order of things which has been a "head ache" fo DFW developers "forever".

Add to the headache that DataEase code is not re-entrant, and you know that you are in at the deep end. 

Plenty of GPF's is caused by you calling a function that use the same registers or memory as another, before the first one has finished. You see, DFW was never really designed for this level of multitasking and speed.

Wait() turned out to be quite different than we "intended". It was designed to wait a certain time before executing the next function, but as it turns out it ended up a little flip-sided.

Based on what kind of function you call, wait 10 seconds may make a big difference (creating a PDF for instance that is done by a third party product) but if you call a function in DataEase waiting 0.1 seconds might make the same difference ;-)

You see, the added and unexpected effect of the wait() function is in the design of the function itself. When you call it, it will only start waiting when the function in front of it is finished, so waiting a long time is no point it is the call of the wait() function itself that is the clue.

Another "design flaw" is that it can't wait less than 1 second so Wait(0.1) will in reality means instant so what does it end up doing?

STACKING YOUR FUNCTIONS!

And that was what we wanted in the first place - To be able to control the firing order.

If you chuck a wait(0.1) in front of a function that cause GPF I will bet you that it will not anymore.

In a sample we are currently working on we wanted to close the form we just left, when we open the new form. 

We can do that with DocumentCloseName(), but it GPFed. Why?

Because we did it in a check in a virtual fields that was setting the SelectionFilter in the current form at the same time.

So:

+If(GetVar("FCustomerNr") not=blank, SelectionFilter("CustomerNr>=",GetVar("FCustomerNr"))+SetVar("FCustomerNr","")+DocumentCloseName("MyTableView"),0)

GPFed.

but

+If(GetVar("FCustomerNr") not=blank, SelectionFilter("CustomerNr>=",GetVar("FCustomerNr"))+SetVar("FCustomerNr","")+wait(0.1)+DocumentCloseName("MyTableView"),0)

Was fine!

Just because the SelectionFilter managed to finish before we move over to closing the old form.

So remember WAIT(0.1) and remember your firing order. If you chain functions you have to know what you are doing, and if you don't just chuck a +wait(0.1)+ between all of them, it doesn't do anything but order the functions so ....

NO HARM DONE!