With a slot method member you can implement the logic to execute when the slot method receives a signal. This approach follows the signal-slot paradigm where two objects communicate without having to take care of each other identity. The slot methods are represented in Composer by following bricks:

Every slot method has a body containing its implementation code. The code is expressed in the platform-independent Chora syntax. Within the code you can evaluate and modify variables, perform calculations, call other methods, etc.

A slot method can be defined within a class or class variant only. If one class is derived from another class, all methods implemented in the ancestor classes are inherited implicitly. In the derived class the inherited methods can be overridden and modified with new implementation.

In order to preserve the clarity, all methods inherited from a base class but not overridden in the actual class are not shown as bricks in the Composer. The Inspector, in turn, shows always the complete list including all inherited members. If you are looking for a particular inherited method, use the Inspector for this purpose. Please note, inherited but not overridden methods are shown in Inspector with gray thin font:

Inherited but not overridden slot methods appear only in the Inspector window. They are shown with thin gray font.

If an inherited method has been overridden, Inspector shows it with dark gray font. Additionally, overridden methods appear as bricks in the Composer window. You can distinguish easily, whether a method is overridden or whether it is new by considering the font color in its brick. New methods are shown with black font. Overridden methods, in turn, with gray font:

Overridden methods appear in Inspector with dark gray font. They are also shown as bricks in Composer, again with gray font.

Adding a new slot method.

Slot methods have a local character - they can be accessed only in context of an instance of the class, in which they are defined. To address a slot method, you use its name. Please note, the name of an inherited slot can't be changed retrospectively in the derived class.

The body of a slot method is edited in the Code Editor window. For this purpose:

In the Code Editor you implement the method by using Chora statements and expressions.

Please note, before you can edit an inherited method, you have to override it first.

Slot methods are invoked in response to signals received from other objects. At the execution time, the identify of the sender object is passed on to the slot method in the hidden parameter sender. In your implementation, you can evaluate this parameter and e.g. distinguish between various sender objects.

Please note the description of postsignal and idlesignal statements regarding the behavior when multiple signals (and thus multiple sender objects) are recorded to one and the same slot method.

You can create any number of copies of an already existing slot method.

In order to provide new implementation for an inherited method, you have to override it explicitly:

Overriding an inherited slot method.

When you override an inherited method, it is often convenient to invoke from the new implementation the inherited version of the method. This can be achieved by calling the pseudo method super(). The pseudo method expects the sender parameter to by passed in its unique argument. For example:

If you want to revert an overridden slot method to its original inherited implementation, delete it simply. Thereupon, its brick disappears from the Composer and the Inspector shows the method name with thin font again.

To send signals to a slot method you use the statements signal, postsignal or idlesignal. A slot method can also be registered as notification observer. In this case the slot method is invoked when the observer is notified.

If the identity of the affected slot method is well known, you can send the signals directly to it by using its name. But usually, you will send the signals indirectly by using a reference to a slot method. For this purpose the data type slot is available. You can, for example, create variables and store there references to slot methods you want to signal later. For example:

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

Please note, inherited methods can't be deleted. However, if a method is overridden you can delete this overriding.

The following table shows the complete list of attributes provided by the slot method member:

Attribute name	Short description
Brick	Determines the position and the size of a slot method brick within the Composer window.
Description	Contains the description for the slot method member.
Generator	Controls the code generation for the affected slot method member.
Native	Specifies the kind of language the corresponding method is implemented in.

This section describes the Chora syntax of how slot methods 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, slot method definition is always introduced with the keyword slot, followed by the name and the body (the implementation) of the method. The body of the method is enclosed between a pair of curly braces {..}. In the implementation of the method the Chora statements are used. Wherever necessary, the tokens are separated by whitespace signs.

The definition of a method can be initiated by a comment block providing optional description for the method. The content of this comment corresponds to the value of the methods's attribute Description. Furthermore the directives $rect and $output can be specified providing values for the corresponding attributes Brick and Generator.

In case of a method inherited from a base class, the method definition is additionally prefixed by the keyword inherited. In this case the method inherits the value for the $output directive from the base class. Modifying this value in the inherited method is not foreseen. 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 a method, $scope would specify the name of the class the method belongs to.