Sprechen Sie GEM? Anwendungsprogrammierung mit GFA-Basic, Teil 4

GFA-Basic ist nach wie vor eine der beliebtesten Programmiersprachen auf Atari-Plattformen. Vollprofi Holger Herzog führt Sie in die Anwendungsprogrammierung unter GEM ein.

Viele Leser werden sich an die Zeit zurückerinnern, in der kaum eine programmierte Benutzeroberfläche der anderen glich. Zwar geht heute der Trend wieder in Richtung der individuellen Oberflächengestaltung (ein poppiger Fenster-Skin ist bereits selbstverständlich), dies bewegt sich aber eher auf der künstlerischen Ebene und verlässt nicht einen äußeren Rahmen: die sogenannten Richtlinien zur Oberflächengestaltung.

In der heutigen Zeit erwarten die Benutzer also von Anwendungssoftware, dass sich das jeweilige Programm konform präsentiert. Doch auch aus Sicht des Programmierers kann man hieraus einen nicht geringen Vorteil ziehen: die Verwaltung der Benutzerschnittstelle als recht großer Teil der jeweiligen Programme kann zu einem erheblichen Anteil allgemein realisiert werden. Ist dieser Teil einmal umgesetzt, kann auf ihn bei der Erstellung jeder neuen Anwendung wieder zurückgegriffen werden, was den Aufwand bisweilen erheblich einschränkt. Der Application-Builder faceVALUE [1] stellt genau einen solchen „Baustein" dar. Dieser Kursteil soll daher das benötigte Wissen vermitteln, um die von faceVALUE zur Abwicklung des Benutzerdialoges bereitgestellten Funktionen nutzen zu können. Es wird sich zeigen, dass mit faceVALUE Benutzerdialoge mit wenigen Befehlen zu handhaben sind.

Abgrenzung der Problemgebiete

Der allgemeine Aufbau des Systems aus Anwendung und Anwender ist in Abbildung 1 dargestellt. Nicht gezeigt sind hierbei nun eventuelle Kommunikationskanäle der aktuellen Applikation zu anderen Anwendungsprogrammen. Hier soll die Aufmerksamkeit nämlich auf die Benutzerschnittstelle gerichtet werden, die zu diesem Zweck in Abbildung 2 feiner aufgelöst wird.

In unserem Fall werden die Anwendungsprogramme für Rechner geschrieben, auf denen bereits ein Betriebssystem läuft. Der aus unserer Sicht zu realisierende Teil eines Programmes reduziert sich dadurch bereits entsprechend der Ein-/Ausgabe-Funktionalität, die das Betriebssystem bereitstellt.

Es verbleibt der gestrichelt abgegrenzte Teil in unserer Zuständigkeit, der sich aus einem Teil, der sich um die Benutzerschnittstelle (engl. user interface) kümmert (dem UI-Verwalter) und dem Teil, der die eigentliche Informationsverarbeitung - also der Verarbeitungsinstanz - vornimmt, zusammensetzt. Im ersten Kursteil wurde diese Trennung bereits anhand des Tetris-Spiels eingeführt, ohne näher darauf einzugehen. Der dort genannte Tetriskern entsprach der Verarbeitungsinstanz. Während der Kern nur dem Problem nahe „Maschinensprache" spricht, übersetzt der UI-Verwalter vom Betriebssystem unterstützt diese in eine für den Benutzer verständliche Sprache. Zum Beispiel zeichnet er das Spielfeld dazu in ein GEM-Fenster. Im Bild wird der UI-Verwalter auch GUI-Verwalter bezeichnet, was zum Ausdruck bringen soll, dass wir es hier speziell mit einem Verwalter für grafische Benutzeroberflächen zu tun haben.

Unter Hinzunahme der Eingangs erlangten Erkenntnis, dass große Teile des GUI-Verwalters bei allen Anwendungen gleich sind, wurde das Programm faceVALUE entwickelt, dass die Aufgabenstellung des Entwicklers weiter einschränkt. Abbildung 3 löst dazu den (G)UI-Verwalter genauer auf, und bringt Komponenten zum Vorschein, die von faceVALUE realisiert, und jene, die noch vom Entwickler realisiert werden.

