>>>>>>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.
>>
>>I think Rick gave a very good technical explanation (I have learned from it). I have read - probably many moons ago - in a message here on UT that DOEVENTS would help. And you are correct that at one time I wanted to allow user to interrupt the process. But I could never successfully manage to do it. So maybe my DOEVENTS is left there from that time. It does not hurt anything though. Ideally I always wanted this particular part of the application to display the progress (by using ID) and allow user to cancel. But it is like many things: you wish, you try, it does not work, you move on.
>
>
>The GuiThread app I'll be presenting next week will provide a way to spawn a separate "thread" which will handle that kind of UI for you. You can send messages back and forth and have the user not only have the ability to cancel a process, but do real input, real work, whatever.

Great, just remember to drop a note before the presentation that we won't miss it!