SetWaitCursor not blocking events

[Comadreja]

Hi,
I'm working with Labwindows/CVI 5.0 and Windows 2000.

My problem is I set the cursor to wait state for a lengthy operation but, even though the hourglass appears, I can still click on controls and the events keep working. That's not desirable because I would like to block the user interface while the lengthy operation is executing. Is there a way to override or ignore all events?

What I have thought of is defining a global variable 'bwaitMode' and I ignore all events in every callback function when it is true, but this seems not to be the optimal solution, because I have a big UI with lots of panels and controls. That's why also setting all controls to 'notify' or 'dimmed' is not a good solution.

I think I may do something with a loop and the 'GetUserEvent' function to catch all the events and ignore them, but I'm not sure if that would work. I'd appreciate any help on this

Daniel Vilches

[Clarkus]

SetWaitCursor does not block events.
It simply changes the look of the curser.

Are you calling ProcessSystemEvents (); from inside your routine. If this is not called, no other events should be executed until your routine returns.

[jared]

The most correct thing to do would probably be to perform your lengthy operation in another thread using CVI's multithreading API (CmtScheduleThreadPoolFunction, etc...) while the UI thread has a modal message popup installed that prevents the main panel from receiving events. The UI thread should process events so that the events aren't queued up and then serviced after the lengthy operation. I've attached an example (BlockInputMT).

Another way to do it is to install a popup before the lengthy operation and then right after the operation, call ProcessSystemEvents(), then remove the popup. I've attached an example of this as well (BlockInput)

Hope this helps.

- jared

[Jorge M.]

Hello,

Clarkus is right, the events should not be executed/handled until you return from your callback, but I assume that you find inconvenient to process those queued events.
In that case, what I would try is to call QuitUserInterface at the beginning of the lengthy operation and then RunUserInterface when you are finished. In this scenario, no events should be picked up by your CVI application during that time.

Hope that helps!
Regards,

Jorge M.

[Comadreja]

Thanks for the answers.

Jared, that is exactly what I was looking for, because I do have multithread in my app and I do have a special thread that controls de UI, while the lengthy operations are done elsewhere. My problem was assuming that SetCursorWait blocked the mouse events, which it didn't.

The solution of having a messagepopup blocking all the input of the UI thread seems the best one. I'll work in that direction thanks to the code you have posted.

Thank you very much for your help

[Al_S]

It looks like events are queued even when RunUserInterface isn't active.
In the attached sample project, there's a 5 second delay between the initial DisplayPanel and RunUserInterface. If you operate the numeric control during this delay (WaitCursor is displayed), you'll see the updates when RunUserInterface is started.
Other controls on the UI then let you test QuitUserInterface/RunUserInterface in a callback. Whether or not RunUserInterface is active, it looks like the events are queued and will be processed when the callback returns.
I also tried calling ProcessSystemEvents() before calling RunUserInterface, but events still get processed.
Since events prior to the first RunUserInterface are still queued and processed as well, I don't see how QuitUserInterface can be used to ignore all events.
Since other events during a callback are queued and processed only after the callback returns, I don't see that calling QuitUserInterface then RunUserInterface in a callback does anything different.