Für den Programmierer verbleibt zur Realisation neben der Verarbeitungsinstanz nun noch ein wesentlich „kleinerer" UI-Verwalter, der nicht mehr mit dem vergleichsweise unkomfortablen Betriebssystem sprechen muss, sondern auf die sogenannte faceVALUE-Engine (Engine engl. Motor) und ihr viel mächtigeres Befehls-Repertoire zurückgreifen kann.

Die Aufgabe von faceVALUE

Um die Aufgabe von faceVALUE abzugrenzen, muss nun der Frage nachgegangen werden, welches die aus allen Programmen zu verallgemeinernden Funktionalitäten sind. Aus den ersten Kursteilen kennen wir bereits einige dieser verallgemeinbaren Aufgaben: Ein GEM-konformes Programm tätigt seine Ausgaben hauptsächlich in GEM-Fenstern. faceVALUE übernahm bei den Kursbeispielen die komplette „äußere" Verwaltung der Fenster: das Verschieben, Verkleinern bzw. Vergrößern oder das Scrollen wurde vollständig übernommen; das Öffnen und Schließen der Fenster konnte auf jeweils eine Anweisung (@win_open, @win_close) reduziert werden.

Für viele Arten der Ein- und Ausgabe gibt es nun genormte Ein- und Ausgabeelemente. Es handelt sich im Kleinen um die sogenannten „Dialogelemente" wie Knöpfe, Popups oder Listboxen, im Größeren um das Erscheinungsbild der Anwendung in Form von Menüleisten und Dialogfenstern.

Die Dialogfenster

Zunächst wenden wir uns nun den Dialogfenstern zu. faceVALUE bietet die Möglichkeit, komplett von der Engine verwaltete Dialogfenster zu öffnen. Der Programmierer gibt dazu die konkrete Form dieser Dialogfenster in der RSC-Datei (vgl. 1. Kursteil) vor. Diese Datei kann mit Hilfe des grafischen Editors (RCS) komfortabel und anschaulich erstellt werden. faceVALUE liegt mit der Datei LIBS.RSC eine umfangreiche Bibliothek an Dialogvorlagen und Dialogobjektvorlagen bei, aus denen Dialoge und Dialogelemente kopiert werden können. Zur Laufzeit lädt die faceVALUE-Engine diese Datei in den Speicher und kann auf die Informationen zurückgreifen. In Abbildung 3 ist diese Verbindung zu erkennen.

Zum Öffnen und Schließen von Dialogfenstern genügt nun ebenfalls jeweils ein Befehl: @win_open_dialog bzw. @win_close_dialog. Ein solches Dialogfenster ist als Beispiel in Abbildung 4 abgebildet. Um den beiden Prozeduren den gewünschten Dialog identifizieren zu können, muss ihnen die entsprechende Dialogkennung (in faceVALUE üblicherweise mit tree& bezeichnet) übergeben werden. Da die Dialoge in der RSC-Datei vom Programmierer jeweils einen eindeutigen Namen erhalten haben, macht man sich dies an dieser Stelle wieder zu nutze. Das GFA-Listing wird so generiert, dass die Kennung eines Dialoges mit dem allgemeinen Namen „xyz" zur Laufzeit unter der gleichnamigen Variablen xyz& abrufbar ist. Diese Variablen werden automatisch von der Engine beim Programmstart korrekt initialisiert. Genau genommen handelt es sich sogar um Konstanten, die z.B. von ergo!pro [1] vor dem Compilieren durch fixe Zahlwerte ersetzt werden können, um Speicherplatz und Rechenzeit einzusparen.

Selbstverständlich kann sich die faceVALUE-Engine nur um die Form der im Dialog vermittelten Information kümmern. Darunter fiele bei dem Dialog in Abbildung 4 beispielsweise die automatische Verwaltung von Sliderbewegungen oder Tastendrücken. Der Inhalt der vermittelten Information kann ihr nicht bekannt sein - und daher muss ihr dieser vom UI-Verwalter stets bereitgestellt werden.

In Abbildung 5 sind links einige Checkbuttons gezeigt. Der rechte Dialog enthält Radiobuttons und rechts sogar ein sogenanntes Toolboxpopup. »

Zu Checklistboxen, wie sie Abbildung 6 rechts zeigt, gibt es jeweils ein Statusvariablen-Array in Form eines Booleanfeldes (xyz_var!()). jeder Eintrag darin kann mit einem „Häkchen" versehen sein.

Wertekommunikation: Die Statusvariablen

