>>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 ?

I don't have any handy, but the idea is fairly simple. An out-of-process COM server is a separate .EXE, which can have a UI. You have a method which accepts a request, saves the parameters in member properties in itself, and starts a timer. It returns control to the client, probably passing back a reference ID for the result - it might use a member array to allow several results or statuses to be examined during it's life uniquely. The client goes on about it's duties.

In the out-of-process server, the timer fires. It triggers a protected method to perform the long operation, passing parameters as needed. The protected method updates the progress member property to show it's status and progress servicing the request. Running out-of-process, it can operate in parallel to the client app, and simply publish its status in execution. It could run on a remote machine via DCOM just as easily as locally out-of-process.

The client gets responsibility for tracking the progress of the job submitted by polling the member property of the out-of-process server; if it wants to display a progress bar, it does it as a part of the client app.

This is no different than running job servers - I have a database of jobs which need to be run during end-of-month processing for some apps; I create a database of these jobs. Any idle machine can serve as a job server - it polls the database to see if there is anything pending, and if so, it marks the record as in process and fired the pending operation. The client can check the database to see what has run, or is running; it's premised on these jobsallowing shared access to the database and nothing being dependent on the execution to proceed with it's work - usually these are jobs which generate summary reports which, while ultimately required, don't stop other processing from going on.

So basically, the out-of-process server has an OLE COM interface that publishes a method that accepts requests, and publishes a member property to report progress. The server also has a UI which includes a form with a timer and a method to perform the long operation. The OLE class accepts requests, saves its parameters and starts the UI timer before returning control to the client. The timer fires and triggers the method, which updates the status property of the COM object as it proceeds. The client checks the COM object progress property to detect it's progress, and if needed, displays a progress bar in the client app's UI.