Event processing and QuitUserInterface

[Wolfgang]

Dear experts,

I have a very basic question

I have a Quit button with an associated callback routine which looks like:

if ( event == EVENT_COMMIT )
{
// free dynamic memory

// close open files

    QuitUserInterface ( 0 );

}

Now it turns out that if a user is impatient he can hit the Quit button twice and obviously the callback routine is called twice, too, which causes a crash because the dynamic memory has been freed already in the first call. I would have assumed that after QuitUserInterface no more events are processed.... but it seems that pending events are still processed. Is it correct?

My solution to the problem would be to use a toggle parameter to make sure that the callback is called only once. But I wanted to (better) understand the event processing in this case.

Thanks!

[RobertoBozzolo · Accepted solution]

Hello Wolfgang,

I normally revert the order of operations in closing the application: QuitUserInterface first, all other tasks in the main function after RunUserInterface line. This avoids further events being triggered, since the application is no more processing them.

[Wolfgang]

Thank you for the valuable hint!

[RobertoBozzolo]

You're welcome!

And possibly adding a SetWatCursor (1) would help keeping impatient users calm! 

[Wolfgang]

---

I would have assumed that after QuitUserInterface no more events are processed.... but it seems that pending events are still processed. Is it correct?

...But I wanted to (better) understand the event processing in this case.

---

Thanks to Roberto I have nicely resolved the issue but I still want to clarify/understand the event processing scheme...

In the scenario described earlier all pending events seem to be processed, QuitUserInterface only seems to prevent the generation of new events.

Somehow I have understood the help of QuitUserInterface in a different way:

• Firstly it states that QuitUserInterface terminates event processing. This statement is somewhat vague but I would have assumed that it terminates event processing immediately. This seems not to be the case.
• Secondly, it also states that it causes RunUserInteface to return after all currently executing callbacks have exited. Since my application is single threaded there should be only one callback at any time, so this also should exclude the same callback with a QuitUserInterace called twice.

So either I am on the wrong track, in this case I'd be grateful to learn, or the help is misleading and should be rephrased.

Thanks either way.

[RobertoBozzolo]

Yes, that "currently executing callbacks" is dubious: it effectively refers to running callbacks (one at a time, not considering threading as you stated) or to callbacks already posted in the queue (including UI events, timers, PostDeferred or PostDelayed callbacks and so on)?

I have had problems in some applications where a timer was querying external devices on the serial port and I was getting "Port not open" errors well after QuitUserInterface and CloseCom, and I ended up stopping or discarding the timer prior to closing the port to avoid those errors: it goes in the line that "executing callback" is quite a wide term here.

You know, I am puzzled that the user is able to press the quit button twice: normally inside a button callback a second event is not processed (the usual question from newbies: "I am not able to stop a running process"), and since your callback terminates with QuitUserInterface I would assume that the second press is ignored, but apparently not (unless in your clearing code a ProcessSystemEvents is present, but I am almost sure it isn't).

[Wolfgang]

I have found the following document that states that pending events are still processed and only then RunUserInterface terminates. This answers my initial question

Thanks again, Roberto, for assistance!