Flush event queue

#1

Hello,
is here anybody experienced with GUI feeded by several working threads? I am developing an GUI application which shows frames received from CAN network. The frame reception is blocking function, so it is in dedicated working thread. It makes GUI repsonsive. I guess it is very common solution…
Now about problem…

The widget showing frames is cleared by button. The button throws out an event. The event stops threads, then clean widget and disables button itself. But… sometimes the widget get event from working thread, although the thread is stopped, and so show received frame just after it was cleaned.
Probably thread is stopped but the event is still in inter-thread queue (posted by wx.QueueEvent() ).
Is there way to flush out particular event type from particular event queue? And then, clean the frame showing widget?

#2

Calling wx.GetApp().Yield(onlyIfNeeded=True) should pause until all the pending events have been processed.

#3

Thanks for reply. I have found this:

 # Process all pending events (wxPython events and also events from working CAN RX thread)
if wx.GetApp().HasPendingEvents():
    wx.GetApp().ProcessPendingEvents()

As I understood, it does the same => processes all pending events of the application. Or is there difference againts proposed wx.GetApp().Yield(onlyIfNeeded=True)?

Is it safe to process all events at place of the button event handler? It would be nice to have better control, e.g. possibility to process only specific events or have custom event queue.

#4

Using code like that would normally only be done if you were implementing your own event loop instead of using MainLoop. Using Yield does essentially the same thing, plus a little more IIRC.

It should be okay to allow all events to be processed in the button event handler, as long as there isn’t any possibility of a recursive call to the same handler. Using onlyIfNeeded=True will help prevent that. It is possible to only yield for certain categories of events, although there are not as many categories as one would probably expect. See the docs for the YieldFor method for more info.

Another idea you may want to investigate is to use something other than wx events for your threads to communicate with the GUI thread. For example, your threads can add an object to a thread-safe queue.Queue or collections.deque and then call wx.WakeUpIdle(). In the GUI thread you would then have a EVT_IDLE handler which reads items from the queue and does whatever is needed to process that item. One advantage for your case is that the idle handler will only be called when the wx event queue becomes empty so you know that nothing is pending other than your thread message objects. Another is that you can use program state to decide to ignore some queued items, dump everything in the queue, or even do things like look ahead at items later in the queue to help decide what to do with the current item.

#5

Thank you very much Robin,
your reply realy helped me to see the problem from different point of view. Yeah… wxPython is great framework for native GUI. However it is not universal tool for everything needed when nontrivial application is developed. Although it provides some basic tools for inter-thread communication.

I realy like the idea to use standard queue.Queue and call wx.WakeUpIdle(). It allows better control above thread data exchange.