Will,
Since you have a wrapper anyway, why go the public variable way? You could just as easily add the code to find the form in the collection as check the vartype of a public variable.

I say this because I also hate public variables and avoid them whenever I can.

>Thanks for you response Larry,
>
>You've kind of confirmed the conclusion I had come to.
>One thing I did think of was...
>The old system uses do progress.spr
>this spr is now empty (except for Do Form progress)
>so I could just chuck some code in to the SPR to handle the progress bar.
>
>

>lParameters tnPercentage, tcDesc
>
>Public oProgressBar
>If Vartype(oProgressBar) = 'O'
>	oProgressBar.cntProgressBar.SetValue(tnPercentage, tcDesc)
>Else
>	DO FORM "eProgress" With tnPercentage, tcDesc Name oProgressBar
>Endif
>If tnPercentage = 100
>	oProgressBar.Release()
>	oProgressBar = Null
>Endif
>

>
>I hate using Public variables but I think this could be a workaround for my problem.
>
>>The difference you are seeing is the objectification of FoxPro in VFP. SPRs (FPW screens) merely defined a window and wrote things to it using @ SAYs/GETs. When you ran the SPR again with a new parameter, you just overwrote what was previously in that spot on the desktop.
>>
>>In VFP, forms are objects and completely self-contained. Re-running a form with a new parameter creates a new instance of that form (as you have seen). IMO, you are going to have to re-think the concept. IN VFP terms, you will have to get an object reference to the progress form and call a form-level method to change the label (or whatever) that is showing progress.
>>
>>You can easily get a reference to the form by looping through the _Screen.Forms collection and checking some attribute of the form you know exists. For example, you could write a function that accepts a parameter, checks the caption property to make sure it corresponds to the passed parameter and return that object if it does. Then you could change any control on that form using the returned object.
>>
>>HTH.