>>>>>>>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.
>>>>>>
>>>>>>How do you update the textbox value? Does it use control source or you set the VALUE property in code?
>>>>>
>>>>>I set the VALUE property in code; as the DO WHILE loops.
>>>>
>>>>I use a similar approach using THISFORM.DRAW() and it always updates the textbox or label that is updated, so it's strange that it doesn't do that in your situation. Why do you have a DOEVENTS in the loop, can the user cancel the process? Maybe you should try the code without the DOEVENTS to see if the DRAW does work then.
>>>
>>>
>>>DOEVENTS is required to process Windows messages when other serial processing is taking place (lots of code which doesn't read user input, but does SQL queries, runs in loops, etc.). It's what prevents the system from saying "Program Not Responding" if there is a lengthy data retrieval process or something. Internally Windows maintains a "message queue" for every visible window, along with hidden "message windows". If that queue is not having its messages read periodically, then after a specified amount of time Windows will say "not responding" and the screen will become partially obscured to indicate the app isn't working in accordance with the dictates of Mr. Windows, PhD. :-)
>>>
>>>DOEVENTS FORCE is useful because it will process events with a significant effort given to the task, but it does slow down loop processing notably. As the OP indicates, it's only a millisecond here or there though, so it's probably not noticeable in the overall scheme of other user tasks, just when processing tight loops.
>>
>>This reminds me about an issue I have :)
>>
>>I have a long process (5 minutes) that runs various methods on a form. It displays a thermometer and many wait window nowait's to tell the user what is happening. However, often after a while the display stops updating; the thermometer stops, and the wait windows stop appearing. Sometimes a Windows message appears ("non-responding") . When the code is completed, the display refreshes and all is good.
>>
>>Could I use your suggestions to fix the display of the thermometer and wait windows? Where would I call it - once at the beginning; Or each time the thermometer is updated??
>>
>>
>>Cyril
>
>
>Yes. Somewhere after you update your thermometer add DOEVENTS FORCE. If you rapidly update it, then add logic to only update every couple of seconds only.

Thanks for the DOEVENTS FORCE suggestion and info.

Cyril