>>
>>Every once in awhile, you have to wait for the system (operating and otherwise) >to complete its chores before you can go ahead with your's. I suspect that's >what you're seeing here. When I've encountered such things, I've inserted a >timing loop.
>
>they won't believe that either!
>
>I think, however, in my case its just a case of calling the routine at the wrong point in the release process. I'm trying to do a cleanup routine which releases any forms which haven't already been released (is this even necessary I suppose I should ask - or can we just issue a cancel or quit regardless and the system closes everything down for us?)
>

QUIT will release all forms and close all tables as long as a CLEAR EVENTS has been issued and no transactions/table changes are pending. The conditions noted will either pop a VFP error dialog or give a "Cannot close Visual Foxpro" error

>Anyway, for what its worth, I simple check for whatever form is 'wontop()' and call its release method. No problem except for some I'm just closing which come up as being wontop() but then when you call the release method, we get the message that it's no longer an object. Yet if we suspend at that point, not only is it wontop() but it also returns .t. for wexist. The giveaway that its in the process of disgorging itself is that its form name now has a null value rather than 'object'.
>

You need not check WONTOP(); a simple solution using the VFP Forms collection would look like:

FOR EACH oForm in _VFP.Forms
   oForm.Release()
ENDFOR

>I can't wrap my head around the concept of an object which has ceased to exist in memory but still tells the system it is the currently active window!
>
>Harry