force application to update

[tommyH]

I have created a labwindows application that has a lengthy process (about 5 minutes). During that process I am using the progressdialog while it is waiting to complete. If I do something else on the computer, (for example open a web browser, or text file), the gui stops updating itself, but the application is still running. Is there a way to force the application to update its user interface? That way the user can see the progressdialog update instead of being stuck at somepoint until the whole process is complete.

Thanks in advance

[Al_S]

Tommy:

Have you looked at using ProcessDrawEvents()?

Here's some of the help info:

When your program executes in a callback function or in code that does not call RunUserInterface or GetUserEvent, LabWindows/CVI does not update the user interface. Functions that are overly time-consuming can "lock out" user interface updates. To allow LabWindows/CVI to process these updates, call ProcessDrawEvents.

[Al_S]

If your program just runs that much slower when other applications are running, you could use SetSleepPolicy to give more time to your app.  The default is VAL_SLEEP_MORE, which is nice to other programs, but you can set it to VAL_SLEEP_SOME, which gives more time to your app.

SetSleepPolicy (VAL_SLEEP_SOME);

[tommyH]

Thanks for the response Al.

I tried the SetSleepPolicy and also the ProcessDrawEvents, but am still having issues. For example, i have a GUI that is turning on a test unit and just waiting for about 5 minutes. Im using the UpdateProgressDialog to give the user some sort of feedback of the process. The dialog is displayed on top of the main GUI. If I move the dialog around...it leaves a blank spot on the main GUI.  Also the progress dialog stops updating and the main gui displays a (Not Responding) message like other windows applications. Any other ideas?

Thanks again

[jr_2005]

The only time we ran into a similar issue was when we experimentally tried a CVI 7.1 application on a Vista platform. Mostly seem to work, until the application lost focus - it then (if a popup panel was shown) stopped updating the GUI, no matter what we tried. (Application kept on working internally - it just failed to communicate its output via the GUI.)

In the end we told the Customer not to use it with Vista and to stick with XP - it worked flawlessly there. What versions are you using?

JR

[tommyH]

LabWindows CVI8.1.1 on Windows XP SP2

[menchar · Accepted solution]

You might try ProcessSystemEvents instead of the draw events call - I think ProcessSystemEvents is implemented as something of a grabbag of functions that allows Windows to do what Windows wants to do when you call it, more stuff than the draw events call does.  From what you're describing, your main window is not getting repainted.  Normally, the main window message queue would be getting "repaint" messages sent to it by the OS, and it needs to process windows messages to do the repaint.  If you grab the main thread and have it off doing something, it's not going to get a chance to process messages unless you let it.  

Adjusting the sleep policy wouldn't seem to help this directly, would it?  Putting the main thread to sleep periodically may help other processes proceed,  but it doesn't help your CVI app I wouldn't think - maybe I misunderstand the sleep policy.

If you had a main window message callback installed and had it "swallowing" the repaint messages I suppose it might act that way - but you're not doing that I'm sure.

And the modality of your topmost panel shouldn't stop the main panel from repainting I wouldn't think - even if the top panel were "modal" (all KB/mouse events restricted to and handled by the top panel - none allowed on the main panel) I think the underlying main panel should still repaint when you move the top panel around.

Good luck - let us know if you solve this.

Menchar

[tommyH]

Thanks everyone. ProcessSystemEvents did the trick