UI-Verwalter und Engine tauschen diesen Inhalt über die sog. Statusvariablen aus (siehe Abbildung 3). Dies sind GFA-Basic-Variablen, die das faceVALUE-Hauptprogramm bei der Erstellung des Quelltextes als Schnittstellenvariablen zwischen dem Generiertem (der Engine) und Programmiertem automatisch einführt. Sie können im Quelltext in der Prozedur @user_var_index nachgeschlagen werden, die nur zur Dokumentation dieser Schnittstelle eingefügt wird.

Anzahl und Funktion der Statusvariablen richten sich nach Anzahl und Typ der in der RSC-Datei definierten Dialogelemente. Für jedes Dialogelement gibt es so seinem Typ entsprechende Statusvariablen - für die Objekte des Dialoges in Abbildung 4 wären dies zum einen jeweils eine String-Variable, die den Textinhalt der Texteingabefelder beinhaltet, und jeweils eine numerische Variable, die die aktuelle Position der Sliderobjekte (im faceVALUE-Jargon werden diese entsprechend als Numberscroller bezeichnet) ausdrückt.

Abschließend sei mit den Toolstrips (waagerecht) und den Toolbars (senkrecht) eine Kombination aus Userwindow und Dialogfenster vorgestellt (Abbildung 7).

Der Bezeichner der Statusvariablen richtet sich nach dem Objektnamen, der in der RSC-Datei für das ihnen zugeordnete Dialogobjekt vergeben wurde. Genau wie die Dialogkennungen der Dialoge in gleichnamigen Word-Variablen abgelegt werden, so gibt es auch für Dialogobjekte Kennungen, die in den Objekten gleichbenannten Word-Variablen abgelegt werden. Diese Kennungen werden in einigen Fällen benötigt, um einzelne Objekte identifizieren zu können (s.u.). Die Statusvariablen erhalten ihre Namen nun in ähnlicherWeise.

Bei unkomplexen Dialogelementtypen gibt es für das Element „xyz" nur eine Statusvariable, die - je nach Typ des Dialogelementes - xyz_var!, xyz_var& oder xyz_var$ benannt wurde. Das Postfix „_var" soll ausdrücken, dass es sich um eine Statusvariable handelt. Bei komplexeren Typen (etwa Listboxen) kommt es vor, dass die Statusvariablen sogar Arrays beinhalten.

Vor dem Öffnen eines Dialoges füllt der Programmierer nun die Statusvariablen mit den Werten, die dem Benutzer vorgelegt werden sollen. Nach dem Öffnen kann er die vom Benutzer nun ja zum Teil veränderbaren Werte jederzeit wieder aus den Statusvariablen auslesen - die Engine hält die Variablen während der Dialog geöffnet ist stets „up to date" bezüglich der Eingaben.

faceVALUE verlangt die konsistente Vorbelegung der Statusvariablen nicht nur vor dem Öffnen eines Dialoges, sondern auch einmalig zu Programmstart. Dazu legt es die Userprozedur (näheres zu den Userprozeduren s.u.) @user_rsc_var_init an und listet dort alle Statusvariablen in Form von Initialwertzuweisungen auf. Der Programmierer soll hier die passenden Vorbelegungen eintragen. Listing 1 zeigt diese Prozedur.

Änderungen an den Statusvariablen

Auch der Schreibzugriff vom UI-Verwalter auf die Variablen ist nach dem Öffnen des Dialoges noch möglich. Die Engine überträgt dann die veränderten Werte in den Dialog und vermittelt sie somit dem Benutzer. Hier ist lediglich ein Sachverhalt zu akzeptieren: Da es der Engine in GFA-Basic nur dann möglich wäre, Veränderungen in den Variablen seitens des Programmierers automatisch zu erkennen, wenn sie vor jeder Aktion des UI-Verwalters die Statusvariablen kopieren und nach der UI-Verwalter-Aktion die Änderungen durch Vergleich mit den alten Werten heraussuchen würde, wurde aus Effizienzgründen ein Protokoll zwischen UI-Verwalter und Engine eingeführt, um Änderungen an Statusvariablen zu melden.

Hat der Programmierer Statusvariablen von geöffneten Dialogen geändert, so teilt er dies der Engine durch anschließenden Aufruf der Prozedur @rsc_ob_reset mit. Dieser Prozedur wird zum einen die Kennung des Dialoges (tree&), zum anderen die Kennung des von der Änderung betroffenen Dialogobjektes (ob&) übermittelt. Wurden Statusvariablen vieler Objekte gleichzeitig verändert, so kann als ob& der Wert 0 angegeben werden, womit der komplette Dialog als verändert gilt. Die faceVALUE-Engine veranlasst nun die nötigen internen Aktualisierungen, insbesondere aber auch das Übertragen der neuen Werte in die dem Benutzer sichtbaren Objekte.

Es sei angemerkt, dass die Prozedur @rsc_ob_reset vom faceVALUE-Hersteller als Extraroutine eingeordnet wurde und daher im faceVALUE-Hauptprogramm bei Bedarf explizit zum Einbinden ausgewählt werden muss (vgl. 1. Kursteil).

Listing 1

PROCEDURE user_rsc_var_init
    '
    ' Hier müssen alle Status-Variablen korrekt vorbelegt werden.
    ' Ebenso müssen die Arrays für die Listboxen hier dimensioniert 
    ' und initialisiert werden.
    '
    ' Diese Prozedur wird einmal beim Programmstart durchlaufen.
    ' Danach werden die entsprechenden Dialogobjekte nach 
    ' den hier getätigten Einstellungen eingerichtet.
    '
    current_menubar&=menu&      !in diese Variable den Menübaum-Index eintragen
    '
    '
    LET check_var!=FALSE        ! TRUE/FALSE - Baum: dialog1&
    LET nscroll_var$="98"       ! min=98/max=98 - Baum: input&
    '
RETURN

Ereigniskommunikation: die user-Routinen

Ereigniskommunikation liegt im Unterschied zur Wertekommunikation immer dann vor, wenn der Empfänger bereits weiß, welcher Wert übermittelt werden wird. Es interessiert ihn dann vielmehr der Zeitpunkt der Wertänderung. Beispielsweise weiß ein Autofahrer vor einer roten Verkehrsampel genau, welchen „Wert" die Ampel im Folgenden annehmen wird.

In GFA-Basic können zwei Programmteile Ereigniskommunikation zum einen dadurch betreiben, dass sie sich gegenseitig Flags setzen und löschen. Hierbei ist es nötig, dass die beiden Programmteile nebenläufig abgewickelt werden, was über die Hauptschleifenarchitektur ermöglicht werden kann (vgl. 1. Kursteil).

Zum Anderen gibt es die - meist einfachere - Möglichkeit des gegenseitigen Aufrufens von Prozeduren. So kann der Ereignisempfänger unmittelbar reagieren. Hierbei gilt es dann zu beachten, dass der Empfänger es mit der Reaktion nicht „übertreibt", da der Absender seine Operation noch nicht abgeschlossen, sondern mit dem Unterprogrammsprung nur zum Zwecke der Ereignismeldung unterbrochen hat.

Auch zwischen Benutzer und faceVALUE-Engine findet ebenso wie zwischen faceVALUE-Engine und UI-Verwalter Ereigniskommunikation statt. Das Drücken eines OK-Knopfes stellt z.B. ein solches zu übermittelndes Ereignis dar. Gleiches gilt natürlich für die Anwahl von Menüpunkten im Hauptmenü oder in sogenannten Menü-Popups (s.u.).

Für faceVALUE hat man sich dazu entschieden, solche Ereignisse via Prozeduraufruf zu melden. Wie bereits im ersten Kursteil erläutert, gibt es zu jedem Typ der von der Engine zum UI-Verwalter meldbaren Ereignisse eine user-Prozedur, die von der Engine im Falle eines jeweiligen Ereignisses angesprungen wird. Der Programmierer kann nun in dieser Prozedur auf das Ereignis reagieren.

Dialog- und Menüaktionen meldet die Engine durch Aufruf der Prozedur @user_rsc_interact. Als Parameter erhält man Informationen darüber, in welchem Dialogbaum welches Objekt angewählt wurde.

Wegen der Vielzahl der Objekte ist nun ein mitunter sehr großer Fallunterscheider notwendig, um die passende Operation auszuwählen. Das faceVALUE-Hauptprogramm kannte ja zum Zeitpunkt der Listingerstellung alle Dialogobjekte der RSC-Datei und war deshalb in der Lage, die Prozedur @user_rsc_interact bereits mit einem Fallunterscheider zu füllen, der alle ereignisauslösenden Dialogobjekte in Form der SELECT-/CASE-Entscheidungsan Weisung unterscheidet (siehe Listing 2).

Als Programmierer schreibt man seinen Code nun in die einzelnen CASE-Zweige hinein. In Listing 2 wird beispielsweise durch Aufruf der Prozedur @win_close_dialog der Dialog mit dem Namen „dialog1" geschlossen, sobald der Knopf mit dem Namen „ok" im selbigen Dialog vom Benutzer angewählt wird.

Die Menüzeile

Es fehlt bislang die Betrachtung, welche konkreten Dialogelementtypen von faceVALUE bereitgestellt werden und welche Statusvariablen bzw. Ereignismeldungen diesen zugeordnet sind. Bevor nun aber auf die Dialogelemente eingegangen wird, soll die in der Regel wichtigste Eingabemöglichkeit erörtert werden: die Menüzeile eines Programms.

Menüzeilen werden ebenfalls mit Hilfe des RCS-Programms in die RSC-Datei eingebracht. Das faceVALUE-Hauptprogramm generiert für jede Menüzeile ebenfalls Einträge in @user_rsc_interact. In Listing 2 ist zu sehen, wie auf das Anwählen des Menüeintrages mit dem Namen „open" mit dem Öffnen des Dialoges „dialog1" und auf das Anwählen des Menüeintrages „quit" mit dem Beenden des Programms reagiert wird. Welches der möglicherweise ja mehreren Menüs aus der RSC-Datei nach dem Programmstart angezeigt wird, wird in der Prozedur @user_rsc_var_init durch Initialisieren der Variablen current_menubar&c festgelegt (s. Listing 1). Somit realisieren Listing 1 und 2 bereits mit Ausnahme der RSC-Datei ein komplettes Programm mit Menüzeile und Dialogfenster. Das Menü erscheint nach Programmstart. Der Dialog lässt sich über das Menü öffnen und über den OK-Knopf wieder schließen.

Listing 2

PROCEDURE user_rsc_interact(index&,tree&,object&,mc&,sub_me&)
    '
    '  <index&>  Index des Fensters in window_array&(index*,x)
    '            Wenn das Objekt aus der Menüzeile ist: <index*>=-l
    '   <tree&>  Index des Objektbaumes
    ' <object&>  Index des selektierten Objektes (über Mausklick oder Shortcut) 
    '     <mc&>  Anzahl der Mausklicks (l=normal oder Shortcut / 2=Doppelklick)
    ' <sub_me&>  ausgewählter Menüeintrag in Popup-Menüs
    '
    SELECT tree&
        '
        ' ------------------------------------------------
        '
    CASE dialog1&
        SELECT object&
        CASE button1&
            ' der Knopf mit dem Namen 'buttonl' wurde angewählt 
        CASE button2&
            ' der Knopf mit dem Namen 'button2' wurde angewählt 
        CASE ok&
            ' der Knopf mit dem Namen 'ok' wurde angewählt 
            @win_close_dialog(dialog1&)
        ENDSELECT
        '
        ' ------------------------------------------------
        '
    CASE menu&
        SELECT object&
        CASE open&
            ' der Knopf mit dem Namen 'open' wurde angewählt 
            ~@win_open_dialog(-1,dialog1&,-1)
        CASE quit&
            ' der Menüeintrag mit dem Namen 'quit' wurde angewählt 
            LET exit_program!=TRUE 
        ENDSELECT
        '
        ' ------------------------------------------------
    ENDSELECT
    '
RETURN

Tabelle 1: Wertebereiche, Objekttypen und Statusvariablen

Wertebereich	Funktion	Element	Statusvariable(n)
binär	An-/Abwahl	Checkbutton	xyz_var!
kleine, nat. Zahl	Auswahl	Radiobutton, Radiopopup	xyz_var&
Zahl	Zahlwert	z.B. Scrollfeld	xyz_var$
Text	Text	Text-Ein-/Ausgabefeld	xyz_var$
viele Binärwerte	An-/Abwahl	Checklistbox	xyz_var!(), xyz_arr$(), xyz_ndx&
große, nat. Zahl	Auswahl	Radiolistbox	xyz_var&, xyz_arr$(), xyz„ndx&

Die Dialogelemente

Dialogelemente lassen sich im ersten Schritt in Ein-, Ausgabe- und Gliederungselemente klassifizieren. Ausgabeelemente besitzen stets Statusvariablen, da sie immer der Wertanzeige dienen. Im Unterschied zu den Eingabeelementen kann der Benutzer die Werte allerdings nur ablesen und nicht beeinflussen. Man unterscheidet verschiedene Wertebereiche, die in Tabelle 1 aufgeschlüsselt sind. Entsprechend gestaltet sich die zugehörige Statusvariable.

Beispiele zu den Nummern- und Texteingabefeldern befanden sich ja bereits in Abbildung 4. In Abbildung 5 sind links einige Checkbuttons gezeigt. Der rechte Dialog enthält Radiobuttons und rechts sogar ein sogenanntes Toolboxpopup. Hier gibt es im Beispiel eine Auswahlmöglichkeit aus sechs Möglichkeiten, wobei jede der 6 Möglichkeiten abermals einige Alternativen anbieten kann. Die Statusvariablen teilen sich auf in eine Variable, die die Nummer der angewählten Toolbox, und eine Variable, die die Nummer des darin angewählten Eintrages beinhaltet. Näher soll hier nicht auf diesen Typ eingegangen werden.

Zu Checklistboxen, wie sie Abbildung 6 rechts zeigt, gibt es jeweils ein Statusvariablen-Array in Form eines Booleanfeldes (xyz_var!()). Jeder Eintrag darin kann mit einem „Häkchen" versehen sein.

Angemerkt sei, dass Listboxen allgemein noch über ein Statusvariablen-Array des Typs String (xyz_arr$()), welches für jeden Eintrag den darzustellenden Text beinhaltet, und über eine Word-Variable, die angibt, wie viele Einträge die Listbox enthält (xyz_ndx&), verfügen.

Bei den Eingabeelemente gibt es nun ferner auch Elemente, die der Ereigniseingabe dienen. Diese Elemente verfügen über keinerlei Statusvariablen. Sie werden nach dem Anwählen unmittelbar wieder abgewählt. Das Ereignis wird jedoch durch Aufruf der Prozedur @user_rsc_interact gemeldet. Die Elemente haben dort also einen Eintrag erhalten. Hier gibt es neben den normalen Knöpfen (in faceVALUE werden diese Knöpfe zur Unterscheidung von den Check- und Radiobuttons „Aktionsknöpfe" genannt) auch Aktionspopups und Aktionslistboxen. Löst der Benutzer hiermit ein Ereignis aus, landet der Programmfluß ebenfalls im CASE-Zweig des zugehörigen Objektes. Dann muss der Programmierer aber noch nach dem angewählten der Untermenüpunkte, welche einfach durchnummeriert sind, unterscheiden.

Toolstrips und Toolbars

Abschließend sei mit den Toolstrips (waagerecht) und den Toolbars (senkrecht) eine Kombination aus Userwindow und Dialogfenster vorgestellt (Abbildung 7). Das Öffnen solcher „Kombifenster" geschieht mit dem Aufruf @win_open (vgl. Kursteil 1-3). Hierbei wird aber ein Fenstertyp angegeben, der im faceVALUE-Hauptprogramm als Toolstrip oder Toolbar markiert wurde. Ebenfalls im Aufruf angegeben wird die Kennung des Toolstrip- oder Toolbardialoges. Von nun an kümmert sich die Engine um den Dialogteil wie um jeden anderen Fensterdialog, überlässt aber die Kontrolle über den Userwindow-Teil dem Programmierer wie bei jedem anderen Userfenster.

Ausblick

Dieser Kursteil hat umfangreich in die Grundlagen der Dialogprogrammierung eingeführt. Ein Praxisbeispiel kommt daher erst im nächsten Teil, in dem gleichzeitig der Modularisierungsaspekt einbezogen wird. faceVALUE tritt dabei als Quelltextlinker in Aktion.

Anhand der Anleitung aus diesem Teil sollte aber jeder Kursteilnehmer in der Lage sein, Programme mit Menüzeilen und Dialogen zu schreiben. Die Listings zeigen, wie einfach sich dies gestaltet. Bis zur nächsten Ausgabe wünschen wir Ihnen viel Erfolg! □

[1] RUN! Software - friendly applications -, Vorgartenstraße 9, D-66424 Homburg info@run-software.de run-software.de

Das Thema der nächsten Kursfolge ist das modulare Programmieren anhand der Wrinkles.

Holger Herzog

---

---