Missing events

[tubbutec]

Hi,

in my application I use the ugfx event system and often notice that an event is missing. My understanding is that if a new event occurs before the old one was processed it overrides the old event.

Unfortunately this is quite fatal for my application.

How can I prevent this? Do I have to implement some kind of event queue? Or can the sender at least detect somehow that there is an unprocessed event and send the new one later?

thanks

[Joel Bodenmann]

The current implementation of the GEVENT system doesn't feature an event queue. This is one of the consequences of other decisions that were made back then to keep overall system resource requirements low. Usually this shouldn't be a problem because the GEVENT sub-system is only used for managing the GUI. If you're not listening for incoming events using geventEventWait() you will simply miss the event.
This is one of the things that will be changed in µGFX 3.0: An optional event queue.

The proper solution to this problem depends heavily on your system and your application. If you are using the GEVENT module to handle time critical physical interfaces then you are doing something wrong. Just like the other modules of µGFX (for example GTIMER) the GEVENT module has been designed to be used for managing the GUI.
Another solution is, as you mentioned, to build a queue yourself. You can use the existing GQUEUE module which provides extensive implementations of different queues. 

Just as a short follow-up: When you say that "this is quite fatal for my application", that sounds like you are indeed using the GEVENT module for something it was not designed to. May we ask what you are doing and what the problem is that you're facing?

[inmarket]

Just to be clear...

Each listener contains a single event buffer. An event will be put in the buffer provided it is not already full with an event (whether or not the listener is currently waiting). If it is currently full most event sources mark a flag that indicates on the next event that an event has been lost eg the mouse source.

A listener with an event in it gets that event cleared/released when it calls geventEventWait or geventEventFree.

The gwin and other event sources have been carefully written to ensure that a single source event doesn't create a chain of subsequent events that would be lost due to listeners already being full. Eg. That is why a slider only generates a "change" event and doesn't support sending a "click" event. 

As @Joel Bodenmann mentioned this design is really all about resource management for small micro's. An event queue uses up too much ram or more specifically an non-determinate amount of ram. Restricting listeners to a single event at a time prevents problems on ram constrained micro's.

[tubbutec]

Hi, thanks a lot for this clarification.

Here is a typical example in my application:

I am using hardware buttons which send events when pressed and released. I am not using the toggle driver, but a driver derived from it.
If I now press two or more buttons simultaneously, sometimes not all of the events will be received.

An other example is a modified list widget, which sends events while (smooth) scrolling.

Would you say I am misusing the GEVENT module here?

In previous applications I used a very simple fixed size FIFO event queue to prevent these issues, but here my events only had a size of one byte. I understand that would probably not be practical with GEVENT..

Thanks a lot!

[Joel Bodenmann]

2 hours ago, tubbutec said:

Would you say I am misusing the GEVENT module here?

I am not. That is what the GEVENT module was designed to be used for so everything is okay. What I meant is that it would be wrong if you would use it to drive a ModBus interface or other time & event critical things.

To wrap it up: It seems like you are hitting one of the limitations of the current version µGFX. Having an (optional) built-in event queue has been added to the feature requests list already. We decided not to add that feature in the current major version of µGFX because it would require redesigning many things. Instead, this is something we will be looking into for µGFX 3.0 which we started working on already.

By the way: As @inmarket all the existing components & features have been designed to work well with this very resource friendly solution that µGFX 2 uses. Having a widget that constantly sends events sounds like something that doesn't match the design philosophy of µGFX.

[tubbutec]

Thanks for the great support,

Will try to use a simple event queue side by side with the existing ugfx event system