| Commodities |

Commodities - Technischer Hintergrund

Die mit der Betriebssystemversion 2.0 eingeführten Commodities Exchange Funktionen sind die Grundlage für die auf dem Amiga gleichfalls nützlichen und beliebten Commodities, welche einen der vielen Gründe darstellen, warum sich unsere Rechner gegenüber anderen System so flexibel und anpassungsfähig darstellen.

Dabei ermöglichen Commodities nicht einmal etwas grundlegend neues, was nicht auch schon unter den älteren Betriebssystemversionen 1.2 und 1.3 möglich gewesen wäre. Es handelt sich nämlich um Programme, die auf sogenannte Input-Events reagieren. Diese Input-Events werden vom input.device des Betriebssystems generiert, welches bei fast allen Benutzereingaben seine Hand im Spiel hat. Sie stellen eine Konzentration von Tastatur-, Maus- und anderen Ereignissen dar und werden vom input.device nacheinander an verschiedene Input-Handler weitergeleitet. Standardmäßig haben z.B. Intuition und das console.device hier Input-Handler eingehängt, damit sie diese Ereignisse mitbekommen. Jedoch ist es schon seit jeher möglich, eigene Input-Handler zu installieren und damit ebenfalls über die Benutzeraktionen informiert zu sein. Außerdem können solche Input-Handler selbst Input-Events generieren oder welche verändern. Damit war grundsätzlich alles möglich, was heute mit den Commodities gemacht wird. Jedoch zeigte sich, daß die Input-Handler einerseits schwierig zu schreiben waren und sie sich andererseits leicht gegenseitig stören konnten oder die Reihenfolge, in welcher diese aktiviert werden, entscheidend ist.

Um diesen Umstand zu beseitigen, wurde damals von Commodore die Commodities Exchange Library entwickelt, welche Funktionen bereitstellt, die es ermöglichen, daß sich eine Vielzahl von Programmen, sog. Commodities, geordnet in den Input-Strom einhängen können, ohne sich gegenseitig zu stören. Dazu wurde auch das Commodity-Exchange-Programm entwickelt, welches sich im Verzeichnis Tools/Commodities der Systemplatte befindet und mit dem die aktivierten Commodities kontrolliert werden können.

Die commodities.library hängt selbst einen Input-Handler noch vor dem Input-Handler von Intuition beim input.device ein, um alle Input-Events mitzubekommen. Der Benutzer dieser Library, also der Autor eines Commodity-Programms braucht jetzt jedoch nicht mehr direkt einen Input-Handler zu schreiben, sondern verwendet sogenannte Commodity Exchange Objects, im weiteren kurz als CxObjects bezeichnet. Wenn der Input-Handler der commodity.library Input-Events empfängt, dann erzeugt er zugehörige CxMessages (Commodity Exchange Messages) welche er an das Nezwerk von CxObjects weiterleitet.

Derzeit gibt es sieben verschiedene Arten von CxObjects, wovon jede eine andere Art der Behandlung von CxMessages durchführt:

CxObject-Typ	Verwendung
Broker	Zum Anmelden eines Commodity zum Commodity-Netzwerk
Filter	Akzeptiert oder verwirft Input-Events
Sender	Sendet eine Message an einen Message-Port
Translate	Ersetzt ein Input-Event durch ein anderes
Signal	Signalisiert einen Task
Custom	Ruft eine benutzerspezifizierte Funktion auf
Debug	Schreibt Debug-Ausgaben über die serielle Schnittstelle

Diese CxObjects werden zu Bäumen zusammengehängt, um das Verhalten zu definieren. Dabei können einem CxObject andere zugeordnet werden, welche alle CxMessages, die vom übergeordneten Objekt nicht eliminiert wurden, nacheinander empfangen.

Mit dem Broker-Objekt zapft man den Strom der CxMessages an und wird auch über das Commodity-Exchange-Programm steuerbar. Andere CxObjectes werden dann zum Broker hinzugefügt. Üblicherweise hängt man ein Filter-Object hinzu, um die Events, auf die man reagieren will, herauszufiltern und alle anderen unberücksichtigt zu lassen. Das Filter-Object läßt dann nur mehr diese CxMessages, welche den Filterbedingungen genügen, durch. Das bedeutet, alle CxObjects, welche beim Filter-Object eingehängt werden, erhalten nur die gefilterten CxMessages. Dies ist wichtig, da die anderen CxObjects ihre Aktion unabhängig von der einlangenden CxMessage durchführen.

Ein üblicher Vorgang um z.B. auf eine Tastenkombination zu reagieren kann durch folgende Objektstruktur erreicht werden:

Man erzeugt ein Broker-Objekt, in welches man ein Filter-Objekt einhängt. Dem Filter-Objekt gibt man die Tastenkombination, auf die man reagieren will, als Filterbedingung mit. In dieses Filter-Objekt hängt man dann ein Sender-Objekt, welches eine Nachricht bezüglich der eingelangten CxMessage an einen von uns anzugebenden Message-Port schickt. Dies ist üblicherweise ein Message-Port unseres Commodity-Programms. Wenn die Message dort ankommt, dann führen wir die mit der Tastenkombination verknüpfte Aktion aus.

Damit die ursprüngliche Intuition-Message, welche der Tastenkombination entspricht, eliminiert wird, hängen wir auch noch ein Translate-Objekt ans Ende der Objektliste unseres Filter-Objektes ein. Mit so einem Translate-Objekt kann man Input-Events verändern aber, was für unseren Fall interessant ist, auch eliminieren.

In diesem Beispiel wird die eigentliche Arbeit nicht von den CxObjects gemacht, sondern von unserem Commodity-Programm aufgrund der Messages, die uns vom Sender-Object geschickt werden.

So viel zum grundlegenden technischen Aufbau von Commodities.

Thomas Öllinger ...........

....