Just to exapnd alittle on what Garrett was saying, the reason for this (I believe) is because of VFP's single threaded nature.

When you instantiate a DCOM server using CREATEOBJECTEX (or whatever) the EXE does run on the remote machine but VFP on the client machine stops processing until the DCOM server returns from what's it is doing. If it runs some long process (although it may be shorther than if you ran it from the client machine), you will not get control back until it is done. The timer enables the DCOM server to return immediately and then process what it needs to.

FWIW, another way to do this (there are always so many in VFP) would be to create a timer object on-the-fly in a wrapper method. You could create a subclass of a timer object and pass in the appropriate method to launch. The warpper method would create the timer object, set the ExecuteMethod property of the new Timer class and return to your application. The Timer would fire and then execute the specified method. VMP uses this technique and we call it a "hand grenade".

As Garrett said, your application would have to periodically check a status flag to determine progress and display whatever you wanted to display.

>Hi Garrett,
>Interesting... I'll give that a try! Thanks!
>Mark
>
>>>Thanks for the response. I think everyone is misunderstanding my question. By
>>>user-friendly, I don't mean having a UI on the server, I mean my UI on the >client app, that invokes the server. Passing messages as you say here is more
>>>what I'm talking about. So how is that done? If I have a method on the server
>>>object that is performing some function, how can I send (return?) a value to
>>>the client app, and then return again to the process?
>>
>>Completely random, half-remembered guess: Try setting a property on the DCOM object that a timer will poll, and start processing. That frees your client app up to query a different property, which gives the Percent Complete.