I suppose you refer to the properties existing in Mosaic classes, for example, the property Color of the Filled Rectangle view. In such case, the update is triggered only, when the value will change. Assigning the value already stored in the property is ignored in such case. For this purpose the onset method associated to the property contains following (or similar) condition at its very beginning:
// The color does not change -> Nothing to do.
if ( value == pure Color )
Please note, that changing a property belonging to a view does not execute the update immediately. Instead, the screen area affected by the alternation is recorded internally. The real screen update is performed later when the application has finalized all operations. This approach permits multiple property alternations to be accumulated and optimizes the screen update significantly.
In turn, if you refer to your own implemented properties (not the properties belonging to Mosaic views as explained above), the behavior depends on whatever you have implemented in the onset method associated to the property. Generally, every time a value is assigned to a property, its associated onset method is invoked. In the implementation of the onset method you can decide how to handle the assignment operation - you can perform some update even if the same value is assiged twice in such case.
I hope it helps you further.
you usually don't need to know when the update is performed. If you have 60 lines and in your implementation you update their visibility state (e.g. within a loop iterating over the 60 lines) the resulting update will not interfere with your implementation.
The above mentioned 'real screen update' is triggered when your implementation has finalized all operations and there is some screen area affected by the operations and requiring the update. From technical point of view, Embedded Wizard drives the application in a loop performing following steps (as pseudo code):
for ( ;; )
if ( AnyScreenAreaToUpdate())
In your case, the logic changing the visibility state of the 60 lines is executed in response to either a user event (touch or keyboard), an event received from the device, an expired timer or a pending signal. In any case, this logic is finalized before the screen update is performed. Or, in other words, the screen update is not performed if there are other events pending for execution.
See also: Platform Integration Aspects: Main Loop.
Does it help you further?
Ask Embedded Wizard
Welcome to the question and answer site for Embedded Wizard users and UI developers.
Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!