Initialisation hierarchy with Class-Variants

Question

Hi,

i have got following initialisation hierarchy:

Base-Application -> Base-Screen -> Widget -> Derived-Screen -> Widget -> Derived-Application

Now i am wondering why der Derived-Application is called after the Derived-Screen is called. The Derived-Screens Variant-Condition is the Derived-Application.

How is it possible that a class is called before its condition is initialised? How do i get this problem fixed? It is necessary that the corresponding application is initialised before the widget.

Kind Regards

Jonas

Answer 1

Hello JK,

I don't understand your question. Is Deriver-Application a variant of Base-Application? Is Widget an instance within a Base-Screen?

How is it possible that a class is called before its condition is initialised? How do i get this problem fixed? It is necessary that the corresponding application is initialised before the widget.

The initialization order follows strictly the inheritance and aggregation hierarchy. Can you explain more in detail, what problem do you observe?

Best regards

Paul Banach

Comments

Hi Paul,

Is Deriver-Application a variant of Base-Application?

Yes

Is Widget an instance within a Base-Screen?

Yes

In my expection the initialisation hierarchy should be following:

Base-Application -> Base-Screen -> Widget -> Derived-Application -> Derived-Screen -> Widget

 

However the actual initialisation hierarchy is this:

Base-Application -> Base-Screen -> Widget -> Derived-Screen -> Widget -> Derived-Application

 

The variant condition of the derived screen is the derived application. How can the derived screen be initialised before the derived application? 

---

Hi JK,

Base-Application -> Base-Screen -> Widget -> Derived-Application -> Derived-Screen -> Widget

It is still not clear for me how to interpret this hierarchy. Does Base-Screen descend from Base-Application, or is it an object embedded inside it?

if Base-Screen is embedded within Base-Application, the resulting initialization order is correct. In this case, the Base-Application first completes its own initialization before the next descending class, in this case the variant Derived-Application performs its initialization.

In Chora the base class is always initialized before continuing with a variant of the class. Then the next descending class is initialized. If a class (or variant) does contain embedded objects, the embedded objects are initialized before the class (or the variant) itself finalizes its own initialization by invoking Init().

Best regards

Paul

---

Hi Paul,

For my application it is important that the application is initialized before the embedded variant classes, no matter if it is a base or derived application.

As I understood you, this is not realizable in the Embedded Wizard?!

---

Hi JK,

it is important that the application is initialized before the embedded variant classes

if I understood your question correctly, this would result in (temporarily ?) not initialised data members of the embedded objects. For safety reasons the initialisation order in Embedded Wizard does not permit such situations. The initialisation is performed strictly according to the inheritance and aggregation hierarchy. Skipping over initialisation steps is not possible.

Possibly following redesign of your application would help?

1. Assuming the problem is caused by Base-Screen being an embedded object within the Application component and you want the Application component to complete the initialisation of its variant before the Base-Screen is initialised.

2. In such case, remove Base-Screen from the Application component.

3. Create a new class descending from the Application component, e.g. Application2.

4. Embed Base-Screen in Application2.

5. In Profile use Application2 as ApplicationClass.

Now, Application2 and its embedded Base-Screen are initialised after Application component and its variant has finalised the initialisation.

Well, I don't know whether the above approach corresponds to what you are looking for. For me it is still unclear what you try to achieve and how to interpret the above demonstrated hierarchy. If it does not help, can you explain more in detail your application case?

Best regards

Paul Banach