Hi Mark,

Thanks for the info about this issue. So it seems that this can be solved in ActiveVFP. Personally I don't have the programming know-how to solve it myself. I hope that Claude can solve it and publish the solution, so that everyone can benefit from this. In the mean time I will try Ann Marie's option: recompile the mtdll.


>"CLEAR PROGRAM main" will not work the way you have things arranged. If an error occurs in "main" or any routine called by main, your CLEAR PROGRAM statement will not work for "main" if issued within the error handler. You need to set a flag in the error handler, let the stack unwind, and then test for the flag and issue the CLEAR PROGRAM if the flag indicates that such an action is appropriate.
>
>>Thanks! AVFP has this architecture:
>>
>>ASP/ASP.NET
>>|
>>Proxystub.prg - subclasses ActiveVFP(so it uses the error handler from there),creates ActiveVFP objects, calls main.prg. has this code after main.prg is called:
>>SET PROCEDURE TO
>>CLEAR PROGRAM main
>>|
>>Main.prg - externally marked, main application code (this is the one that needs to be unloaded), uses ActiveVFP objects
>>|
>>Activevfp.prg - contains the various classes
>>has this code in the error handler:
>>SET PROCEDURE TO
>>CLEAR PROGRAM main
>>
>>* main.prg is external so that it can simply be replaced on a live server when new code is introduced (sort of like asp.net)