Hi!

It is depended on the way you call this COM object. For example, imagine situation when you call the COM object to request a lengthy operation for it. After that in some other place in the program you try to call the COM object again to get another data and cannot, because COM object is busy working on previous task. As far as client application aware about such thing, no problem.

There are no otehr issues as far as I know.

>When I need to have longer tasks or scheduled tasks done by
>a COM Server (EXE) and do not want to wait for completion,
>normally do start a timer from within a StartProc and return
>immediately. Within a few ms the timer starts and actually
>Starts the process (see example below).
>
>Good approach, bad approach, any other ideas?
>
>

>
>DEFINE CLASS TEST as SESSION OLEPUBLIC
>    o_tmrStart = .NULL.
>
>    PROCEDURE INIT
>      .o_tmrStart = CreateObject("tmrCmd")
>    ENDPROC && INIT
>
>
>    PROCEDURE Start
>     ....
>     public go_App
>     go_App = This
>
>     if .EverythingIsSet()
>         .tmrStart.c_Cmd    = "go_App.TheLongerTask"
>         .tmrStart.Interval = .tmrStart.n_Delay
>         ll_RetVal = .T.
>     else
>         ll_RetVal = .F.
>     endif
>
>     return ll_RetVal
>
>    ENDPROC && Start
>
>    PROCEDURE DESTROY
>      rele go_App
>      .o_tmrStart = .NULL.
>    ENDPROC
>
>ENDDEFINE  && tmrCmd
>
>DEFINE CLASS tmrCmd as TIMER
>    n_Delay = 20
>    c_cmd   = ""
>
>    PROCEDURE TIMER
>     if this.Interval = 0
>         return
>     else
>         This.Interval = 0
>     endif
>
>     lc_cmd = .c_cmd
>     &lc_cmd
>    ENDPROC
>
>ENDDEFINE && tmrCmd
>
>