I can share my experience with the problem you are describing:

If your MTDLL is dispatching to an FXP, then you need to put a Clear Program statement in the destroy event of your COM object, at least during development time.

I have found that this approach works great and really expedites web development. I can tweak the PRG, recompile to FXP, and the new FXP is used seamlessly by the MTDLL.

It's trickier if the error happens in the init event of the object, because the object might not get created, and thus the destroy event doesn't fire. But I have found that this is only a problem if an error is trapped in an FXP that you call from inside the init event. It seems that the callback to the object's error method happens with the FXP still cached and locked in (still on the call stack just below the error method), so Clear Program won't release it. Instead, in this circumstance, I have the error method set a flag (object property), and I check for it after the stack has unwound back to the init even itself, and issue the Clear Program then if the flag is set. Then the Clear Program works. Note that only seems necessary if your init even can fail in such a way that the object does not get created.

>Hi All,
>
>I have a small web application that's written in ActiveVFP. I test the application by writing code in the main.prg and immediately after I compile the file so that I can see the effects in the browser. Ofcourse code-errors can occur, the only irritating thing is that after the occurance of an error I can't compile the code. I get the following error message when I compile the main.prg:
>

>cannot create file main.fxp
>

>
>I have to wait a minute or so before I can compile.
>
>Does someone know why this happens? Or help me to overcome this?
>
>Thanks beforehand.