>>>>Also, one thing you might do after your Draw() code is add this:
>>
DECLARE INTEGER InvalidateRect IN WIN32API INTEGER hwnd, INTEGER ignore1, INTEGER ignore2
>>InvalidateRect(thisForm.hwnd, 0, 0)
>>*InvalidateRect(thisForm.hwnd, 0, 1)
>>>>
>>>>That will force the window to repaint itself at the Windows OS level, and may help it "go away".
>>>
>>>The Themes = .F. had no effect.
>>>But InvalidateRect() does work perfectly, I don't even need to call THISFORM.Draw().
>>>So I created a method THISFORM.Redraw() and put the API call in there.
>>>Thank you!
>>
>>
>>You're welcome. I updated the note above about the ignore1 and ignore2 values. The ignore2 parameter is actually "redrawBackground?"
>
>PMFJI, but I was wondering if the above code (using InvalidateRect) would work for a following case:
>I have a form that processes many items (actually printing report for each item). So I wanted to show the ID of the item being processed in a textbox on the form. I have code:
>
>thisform.Draw
>DOEVENTS
>
>in the DO WHILE loop where the items are being processed. It never actually showed the items (at least I never could see them). But I left the code there and since the customers didn't complain, I forgot about it. If I replace my thisform.Draw with the above API function call, do you think it will work showing the items being processed? And if yes, would it make sense to call the
>
>DECLARE INTEGER InvalidateRect IN WIN32API INTEGER ...
>
>only once at the top of the procedure and then only call Invalidate() after every record ID is set in the textbox on the form?
>Thank you.
The WM_PAINT message is the message the Windows OS sends out to the program running the window (Visual FoxPro) to tell it to redraw itself. Until you are in the READ EVENTS loop, and in a place where it is processing events, it won't update. Using InvalidateRect() in combination with DOEVENTS or DOEVENTS FORCE if you really need it to update will likely work, but will impact tight loop processing performance.