Hello Marco,
the Order affects the order in which the members of the component are evaluated during editing of components and during code generation. If the data member Property1 has lower order than data member Property2, then Property1 will appear first as data member in the generated code (e.g. in the structure definitions). Similarly, if the method OnSetProperty1 has a lower order than OnSetProperty2, OnSetProperty2 will be generated after (below) OnSetProperty1.
When data members existing within a component are initialized, this initialization is also performed according to the order of the members. For example, if you have two embedded objects, Text and Data, then by changing the order of the members you can ensure that Data is initialized before or after Text.
When I run the prototyper first the GUI Component is created and then its properties are initialized.
Is it possible to program the order of initialization of those properties?
You refer to the initialization of properties of an embedded object. This part is not explicitly specified. Actually, the initialization order of the properties corresponds to the order in which the properties appear in the implementation of the embedded component. However, when the order of the members within the embedded component is changed retrospectively, the order of already existing initializations does not change anymore.
To explicitly control the order you will need to implement the initialization as assignments inside the Init method of the superior component. The best approach, however is to implement the components so that they don't depend on the initialization order of their properties. For example, the Mosaic view Text contains properties for String and Font. Changing one of the properties affects the layout and the appearance of the view.
This update is time intensive and requires the string to be reprocessed and eventually broken in several rows. To avoid that initialization of the both properties causes the view to perform the update twice, the view stores the new string and the new font but delays the update. This is achieved by using a postsignal. In this manner the implementation can modify the properties multiple times, in any order - the resulting update is performed only once and produces exact the same results.
If you are interested in such 'accumulated' uopdates within your own component, you don't necessarily use the postsignal. Components provide a generic approach to perform such accumulated updates. See the methods UpdateViewState() and InvalidateViewState(). See also Managing component state.
Best regards
Paul Banach