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.