Statements: idlesignal

The idlesignal statement posts a signal to a slot method.

Syntax

Form 1:

idlesignalslot‑expression;

Form 2:

idlesignalslot‑expression,sender‑expression;

Discussion

The idlesignal statement records the slot method determined by the slot-expression for later invocation. The recorded slot methods are invoked immediately before the next following screen update begins but after all pending user inputs and events have been processed. Thus, unlike its counterpart signal, the idlesignal statement doesn't wait for the slot method completion. If the slot-expression results in the value null, then no slot method is recorded. For example:

var slot s1 = someObject.OnShowMenu;
var slot s2 = null;

// Record slot method 'OnShowMenu' of 'someObject' for later execution
idlesignal s1;

// The expressions results in 'null'. Nothing happens.
idlesignal s2;

Per default, when the slot method is invoked, the identity of the sender object (see this variable) is passed on to the slot method in the hidden parameter sender. Thereupon the implementation of the slot method can evaluate or even interact with the sending object. In its second form, the idlesignal statement allows you to explicitly specify in the sender-expression another object to be passed on instead of the actual sender object, even a null object. It permits the sender to feign a foreign identity against the slot method. For example, you can implement a button able to post signals with the identity of its superior component:

var slot theSlot = ...;

// Send the signal with the identity of the superior GUI component.
idlesignal theSlot, Owner;

All recorded slot methods are invoked strictly in the order, in which the corresponding idlesignal statements have been executed. When trying to record the same slot method twice, the idlesignal statement invalidates (removes) the old entry first before the slot method is newly registered. For example:

// The three slot methods are recorded and will be invoked in the order:
// 'SlotMethod1', 'SlotMethod2' and 'SlotMethod3'.
idlesignal someObject.SlotMethod1;
idlesignal someObject.SlotMethod2;
idlesignal someObject.SlotMethod3;

// With this operation the order changes to:
// 'SlotMethod2', 'SlotMethod3' and 'SlotMethod1'. Moreover, 'SlotMethod1'
// will be invoked with 'Owner' object as the sender. The other methods
// are invoked with 'this' as sender.
idlesignal someObject.SlotMethod1, Owner;

All pending idlesignal statements are ignored by the Garbage Collector. When the Garbage Collector reclaims an object, which is referred by a waiting idlesignal, the idlesignal is discarded. In other words, pending idlesignals can't prevent the involved objects from being reclaimed if these are not used elsewhere. Please note, prior the version 8.20 this behavior was different. In this case pending idlesignals were very well able to maintain the referred objects alive until the signal has been delivered and processed.

Please note, slot methods can be invoked also by using the signal and the postsignal statements.