>I've run into a problem at a client site.
>
>It seems that VFP5 occasionally runs ahead of itself. It occurs most often when calling specific methods or DODEFAULT()'s. If a property of a form is set in the method, the line of code after the method runs with the old property value.
>
>Something like:
>
>thisform.lMyProperty = .F.
>thisform.myMethod()
>IF thisform.lMyProperty
> WAIT WINDOW 'Property is True'
>ENDIF
>
>myMethod() Method:
>...
>(Code)
>...
>thisform.lMyProperty = .T.
>...
>(More Code)
>...
>RETURN
>
>The WAIT WINDOW sometimes fires. If I run the code with the TRACE window open, it always works (of course! ).
>
>I'm not sure if it matters, but the clients are running on very fast (Pentium II 400) PC's.
>
>Anyone else seeing oddball behavior like this? Any Idea what will happen to similar code on the inevitable Pentium 800's which will be coming into fashion a few years down the road?
>
>- George [Perplexed]

You arre not dreaming, George...

In some rare situations "VFP 5 gets a bit ahead of itself" as you said.

That happened to me once in a different situation, a piece of code like:

** instanciation of a modeless form
DO FORM BePatient
** create SYNCHRONOUS SQL pass-thru call
SQLEXEC(....)

the second instruction would start before the first one has completed.

I had to put some waiting code (a one second timeout) after FORM instanciation in order to get the screen showing properly... odd and possibly related to the optimizations that the VFP team brought to the product when moving from 3.0 to 5.0. That is my guess.





the second line of code would start executing before the first has produced its results