Module Coordinator-Base – step 0031 – February 2010

1 Purpose of SrrModCoord

SrrModCoord coordinates activities of the SRR Framework within one module. Each module instantiates and initializes exactly one instance of SrrModCoord (in each scene instance).

SrrModCoord announces the module at SrrControl, waits for successful registration and afterwards forwards/collects relevant events to/from all SRR objects within the module.

SrrModCoord provides the user interface for the module’s main file (interface uiMod, which is described in this document).

2 User Interface of SrrModCoord (uiMod)

SrrModCoord is an external prototype, available in the directory srr/.

</ProtoInterface>

The fields of the user interface can be arranged according to the following categories:

x) Initialization, Session Handling

When SrrControl issues the commParam event (after initialization, only once), the frame forwards the event to all modules (see the description of the required minimum interface miMod(Module)).

Each module itself forwards the commParam event to its module coordinator which in turn announces the module at SrrControl (if moduleName has been set, too).

After successful registration, the module parameters are issued in the modParam event, which is forwarded by the user (module) to all SRR objects and static models in the module as a trigger for initialization.

If the value of the field modParam.moduleIx is less than 0, this indicates unsuccessful initialization or de-registration, otherwise this field can be used as an index into all module related arrays of the Common Parameters (see SrrControl).

x) Tracer

The trace level of the modules is set at the uiControl interface (see SrrControl.x3d). The SRR Controller forwards the information to all module coordinators via the common parameters commParam.

The module coordinators derive their integer trace level from the SFString definition of all trace levels. Additionally, they output their current trace level in the localTraceLevel field to allow the custom module to adjust their trace level to the trace level of the module coordinator.

x) Communication State (Central Controller, Roles, Module Activation)

The module can request its own activation with the activateRequest event and its own deactivation with the deactivateRequest event(the latter one currently not implemented).

This request may be done any time. If it is done before successful registration, SrrModCoord will store the request and process it afterwards.

The result is indicated in the activated output event. The activated event contains a bit field that indicates changes in the state of the module. activated can also fire an event, when the state of the module changes because of an external reason.

activated & 1: this scene instance became MOC for this module (and was not MOC before)

activated & 2: this scene instance lost the MOC role for this module (and was MOC before)

activated & 4: this module has been activated in this scene instance on own request

activated & 8: this module has been activated in this scene instance on external request (frame/main file requested activation at SrrControl)

activated & 32: this module has been deactivated in this scene instance on external request (frame/main file requested deactivation at SrrControl)

x) Modularity of the SRR Framework

The module controller has the possibility to be extended by optional modules.

The base module can be extended via the srrModCoordModules field, that holds references to all used extension modules (see e.g. SrrModCoordTm).

This field must be set before initialization.