As an alternative, check out this code and thread #910724 :

&& server objects (compile into COM-Exe)

DEFINE CLASS oTestServer AS Session OLEPUBLIC

    loCallback = .NULL. && saves reference to callback object
    lAdvised = .F. && is callbackobject set?
    HIDDEN loTimer

    FUNCTION Init
	DECLARE INTEGER Sleep IN WIN32API INTEGER		
	THIS.loTimer = CREATEOBJECT('dirTimer',THIS)
    ENDFUNC

    FUNCTION Destroy
	THIS.loTimer = NULL
	CLEAR DLLS	
   ENDFUNC

   FUNCTION FireEvent AS VOID
      LPARAMETERS lcSomeValue
      IF THIS.lAdvised
         THIS.loCallBack.EventMethod(lcSomeValue)
      ENDIF
   ENDFUNC

   FUNCTION Advise AS VOID
      LPARAMETERS loObj
      THIS.loCallback = loObj
      THIS.lAdvised = .T.
   ENDFUNC

   FUNCTION UnAdvise AS VOID
      THIS.loCallback = .NULL.
      THIS.lAdvised = .F.
   ENDFUNC

   FUNCTION SomeMethodThatFiresEvents AS Boolean
        && prepare something
        THIS.FireEvent('Task startet .. ')
        Sleep(5000)
        THIS.FireEvent('Task finished X percent ..')
        Sleep(5000)
        && do more
        THIS.FireEvent('Task fineshied XX percent ..')
        && ..
    ENDFUNC

    FUNCTION DoSomeAsynWork AS Boolean
    	THIS.loTimer.Interval = 1
	RETURN .T.
    ENDFUNC

ENDDEFINE

DEFINE CLASS dirTimer AS Timer

	Interval = 0
	loParent = NULL

	FUNCTION Init
		LPARAMETERS loObj
		THIS.loParent = loObj
	ENDFUNC

	FUNCTION Destroy
		THIS.loParent = NULL
	ENDFUNC

	FUNCTION Timer
		THIS.Interval = 0
                && do some work
                Sleep(1000) && sleep to simulate some work ..
		THIS.loParent.FireEvent('Timer Fired')
	ENDFUNC

ENDDEFINE

&& client testprogram
startprocess.prg:

PUBLIC loFoxServer, loEventhandler

loFoxServer = CREATEOBJECT('testcom1.oTestServer')
loEventHandler = CREATEOBJECT('oTestCallback')

loFoxServer.Advise(loEventHandler)

DEFINE CLASS oTestCallback AS Session OLEPUBLIC

    FUNCTION EventMethod
        LPARAMETERS lcSomeParam
        ? lcSomeParam
    ENDFUNC

ENDDEFINE

startasyn.prg:

?loFoxServer.DoSomeAsynWork() && returns immediately .. 

&& simulate block situation
DECLARE INTEGER Sleep IN WIN32API INTEGER
Sleep(15000) && the event of ther server is fired when this runs


endprocess.prg:

loFoxServer.Unadvise()
loFoxServer = NULL
loEventhandler = NULL

>Several months ago I made an attempt to use some of the help and code found herein to simulate some multitasking from my application. We tried some timer stuff and timer stuff from inside a COM app, etc.
>
>I was unsucessful as it just took longer than I had time to accomplish. It was postponed. I now have to revisit and accomplish this.
>
>My requirement: My app keeps up with account transactions similarly to what banking software would do. I need to ask for an account balance but NOT wait for the answer. I was led to an article by Randy Brown on MSMQ (Message Queue), and after a lot of reading this sounds like exactly what I need. Mr. Brown stated my requirement probably better than I could:
>
>Asynchronous messaging – have you ever written a Visual FoxPro application where one of the application operations takes a long time to perform (e.g. printing a report, re-indexing a large database, etc.)? Visual FoxPro does not return control to the user until the operation is completed. This can be very annoying to the end user who is trying to be productive with your application. Many Visual FoxPro developers employ kludges to handle these situations such as Timers and DO WHILE loops which continuously poll some resource (e.g., file or table) for a change (semaphore) made by the application. These types of coding habits are not efficient and needlessly waste valuable system resources and processor time. With asynchronous messages, you can setup a VFP object that sits in limbo until a message arrives in a queue. Once this event happens, a method on your VFP object is called. You can call a VFP COM server, which runs in its own process, to handle the application request and allow the
>user to continue working. The MSMQ Message can contain all the information being passed from your application to your VFP COM “helper” server. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxgen/html/msmqwvfp6.asp
>
>That pretty much sums up my need. I want to ask for an account balance and NOT wait for the answer. When the answer arrives I want some code to be executed.
>
>I need help understanding something "BIG PICTURE" and it may really help to get this resolved more quickly. I need to know that I am understanding the big picture. Here is what I believe. Please correct me:
>
>I have a VFP/(Visual Fox Express framework) app. There is a read events. I kind of percieve the Read Events as the VFP runtime or the application's interface with the VFP runtime. If I understand correctly the Read Events is sitting there polling input devices. When an input device (keyboard, mouse, etc) does something, Read Events calls the associated method.
>
>If I am understanding MSMQ correctly, MSMQ becomes like another input device to the VFP runtime. Just like a mouse can trigger an event, MSMQ can trigger an event as well.
>
>So basically I would have an app (with a UI) running on a workstation(WS) and another COM app running on the server.
>
>The WS app tells (via a message), the server/COM app's "WorkstationNeedsBalance" method to fire. That method gathers the balance data and calculates the balance and then tells (via a message), the WS app's "BalanceIsReady" method to fire.
>
>Have I got the basic principles correct?
>
>Thanks,
>John