I don't know if SYS(2335) makes any difference here. In the help it says: Note that SYS(2335) applies only to .exe automation servers for which the StartMode property equals two. Unattended mode is always enabled for in-process .dll automation servers (for which the StartMode property equals three).

I don't need to get information back to the COM client with COMRETURNERROR. Rather, it's the issue of gracefully exiting a critical section even when an asynchronous jump occurs (such as an error event within the CS), so that the CS does not remain "activated".


>Mark you should use COMRETURNERROR see the help for more information. also u should set SYS(2335, 0) in the init event of your VFP COM object to prevent situations like that to happen.
>
>>I have this VFP COM MTDLL that has a short critical section in it. The MTDLL is used by an ASP app. I have run into a problem. Currently, when the error event for the COM object fires while in the CS, the expected things do happen and the appropriate reporting happens on the web page, and then the object returns control to ASP, but the critical section is not exited (control in the VFP code does not return to the point where the error occurred and continue through the remainder of the CS). The next time any browser session instantiates the same COM object and comes to the CS, it hangs because the a previous CS was never exited.
>>
>>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?
>>
>>Thanks very much.