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.
Nick Neklioudov
Universal Thread Consultant
3 times Microsoft MVP - Visual FoxPro
"I have not failed. I've just found 10,000 ways that don't work." - Thomas Edison