1 Das XCONTROL

XControl ist ein modulares (erweiterbares) Kontrollfeld, das von Atari zuerst mit den Computern der TT und Mega-STE Serie ausgeliefert wurde.

Die einzelnen Module sind Dateien mit der Namenserweiterung '.CPX' (Control-Panel eXtension), und XControl selbst kann als Steuerungsprogramm für diese Module angesehen werden.

Wichtig: XControl sollte nur als Tool für Konfigurationsdialoge angesehen werden, und nicht für andere Zwecke mißbraucht werden.

Die Kommunikation zwischen XControl und seinen Modulen erfolgt über zwei Strukturen, die mit XCPB und CPXINFO bezeichnet werden. Über erstere werden einige Flags sowie eine ganze Reihe von Hilfsfunktionen zugänglich gemacht.

Beim Start lädt XControl alle verfügbaren CPX-Header; sofern im Header ein entsprechendes Flag gesetzt ist, werden alle CPX-Dateien einmal zum initialisieren aufgerufen. Für jedes einzelne Modul kann angegeben werden, ob es resident geladen werden soll (dies kann auch über das mitgelieferte Konfigurations-CPX verändert werden). Darüber hinaus ist es möglich, CPX-Module zu schreiben, die nur bestimmte Werte setzen. Man spricht in diesem Zusammenhang von 'Set-Only'-Modulen, die nur beim Booten bzw. erneuten Laden der CPX-Module durch XControl aufgerufen werden, und bei der Initialisierung einfach einen Nullzeiger zurückliefern.

Sobald ein CPX-Modul vom Anwender ausgewählt wird, lädt XControl dieses in den Speicher, und ruft die Funktion cpx_init auf. Anschließend wird noch cpx_call aufgerufen, wobei im wesentlichen nun das Modul selbst die Steuerung übernimmt.

Man unterscheidet zwischen Form-CPX und Event-CPX. Erstere sind relativ einfach zu programmieren, bieten jedoch nur eine eingeschränkte Flexibilität. Letztere sind flexibler, da sie die AES-Events direkt auswerten. Alle mit XControl 1.0 ausgelieferten CPX-Module sind Form-CPX Dateien, woraus geschlossen werden kann, daß Form-CPX in den meisten Fällen ausreichen.

Für die Dateinamen von CPX-Modulen gilt die folgende Terminologie:

Der Aufbau einer CPX-Datei ist einem normalen Programm sehr ähnlich. Sie besteht aus einem 512 Byte großen Header und dem übrigen Dateiinhalt, bei dem es sich fast um eine normale GEMDOS-Programmdatei handelt. Der Header ist dabei wie folgt definiert:

typedef struct
{
    UWORD magic;                 /* Magic-Konstante = 100   */

    struct
    {
        unsigned reserved : 13;  /* reserviert              */
        unsigned resident :  1;  /* RAM-resident            */
        unsigned bootinit :  1;  /* Boot-Initialisierung    */
        unsigned setonly  :  1;  /* Set-Only                */

    } flags;

    LONG  cpx_id;                /* eindeutige CPX-ID       */
    UWORD cpx_version;           /* CPX-Versionsnummer      */
    BYTE  i_text[14];            /* Icontext                */
    UWORD sm_icon[48];           /* Bitmap (32*24 Pixel)    */
    UWORD i_color;               /* Iconfarbe               */
    BYTE  title_text[18];        /* Name des CPX            */
    UWORD t_color;               /* Textfarbe               */
    BYTE  buffer[64];            /* nicht-flüchtiger Puffer */
    BYTE  reserved[306];         /* reserviert              */

} CPXHEAD;

Zum Header noch einige Anmerkungen:

• die erste Funktion im TEXT-Segment muß die Initialisierungsroutine für die CPX sein
   
• zur Konstruktion eines CPX-Headers gibt es mehrere Toolkits
   
• Header und gelinkte Programmdatei können in den meisten UNIX-ähnlichen Shells (z.B. der Mupfel aus Gemini) mit dem Kommando 'cat' zusammengefügt werden.
   
• bei der CPX-Entwicklung ist es sehr praktisch, daß man XControl auch als Programm starten kann (Suffix ändern !). Dies erlaubt es, ohne permanentes Neu-Booten des Rechners zu arbeiten.
   
• CPX-ID und -Versionsnummer sorgen dafür, daß jede CPX nur ein einziges mal (und auch nur die neueste Version) erscheint.
   

Bei der Programmierung eines CPX-Moduls sind einige Feinheiten zu beachten. Da ein solches Modul (mit Ausnahme von 64 Byte) über keinen nichtvergänglichen Speicher verfügt, ist nichts erlaubt, was Speicher in irgendeiner Form fest reserviert. Insbesondere gehen Variableninhalte mit dem Verlassen der CPX in aller Regel verloren ! Daher sollte man:

• Resourcen statisch einbinden
   
• Speicheranforderungen nur kurzzeitig erlauben
   
• virtuelle VDI-Workstations nicht dauerhaft anlegen
   

Bei der Programmierung eines CPX-Moduls kann auf Funktionen der beiden folgenden Kategorien zurückgegriffen werden:

• CPX-Funktionen
   
• XCONTROL-Funktionen
   

Hinweis: Als Alternative zu XCONTROL, welches von Atari nicht mehr weiterentwickelt wird, bieten sich verschiedene Programme an. Besonders empfehlenswert ist dabei COPS (COntrol Panel Server, mit dessen Hilfe sich nicht nur beliebig viele CPX-Module gleichzeitig öffnen lassen, sondern das auch Kontrollfelder mit größerer Arbeitsfläche als XCONTROL erlaubt.

• 1.1 CPX-Programmierrichtlinien
• 1.2 CPX-Funktionen
• 1.3 XCONTROL-Funktionen

English version not yet available.