What I found is that Clear Program will not release an FXP if the Clear Program is issued from the error handler that is handling an error arising within that FXP. But it will release any other FXP's that had been loaded by the MTDLL. I think this non-release is because the FXP cannot be unloaded if a there is an active stack frame for it within the VFP execution engine's virtual call stack.

I have also found that if the COM object is allowed to release gracefully (i.e., nothing happens to effectively halt execution along the object's thread while the object's methods are executing), then the destroy event does fire. I guess in my app this happens when the ASP engine finishes with the page and the VBscript engine releases the object, since in my own app I don't do a "Set oMyComObj to nothing". During development time, the 3 biggies I have in the destroy event are:
Clear Program
Close tables all
RELEASE PROCEDURE xxxx (for all procedures that I SET in the init)

This keeps things from being locked up by the MTDLL in its own thread-local storage even after the object has been released.


>This is good info. We have the Clear Program in the errorhandler of ActiveVFP and in the stub that calls the main prg. In experimenting with the destroy event, it was our impression that it never got executed.