>I have a program that processes some data records at the click of an on screen button. Because of the SPEED of VFP, the client is worried it isn't doing anything. Sooo, in order to "keep the client happy", I decided to add a status line that will update as the records are processed. The status line is maintained in the "loop" like thus:
>
>thisform.mystatus.value="Record #" + str(recctr) + " of " + str(recmax) + "processed..."
>thisform.mystatus.refresh
>
>Well, again, because of the fantastic speed of VFP, the status line, basically, never appears to show anything.

VFP "buffers" screen updates; if you make repeated rapid updates to the screen, only the "last" update will actually be "seen".

You can "force" VFP to "draw" on demand by issuing a THISFORM.Draw() after you have set a series of Control .value properties or performed a .Refresh().

Also note that setting a Control's .value and doing a .refresh() for a given Control should be mutually exclusive; what a .refresh() actually does is "move" the contents of what a Control's .ControlSource is pointing to to the Control's .value property. In your case, if "mystatus" actually has a defined .ControlSource, setting .value would update the ControlSource, and the .referesh() would move it back to .value.

The proper sequence, in this case, should be:

THISFORM.mystatus.value = ..
THISFORM.Draw()

.Draw() is a syncronous command that will update the screen ... no explicit "delays" are required. In actuality, issuing .Draw() repeatedly in a very tight loop, will slow a program down considerably. Depending on the number of records being processed, I might issue a .Draw() perhaps for every "ten records" so as not to slow things down too much (though this is also dependent on the total number of controls actually being displayed).