>Ok Ed. Bu if I used vfpcom.bindevents to bind mabry to a my vfp .dll (multithread compiled). I think that every object call in the dll binded is another object instance. Doesnt it.
>Mabry com events are handled by my MabryHandler dll. MabryHandler.requestdone events call a method of a class compiled as multithread called Execute. Way new execute have to wait the end of the first execute called from mabryhandler ?? I don't understand.

It's simple - the call is blocking Unless you actually spawn a new instance of VFP (not just the same instance of VFP with a separate TLS), VFP can only multitask between executable lines of code, and not even always then. Because you lack callbacks, you have no way to return from an execute and restart - the return terminates the method call, and you need a new method call to resume the session with the client, even if code executed at the server on behalf of the released client can run in parallel, as would be the case if each instance of asynch code ran as a separate instance of VFP.

IOW, with what I understand of how VFP's thread model works, you can't get to where you want to be with only VFP code.