With an autoobject member you can define a global instance of a particular class. Usually autoobjects represent the data model of your application or serve as interfaces to the underlying target device. Since they are global, autoobjects can be accessed from everywhere in your project. Please note, an autoobject can exist only within a unit member. Per default, autoobjects are represented in Composer by following bricks:

An autoobject member appears in Composer and Inspector decorated with the icon associated to its class. Autoobjects of different classes can thus be distinguished conveniently. Moreover, the class of the autoobject is shown in the upper text row of the brick:

The brick shows the class of an autoobject and the associated icon.

You create a new autoobject by simply deriving it from an existing class. In the simplest case, if both, the class and the autoobject are defined within the same unit, do following:

Creating a new autoobject by deriving it from a class existing within the same unit.

If the class is not defined within the same unit, you can use the Browser window:

Creating a new autoobject by using the Browser window.

Alternatively, you can create a new autoobject by using the clipboard functions Copy & Paste:

Autoobject members have a global character - they can be accessed from everywhere within your project. To address an autoobject member, you must always use its full name, which is composed of the unit name, the member is defined inside, and the name of the member itself, both separated by :: (double colon) signs. For example Examples::Device.

When the autoobject is selected, you can inspect and modify its properties directly in the Inspector window. In particular, you can specify initial values for every property of the object. An autoobject exposes automatically all properties defined in its class.

If you have modified a property, you can simply revert to its original value (defined in the class of the autoobject) by pressing the keys CtrlR when the property in question is selected in Inspector.

At the runtime Embedded Wizard automatically re-evaluates all initialization expressions, which involve multi-lingual operands. For example, if an autoobject's property is initialized with a localized constant, the initialization expression is re-evaluated and the resulting, eventually different constant value is re-assigned to the property automatically. Thereupon, the onset method associated with the property is executed. See also the section Managing localization.

You can create any number of copies of an already existing autoobject definition.

You can also Drag & Drop an autoobject member from the Browser into the Composer window and create so a duplicate of the affected member:

Duplicating an autoobject by simply Drag & Drop it between the Browser and Composer windows

Every autoobject is represented at the runtime by a global instance of the class, specified in autoobject's Class attribute. As such autoobjects can be involved within Chora expressions wherever an operand of this class is expected. Moreover, the properties exposed by the object can be evaluated and its methods can be invoked. The autoobject itself is identified by its full name, composed of the unit name, the autoobject member is defined inside, and the name of the autoobject member itself, both separated by :: (double colon) signs. Let's assume, your project contains a class Example::DeviceClass and an autoobject of this class named Example::Device, then following code accesses the autoobject:

Autoobjects are global entities. To prevent the system from creating the same object twice, Embedded Wizard maintains all currently existing autoobjects in an internal cache. Multiple accesses to one and the same autoobject result thus in the same instance. For example:

Every autoobject member can be overridden by one or more autoobject variant members. Once overridden, the variant member can retrospectively modify the properties of the original autoobject member. The derivation of variants provides the fundamental technique to manage several product and design variants within one and the same GUI application. The selection of the appropriate variant occurs automatically depending on the condition specified in the VariantCond attribute of the corresponding variant member.

With the attribute Generator you can selectively control, whether the autoobject member should be taken in account during the code generation or not. Configuring this attribute with the value false will exclude the autoobject from your project unless the autoobject is explicitly involved within a Chora expression.

The following table shows the complete list of attributes provided by the autoobject member. Please note, besides the attributes, an autoobject also exposes all properties defined in its class:

Attribute name	Short description
Brick	Determines the position and the size of an autoobject member brick within the Composer window.
Class	Determines the class of an autoobject member.
Description	Contains the description for the autoobject member.
Generator	Controls the code generation for the affected autoobject member.

This section describes the Chora syntax of how autoobjects are stored inside Embedded Wizard project files. The knowledge about the syntax can be helpful when you plan to process the project contents by third party tools. In particular, the general purpose Export and Import functionality introduced in version 14 requires a good understanding of how project members are represented in Chora syntax to correctly interpret the exported members and synthesize the Chora code for members to import. Please note, Embedded Wizard project files (and thus Chora code) are encoded as text in UTF-8 format.

In Chora syntax, autoobject definition is always introduced with the keyword autoobject, followed by the class of the object, its name and a list of initialization values (so-called presets) for autoobject's properties. The presets are enclosed between a pair of curly braces {..}, whereby each preset is initiated by the keyword preset followed by the name of the affected property, an assignment operator =, the assigned value and ; semicolon sign. If the list with presets is omitted, the definition should be terminated by a ; semicolon sign. Wherever necessary, the tokens are separated by whitespace signs. The class name of the object corresponds to the value of the attribute Class.

The definition of an autoobject can be initiated by a comment block providing optional description for the project member. The content of this comment corresponds to the value of the autoobject's attribute Description. Furthermore the directives $rect and $output can be specified providing values for the corresponding attributes Brick and Generator. The following examples demonstrate the described syntax:

Each Chora file (or text exchanged with an external Export and/or Import tool) can be (or even should be) prefixed with $version directive. This directive determines the version number of the included Chora code. For details concerning the syntax of the version please see the chapter $version macro. Furthermore, the code can include a $scope directive followed by a path to a project member acting as the original owner of the corresponding code. That means the members described by the Chora code existed inside the member specified in $scope. In case of an autoobject, $scope would specify the name of the unit the autoobject belongs to.