LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting EVENT_CLOSE into a loop of GetUserEvent()

Hello All,

it could seem trivial but I have no idea about how to be able to close my application when I am into a loop using the GetUserEvent function.

As far as I have understood, GetUserEvent() should allow processing system events but it doesn't.

Please look at the attached example (it is meaningless, just an example). If you click on X to close the program it doesn't work immediatly, first you have to click on OK button (sometime more than once).

Any suggestion about that?

 

Thanks

Sergio

0 Kudos
Message 1 of 4
(3,193 Views)

There are a few problems. The main issue is that you have some confusion as to how to process events. You don't need (and shouldn't have) the timer to process events. The call to RunUserInterface in your main function is your processing loop. It will continue processing events until a call to QuitUserInterface signals it to stop. You have created a timer which processes user events and commits in a loop until it gets one. Note here that GetUserEvent can only return a small subset of all possible UI events: only commit events and special user-defined events. What is happening is this:

1. RunUserInterface processes the first timer tick event, and it calls the associated callback function, Timer1Second.

2. Timer1Second enters a while(1) loop and keeps looping until GetUserEvent returns a commit event.

3. GetUserEvent only returns an event after you have clicked on the OK button, because clicking the panel's close button ([x]) does not generate a commit event -- it generates a panel close event. RunUserInterface would process the panel close event, but it cannot process any other events until Timer1Second has returned. As a result, you have to click the OK button before you see any response to clicking the close button.

 

Also, note that GetUserEvent returns a panel handle, which is different than a panel constant. The panel constant (MAIN) is only used when loading the panel, after which you always use the returned panel handle. So your test should have been:

        if ((hPanel == panel) && (lControl ==MAIN_COMMANDBUTTON))

 

Hope this helps.

 

Mert A.

National Instruments

0 Kudos
Message 2 of 4
(3,180 Views)

I need to correct my previous post. When I said that GetUserEvent only returns commits and user-defined events, that's true, but before it actually returns, it does process other events that may be waiting. This means that your panel callback (and therefore, QuitUserInterface) probably is getting called, but all QuitUserInterface does is set a flag that allows RunUserInterface to return. However, RunUserInterface is waiting on Timer1Second to return, so until you generate a commit event by clicking the OK button, you're not going to leave your while loop.

 

You should be able to verify all this by debugging and stepping through your program.

 

Mert A.

National Instruments

0 Kudos
Message 3 of 4
(3,167 Views)

Thanks a lot Mert,

 

you have been clear and exhaustive explaining the mechanism of events processing. Now I know what to do.

Besides you were right about the panel handle. I quickly created that unuseful code, just to have something tangible for the discussion, and I made the mistake.

 

Thank you again.

Sergio

 

0 Kudos
Message 4 of 4
(3,158 Views)