The way I handle this to keep the BO and UI layers separated, and to insure that the components remain loosely coupled is to create a property on the BO that reflects the progress of the BO. Before VFP 8 I'd create an Assign method to which I'd add a DODEFAULT() and additional code in the instance to update the progress bar or whatever the UI mechanism was. This wasn't ideal, as it required that the BO be added to the UI at design time so the code could be added to the Assign method.

With BINDEVENT() life is really good. The BO needs to know nothing about the UI, and can happily function with or without the UI. However, when the BO is instantiated at runtime by the UI component, it uses BINDEVENT() to hook the visual progress mechanism to the "status" property of the BO - implementing a Voyeur or Observer pattern, in effect.

This delegates responsibility properly to the UI to handle UI functions, and leaves the BO to handle the processing, only updating a property in case anyone (like a form or other visual element) is interested.

If you're using WebConnect, I think you should be able to implement this in a web app too, simply by using BINDEVENT() to trigger a Response.Write() to update the web page with progress information.

>Thinking about it, you are right. What I was trying to get to is that the BO has to have a mecanism for the UI to know how much work is done. The method I described work for me, but I agree that it is not the best design and the one I would have if I had a multithreaded langage.

HTH

>
>Another method would be to have a set of properties and/or methods the UI could query to get the state of the current work. The BO could be started with an internal timer like the method I described before, but instead of having the BO call a callback method in the UI, the UI can have it's own timer to query the state of the BO. It will require more work to implement correcly however.
>
>>PMFJI. It is the responsibility of the UI to ask the BO.