I wonder it myself. :) But I found this typical for the buttons that run long methods. I would rather think that it is Windows behavior which has something with prioritization of the processes? tasks?. I have seen delayed refreshes in other programs too, for example, in Windows Explorer.

I prefer Draw() in this case to DOEVENTS, since that what I expect the form to do, not process the pending Windows events, some of which may be not related right now to what I am doing. However, I never tested if there is the execution time difference.

>Nick,
>
>You are right, it's been too long since I read that help topic. But that doesn't exactly explain why the heck it doesn't reliably do what the help file says it's supposed to do and forcing a call to Draw(). *bg*
>
>I'll amend my recommendation to:
>
>

ThisForm.SetAll("Enabled", .F., "cmd")
>Thisform.Refresh()
>doevents
>* do the long running thing

>
>I use the .Refresh of buttons all the time with code something like this:
>
>this.Enabled = f( SomethingAboutSomeFieldOfTheCurrentRow )
>
>without experiencing paint problems.
>
>
>>I would disagree with this interpretation of Refresh() functionality.
>>
>>According to Help:
>>
>>Refresh Method
>>
>>Repaints a form or control and refreshes any values, or refreshes a project's visual display.
>>
>>The definition of control in Help:
>>
>>A graphical object, such as a text box, a rectangle, or a command button, that you place on a form to display data, perform an action, or make the form easier to read. Visual FoxPro controls include check boxes, edit boxes, labels, lines, images, shapes, and so on.
>>
>>Therefore, Form.Refresh() is supposed to repaint the command button according it's changed state, i.e. Enabled = .f., not only "updates the displayed value in the control from its .ControlSource" as you say.