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


Ed, This is just the kind of help i needed, Thanks a million !

Stephane