Thanks for the help Steve, I really like this method. My only question is: is events raised with RAISEEVENT in VFP can be trapped by other language, like .NET, or only VFP can trap them?

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