Christof,
Let me run this by you. I'm must wondering if this approach will work.
The current path of execution in the DLL is this:
- when an error condition occurs, the COM object's error event is entered
- the event code does a bit of error logging and displays error info in the browser window
- The COM object has an object reference to some of the ASP objects, so it issues: oASP.oResponse.end (terminating the web page)
- The COM object then issues a "cancel" command while still within the error event, and then returns, which terminates processing in the COM object, but its Destroy event still fires
- The Destroy event does some cleanup (closing tables, doing a Clear Program All, etc). I keep a lot of the VFP modules I use as "external" FXP files that are invoked when needed by the DLL.

So consider possibly just putting SYS(2336,3) in the destroy event, just to be sure that any critical section that had been established within that thread gets freed upon destruction of the object. Will this work, just as a blanket cleanup operation, or could it cause probems?

Thanks!





>Hi Mark,
>
>>Is there a preferred way to deal with cleanly exiting a CS even when an error event fires? Or possibly deal with error handling completely within the CS itself?
>
>If it's possible you should use a TRY CATCH block for the critical section. Enter the critical section in the TRY block and leave it in the FINALLY block. FINALLY is always executed, no matter if there's an error or not.
>
>If you can't use TRY blocks, the alternative would be to use an object that enters the critical section in the Init and leaves it in the Destroy event. Create this object and store the reference in a local variable. If for some reason the error handler cancels execution, the object is released and its Destroy event fires.