>>Create an out-of-process COM server. Create a property in the COM object which indicates the degree of completion that the client can poll. Create two methods in the COM object; one is called by the client to start the operation, and the other actually performs the operation. On calling the first process, the COM object clears the member property and starts a timer that will trigger the long operation on delay. Return control to the client. THe trigger fires the long operation, periodically indicating it's progress in its member property. The client polls the member property at intervals to determine the degree of completion, using the value of the member property to update a progress bar in the client app. The call is finished when the second COM object method completes and sets the member property to it's done condition. If any result needs to return to the client, it should be placed in a member property of the COM object on completion of the call.
>
>
>ED, Could you post a code sample for this ?

Take a look at the Pool Manager sample that shipped with VFP; it implements an out-of-process job server that demonstrates implementing asynchronous job servers in VFP. I'd use an Event tonotify the app when each job finished; there's much less overhead to wait on an event to be signalled than to read COM object property if all I needed to know was if it finished and it ran locally; events won't cross workstation boundaries, so they don't work under DCOM, but they have the advantage of being able to notify multiple clients of an event at once, and the server doesn't have to wait for the clients to respond; the state is maintained by the OS, and it goes away as soon as noone holds a reference to it. It only has two states - signalled and unsignalled, limiting what it can tell you. It's one of the native synchronization functions in Win32.