Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
DRAW() not working as expected
Message
From
16/06/2013 19:19:52
 
 
To
14/06/2013 09:03:21
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows 2003 Server
Database:
MS SQL Server
Application:
Desktop
Miscellaneous
Thread ID:
01576345
Message ID:
01576528
Views:
105
>>>>>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
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform