(Teil 1)

1. Voraussetzungen

1.1 Hardware
In fast allen zum SDK erschienenen Berichten und im Handbuch selber wird als Voraussetzung der Einsatz zweier Rechner genannt, die über ein Nullmodemkabel seriell miteinander verbunden sind. Am Anfang ist das aber überhaupt nicht notwendig, sondern erschwert den Einstieg nur noch.
Ein PC reicht also erst einmal, ein 486er sollte es aber schon sein, da sonst das Compilieren (Übersetzen in ein lauffähiges Programm) zu lange dauert und man dann schnell die Lust verliert.

1.2 Software
Neben dem SDK (möglichst ab Version 2.0) ist ein Borland C++ - Compiler ab Version 3.1 Voraussetzung. Beides kann auf beliebige Partitionen der Festplatte installiert werden.
In der Autoexec.bat muß aber jeweils der entsprechende Pfad gelegt werden. Bei mir liegt beides auf der Partition G. Daher steht unter path folgendes:

   path ....;g:\borlandc\bin;g:\pcgeos\bin;...

Außerdem muß noch eine Systemvariable gesetzt werden:

   set ROOT_DIR=g:\pcgeos

Um die Programmtexte bearbeiten zu können, muß natürlich ein Editor vorhanden sein. Ich persönlich benutze den DOS 7.0 Editor, weil man dort mehrere Texte gleichzeitig im Editor und geteilten Fenstern griffbereit haben kann. Die Wahl des Editors ist aber Geschmacksache.

2. Vorüberlegungen

Ein Einsteigerkurs zur SDK-Programmierung kann sicher keine einfachen Rezepte bieten, mit denen man sofort in die Lage versetzt wird, die gewünschten Projekte zu verwirklichen. Schon bei den einfachsten Beispielprogrammen wächst die Komplexität schnell über den Kopf, insbesondere wenn man vorher noch nicht viel von der objektorientierten Programmierung (OOP) gehört hat. Dazu benutzt das SDK eine eigene Programmiersprache (GOC, alle GOC-eigenen Sprachelemente beginnen mit @), die wiederum C (nicht C++) beinhaltet. Egal, ob man von Basic oder Pascal her kommt, die benutzten Sprachelemente von C hat man schnell raus. Wenn dann allerdings später Sprachelemente wie Strukturen und Zeiger benutzt werden, kommt man um ein Lehrbuch für C nicht herum. Die größten Schwierigkeiten haben zumindest mir das Verstehen der Objekt-Gefüge und die Zusammenhänge mit den Messages und Methoden bereitet. Ein Versuch des linearen Lesens des Handbuchs hat mir (zu Anfang) nichts gebracht. Erfolgreicher war dann schon das Experimentiern mit den Beispielprogrammen "Hello", "Hello2" und "Hello3".

3. Übersetzen und Starten eines im SDK enthaltenen Beispielprogramms

Bei der Installation des SDK wird ein Verzeichnis namens pcgeos erzeugt. Im Unterverzeichnis pcgeos\appl\sdk_c steht eine Reihe von Beispielprogrammen zur Verfügung, die jeweils eine eigene Facette der Programmiermöglichkeiten vorstellen. Wie in den Beispielen, die üblicherweise in jeder Programmiersprache mitgeliefert werden, ist auch hier ein Programm (hello) dabei, das nichts anderes tun soll als einen Text (hier: "The quick brown fox ...") auf den Bildschirm zu schreiben.
In dem Verzeichnis hello sind zwei Dateien enthalten: hello.goc und hello.gp.
Der eigentliche Programmtext ist in der goc-Datei enthalten, währen die gp-Datei Informationen für den Compiler bereithält, z. B. die Struktur der Programmresourcen (dazu in den nächsten Folgen mehr), der Name Programms im Programmmanager, das Icon und noch einiges mehr.

Um ein lauffähiges Programm namens "helloec.geo" (Übersetzte Programme haben die Endung geo .) zu erzeugen, geht man erstmal in die Dos-Kommando-Zeile. Am Dos-Prompt hangelt man sich bis zum Hello-Verzeichnis vor.

   Also:         g:>cd g:\pcgeos\appl\sdk_C\hello>

An diesem Prompt werden jetzt nacheinander drei Befehle eingegeben, deren Bedeutung ich an dieser Stelle noch nicht erklären möchte:

g:\pcgeos\appl\sdk_C\hello>mkmf             [enter]

g:\pcgeos\appl\sdk_C\hello>pmake depend     [enter]

g:\pcgeos\appl\sdk_C\hello>pmake            [enter]

Jeweils nach pmake depend und pmake werden scheinbar kryptische Zeichenfolgen und zum Schluß noch eine kleine Statistik angezeigt (nachzulesen im Handbuch, Tutorial S.17/18/19). Wenn keine Error-Meldungen aufgetreten sind (sollten eigentlich nicht, da hello.goc bisher nicht verändert wurde), dann steht im Hello-Verzeichnis jetzt die fertige Applikation (helloec.geo) und kann vom GeoManager aus gestartet werden. Es sind zwar noch einige andere Dateien hinzugekommen, aber diese sind nur für den Compiler wichtig.

4. Das Hello-Programm

4.1 Was leistet "C Hello Sample Application"?
Bevor wir mit der Programmierung beginnen, schauen wir uns am besten erst mal das vorherige Ergebnis an. In einem ansonsten leeren Fenster wird der leicht gedrehte Text angezeigt. Das Fensterinhalt ist scrollbar, also größer als der Bildschirm.

Die Menüzeile enthält nur den Punkt Datei, der wiederum nur den Programmausstieg ermöglicht. Die oberste Zeile enthält bis auf das Hilfezeichen alle von anderen Programmen bekannten Elemente. Menü- und Titelzeile werden in dieser Minimalform stets automatisch angelegt, ohne dass der Programmierer sich darum kümmern muß.

Das Hauptfenster, das alles sichtbare beinhaltet, wird Primary genannt. Darin enthalten ist ein weiteres Fenster, der View. Im View wird der Text angezeigt. Die Scroll-Balken sind ein Teil des Views.
Eine Fähigkeit hat das Programm zusätzlich: Es kann im Progarmmmanager sein Icon und seinen Namen zeigen Das ist übrigens Voraussetzung für alle Applikationen).

4.2 Ein erster Blick auf den Programmtext
Der Programmtext ist reichlich mit Kommentaren versehen, die zum Verständnis zwar sehr hilfreich sind, die aber die Übersicht nicht gerade erleichtern. Am besten, man druckt sich das gesamte File einmal aus. Kommentare werden durch /*...*/ ausgeklammert.

Ich habe nicht die Absicht und auch nicht den Platz, an dieser Stelle eine Einführung in die objektorientierte Programmierung zu starten, obwohl einige Grundkenntnisse ganz nützlich wären. Vielleicht aber doch ein paar Sätze, da wir um die Betrachtung von Objekten nicht herumkommen:
Wer sich mit der Deklaration von Variablen auskennt, weiß, daß diese stets von einem definierten Datentyp sein müssen. Diesen Typ könnte man auch Klasse nennen. Von dieser Klasse können beliebig viele Variablen deklariert werden, die sich nur im Namen unterscheiden, aber die gleichen Eigenschaften besitzen. Ein anschauliches Beispiel "aus dem täglichen Leben": Autos werden definiert als Pkw oder Lkw wegen der unterschiedlichen Eigenschaften. Ein produzierter VW-Käfer entspricht dann der deklarierten Variablen mit einem eindeutigen Namen von der Klasse Pkw. Alle Variablen der Klasse Pkw haben aber nicht nur Eigenschaften wie Länge, Breite, Leistung etc, sondern sie können auch fahren, bremsen, blinken usw. Damit haben wir einen der wichtigsten Unterschiede zur normalen Variablen. In dem Datentyp oder der Klasse Pkw sind eben nicht nur Datenformate sondern auch Tätigkeiten enthalten. Daher nennt man den Käfer nicht mehr Variable sondern Objekt der Klasse Pkw. Betrachtet man die Welt aus dieser Richtung, sieht man, dass man alles als Objekt betrachten und jeweils einer definierten Klasse zuordnen kann.

Die möglichen Tätigkeiten eines Objekts sind in der Klasse in sogenannten Methoden definiert. Methoden sind im Prinzip nichts anderes als Prozeduren. Sie haben einen Namen, unter dem sie aufgerufen werden können, um die in C programmierte Tätigkeit auszuführen.

Geosprogramme bestehen ausschließlich aus Objekten. Es gibt eine feste Rangordnung (Hierarchie), die bei der Erstellung der Objekte (Erzeugung der Instanzen) beachtet werden muß, die aber zum großen Teil selbst gestaltet werden kann.

Gehen wir die wesentlichen Elemente des Programmtextes durch:

Zuerst wird der Code einer anderen Datei eingefügt (@include), als hätte man ihn direkt über die Tastatur eingegeben. Dadurch wird zusätzliche Funktionalität zur Verfügung gstellt wie z. B. die Nutzung von Grafik-Befehlen. Ein für C typisches Programmierkonzept. Für alle Geos-Applikationen ist das Einfügen von stdapp.goh Voraussetzung.

   Objekte

Mit @class HelloProcess Class wird die für diese Application zuständige Klasse definiert (abgeleitet von der allgemeineren Klasse GenProcessClass). Beim Start der Applikation wird automatisch ein Objekt dieser Klasse erzeugt, das alle Vorgänge überwacht (Öffnen oder Schließen des Views, Aufrufen der Methoden und vieles mehr).

Das in der Hierarchie ganz oben stehende Objekt ist HelloApp von der Klasse GenApplicationClass. Dieses Objekt ist zuständig für die Kommunikation mit dem Programmmanager wie oben schon beschrieben (Icon, Name etc.). Daher wird es auch in einer eigenen Resource gehalten (Zu erkennen an der Klammerung mit @start ... @end). Resourcen sind ein für Geos typisches Programmier- bzw Speicherkonzept. Geos-Programme kommen nur deshalb mit 640K Hauptspeicher aus, weil über einen ausgeklügelten Speichermanager jeweils nur die für die momentanen Aktionen zuständigen Resourcen (Programmteile) im Speicher gehalten werden.

GI_visMoniker ist eine objekteigene Variable, die den Programmnamen in der Titelzeile enthält.

Die nächste Variable ist zuständig für die Objekthierarchie. Unter GI_comp werden stets alle direkt untergeordneten Objektnamen (Kinder) mit jeweils vorangestelltem @ aufgelistet, hier also das schon erwähnte Primery-Fenster.

Das Objekt HelloPrimery enthält nur @HelloView (das Fenster, in dem gezeichnet bzw. geschrieben wird) als nachgeordnetes Objekt.

Das HelloView-Objekt enthält mehrere Angaben: Zunächst wird die Scrollbarkeit näher spezifiziert. Dann wird erklärt, daß das Process-Objekt für die Steuerung des Fensterinhalts zuständig ist. Die Grenzen des Dokuments sind mit 1000 x 1000 Pixeln größer als die des Fensters. Primery und View sind in einer eigenen Resource. Bei der Gelegenheit: Die Aufteilung in Resourcen wird dem Compiler über die Hello.gp - Datei mitgeteilt.

   Methoden und Funktionen

MSG_META_EXPOSED ist der Name der einzigen hier aufgeführten Methode. Sie wird aufgerufen, wenn ein Teil des im View dargestellten Inhalts ungültig geworden ist, z.B. durch Scrollen. Diese Methode wird also vom View-Objekt aufgerufen, das heißt, der View schickt eine Message namens MSG_META_EXPOSED an das Process-Objekt. Die Methode (Prozedur) selbst wird Handler der Message genannt. Allgemein gilt: Jedes Objekt, das eine Message empfangen können will, muß auch einen Handler speziell zur Verarbeitung der Message haben, sonst wird die Nachrichricht vom System an untergeordnete Objekte weitergereicht. Kann kein Objekt mit der Nachricht etwas anfangen, wird sie verworfen und bleibt wirkungslos.

MSG_META_EXPOSED zeichnet bei jedem Scroll-Vorgang den aktuellen Inhalt des Views neu. Das eigentliche Zeichnen bewirkt der Aufruf der Funktion HelloDraw(gstate). In dieser Funktion stehen die Grafik-Befehle, die zur Ausgabe des leicht schräggestellten Textes führen. Mit #define werden Konstanten für Schriftgröße (TEXT_POINT_SIZE), Rotationswinkel (TEXT_ROTATION) und Ausgabeposition (TEXT_X_POSITION TEXT_Y_POSITON) definiert. Mit den dann folgenden 3 Grafik-Befehlen werden die Eigenschaften des auszugebenden Textes festgelegt und mit GrDrawText der Text schließlich gezeichnet (!). Dabei entsteht kein Textobjekt, das man anklicken und verschieben kann.

5. Erweiterung des Hello-Programms

5.1 Erste Eigene Übungen
Will man erste eigene Versuche unternehmen, bietet es sich an, z. B. mit der Veränderung der Konstanten in der Funktion HelloDraw zu beginnen. Oder man fügt weitere GrDrawText-Zeilen hinzu oder man ändert die View-Größe. Auf jeden Fall wird man auf diese Weise langsam mit dem gesamten Programmtext vertraut.

5.2 Neue Objekte
Aber ich möchte in dieser Kursfolge auch noch neue Elemente anbieten. Das Ziel:

Auf Wunsch soll in einem Extra-Fenster die aktuelle Mausposition angezeigt werden.

Dazu brauchen wir in der Menüzeile einen neuen Menüpunkt, der aufgeklappt den Button zur Auslösung der gewünschten Anzeige enthält. Dieser Menü-Button muß vom Typ GenInteractionClass sein, da er ein untergeordnetes Objekt enthält, das wiederum Objekte enthalten wird, nämlich die beiden Mauskoordinatenanzeigen. Im Gegensatz zum Interaction-Objekt kann ein Objekt vom Typ GenTriggerClass nämlich keine Kinder haben. Der Menü-Button muß ein Kind des Primery-Objekts sein und noch vor dem View-Objekt aufgelistet werden, damit er in der Menüzeile auftaucht und nicht unterhalb des Views. Außerdem muß er aufklappbar und festzupinnen (typisch für Menüpunkte) sein.

@objekt GenPrimeryClass HelloPrimery = {
                GI_comp=@HelloOptionMenu,@HelloView;
                .
                .
        }

Diese neue Objekt wird anschließend deklariert:

@object GenInteractionClass HelloOptionMenu = {
        GI_visMoniker="Mausposition";    /* Button-Beschriftung */
        GI_comp=@HelloMausPosition;
/* der Button im Menü, der die Anzeige auslöst */
        GII_visibility = GIV_POPUP;    /* Menüpunkt aufklappbar */
        }

Der Button im Menü wird deklariert:

@object GenInteractionClass HelloMausPosition = {
        GI_comp=@MausPositionX,@MausPositionY
/* die beiden Koordinatenanzeigen */
        GII_visibility=GIV_DIALOG;     /* Fenster bleibt stationär */
        HINT_ORIENT_CHILDREN_HORIZONTALLY;
/* Koordinaten-Objekte horizontal nebeneinander */
        }

Hints wie im letzten Objekt gibt es sehr zahlreich. Mit diesen Anweisungen sind geometrische Anordnungen der Objekte fast beliebig möglich (nachzulesen in Concepts, Kap.12, Managing UI Geometry).
Um die x- und y-Position des Mauszeigers anzuzeigen, eignen sich am besten Objekte der Klasse GenValueClass. Über Value-Objekte erfolgen in der Regel Zahleneingaben des Anwenders, aber sie lassen sich auch als Anzeigeobjekte (meist für Zahlen) benutzen. Diese Objekte werden wie folgt deklariert:

@object GenValueClass MausPositionX = {
        GI_visMoniker = "x=";
        GVLI_displayFormat = GVDF_INTEGER;
/* Statt INTEGER kann mit MILLIMETERS der Wert
bereits umgerechnet in Millimeter angezeigt werden. */
        GVI_value=MakeWWFixed(0);
/* der Vorgabewert der Anzeige, WWFixed ist
ein Geos-eigenes Zahlenformat */
        HINT_VALUE_DIGITAL_DISPLAY;
/* Digitalanzeige statt eines Schiebereglers (ANALOG_DISPLAY) */
        HINT_VALUE_NOT DIGITALLY_EDITABLE;
/* In der Anzeige soll keine Eingabe mit der Maus möglich sein */
        }

Das gleiche muß noch einmal für das MausPositionY - Objekt geschrieben werden.

Die benötigten Objekte sind damit vollständig deklariert. Jetzt muß nur noch dafür gesorgt werden, daß die aktuellen Mauskoordinaten kontnuierlich abgefragt und zur Anzeige geschickt werden.

Bei jeder Mausbewegung generiert Geos selbst eine Message namens MSG_META_PTR und schickt diese zum process-Objekt. Unter anderen werden dabei die Daten für die aktuelle Mausposition mit übergeben. Wir verändern die entsprechend im System schon vorhandene Methode für unsere Zwecke (und schreiben sie an das Ende des Programmtextes) :

@method HelloProcessClass, MSG_META_PTR
        {
        @send MausPositionX::MSG_GEN_VALUE_SET_VALUE
        (MakeWWFixed (xPosition),0);
/* alles nach dem @ ist EINE Zeile, ohne Leerzeichen! */
        @send MausPositionY::MSG_GEN_VALUE_SET_VALUE
        (MakeWWFixed (yPosition),0);
/* alles nach dem @ ist EINE Zeile, ohne Leerzeichen! */
        @callsuper();
}

Die Message übergibt die Mauskoordinaten in den Variablen xPosition und yPosition.
Die GenValueClass hat einen Handler für Messages, die den anzuzeigenden Wert übergeben wollen: MSG_GEN_VALUE_SET_VALUE. Der Wert muß aber im Format WWFixedAsDWord übergeben werden. Da die von der Maus kommenden Daten im word-Format sind, muß darauf die Umwandlungsfunktion MakeWWFixed () angewendet werden. Genaueres kann im Objekt-Kapitel des Handbuchs (GenValue) nachgelesen werden. Diese Message muß nun also jeweils an das entsprechende Anzeige-Objekt geschickt werden Da unsere Methode ja schon existierte und vielleicht Eigenschaften hatte, die wir hier jetzt nicht berücksichtigen, müssen wir die ursprüngliche Methode mit @callsuper aufrufen. Unsere Methode führt damit die beiden @send-Befehle aus und verhält sich sonst so wie vorher.

Damit ist unsere kleine Programmerweiterung fertig, kann compiliert und ausprobiert werden. Wahrscheinlich wird der Compiler mit Fehlermeldungen abbrechen, GOC unterscheidet nämlich ganz penible zwischen Groß- und Kleinschreibung. Ist die Syntax an einer Stelle nicht korrekt, gibt es oft eine ganze Reihe von Fehlermeldungen, durch die man sich nicht abschrecken lassen sollte. Das sind meist alles Folgefehler, die nach erfolgreicher Korrektur des ersten Fehlers verschwinden.

Und nun viel Spaß beim Üben, Verändern und Erweitern!

Kritik, Fragen und Korrekturen nehme ich gern entgegen unter (siehe Autoreninfo)

Wilfried Konczynski