Usage of signals and the different signal types

Description:

EmWi offers three different types of signals: signal, postsignal and idlesignal. This article gives an overview for the intention, the processing and some practical use-cases of the different signal types.

Solution:

Signals are tailor-made to notify a single object about a certain event or change in the system. Each of the three different signal types can be sent in the Chora code to either a property of type "slot" or to a "slot method" e.g.:

signal     slot-method;

signal     slot-property;

If there is no slot method assigned to a slot property, the signals have no effect – neither a call of a method nor a runtime error occurs. Now let’s have a more detailed look on the different signal types.

1. signal

A signal causes an immediate, synchronous call of a slot method. The hidden argument "sender" in a slot method provides the object of the sender. A typical use-case for a signal is a button who should react immediately on a user input, a slider that immediately changes a value (volume, brightness,…) or a menu item that opens a sub-menu.

2. postsignal

Postsignals are queued in a signal queue. They are executed in the order as they occurred. Multiple postsignals to the same recipient are merged to one single postsignal inserted at the end of the queue. The hidden argument "sender" is always "null" due to the fact that it could be merged from two or more sender. Postsignals are executed with some delay, butalways before the next screen update. As long as a postsignal is pending in the queue, related objects will not be removed by the Garbage Collector. A typical use-case for a postsignal is the optimization (only one call from many merged postsignals instead of many calls from many signals to the same recipient) and to avoid initialization effects due to dependencies on the z-order.

3. idlesignal

The only difference between an idlesignal and a postsignal is the execution time. A postsignal is execuded is after the next screen update if there is no user input. A typical use-case for a idlesignal is to serve time intensive tasks such as JPG decoding or a channel scan in the background. With idlesignals the UI application can respond to the user inputs and the main Software gets enough processing time while the UI task split a time consuming process in multiple small idle steps.

See also:

Keywords:

signal, postsignal, idlesignal, slot, slot property, slot method, optimization