Some coupling are necessary to make things work. As you said, VFP doesn't allow us to raise events, so we have to find a way around it.

What I was trying to say, is this: let say that you have decided one day that the ProgressBar doesn't cut it for you anymore and you want to use the new and improved ProgressPie. This new control doesn't have a method called Update but a method called UpdateMe. You will not only have to change the calling procedure, but the COM also, unless you write a wrapper around the new control.

>THis is true... but, we are talking about VFP which doesn't allow you to Raise events nor does it support callbacks.
>
>The other thing that could be done would be to use an MS Message Queue... the COM server could post progress messages... The UI side could elect to receive those messages or NOT.
>
>But, I always had a problem with tight coupling... and I think this is not the case in this instance. Update() is the public interface to the progress dialog... So, are you saying ANY process that uses the ProgressBar class is tightly coupled to it?