Virtual OS/2 International Consumer Education
VOICE Homepage: http://de.os2voice.org
Oktober 2002

[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]

editor@os2voice.org


DrDialog, oder wie ich lernte, REXX zu lieben - Teil 2

Von Thomas Klein © Oktober 2002

So - die Sommerferien sind vorbei und Deutschland hat gewählt. Wir haben also endlich wieder Zeit für wichtiges! ;) Bevor ich aber die Hausaufgaben kontrolliere (haben Sie die etwa vergessen!?) muß ich mich zu allererst für die vielen Mails bedanken, die mich seit Veröffentlichung des ersten Teils erreicht haben. Ich hätte nicht damit gerechnet, daß die Serie ein doch scheinbar breites Publikum findet und daß dieses auch derart "aktiv" sein Interesse und seine Unterstützung bekundet. Vielen Dank! Das zeigt, daß es mit der OS/2-Gemeinde noch lange nicht so schlecht aussieht, wie manche andere es sich/uns einreden wollen - zumindest kann man das für den Teil der Gemeinde behaupten, der den VOICE Newsletter liest.

Ach ja - Hausaufgaben:
Die Frage war, wie wir die Textbox in unserem Beispiel dazu bekommen, beim Start des Programms leer zu sein. Zwei Wege stehen zur Verfügung:

  1. Zur Entwicklungszeit ("design time")

    Als Vorgabewert für den Inhalt der Textbox verwenden wir ein leeres Feld. Das erreicht man, indem man zur Entwicklungszeit das Kontextmenü der Textbox aufruft und den Eintrag Text auswählt. Im Eingabefenster, das dann angezeigt wird, können Sie direkt den Vorgabewert angeben. Hier steht bereits der bisherige Wert ("Text") drin, den Sie einfach komplett löschen. Drücken Sie zur Übernahme Ihrer Eingabe entweder auf die Schaltfläche mit dem grünen Häkchen oder einfach die Eingabetaste.

  2. Zur Laufzeit ("run-time")

    Wir verwenden eine explizite Anweisung, um den Inhalt des Feldes aus dem Programm heraus zu löschen. Die Anweisung selbst ist nicht so kompliziert und Sie können sie aus der Zeile ableiten, die wir letzten Monat besprochen hatten:

    call ausgabe.text("Hallo Welt!")

    Daraus machen wir also jetzt

    call ausgabe.text("")

    Okay, das war ja noch relativ klar, aber der schwierige Teil ist, die "Stelle" zu finden, wo man das hinschreibt. Und da habe ich Sie zweifelsohne letzten Monat ins kalte Wasser geworfen - sorry. Genau genommen stehen Ihnen hier auch zwei Methoden zur Verfügung. Entweder geben Sie diese Anweisung in dem Moment an, wenn das Ereignis "Dialog öffnen" ausgelöst wird, oder Sie schreiben diese Anweisung in die "globale Hauptroutine". Jetzt sind Sie auch nicht viel schlauer, nicht wahr? Es ist nicht ganz so leicht, einen vernünftigen Einstieg in das Thema zu finden - mal sehen...

Ereignisgesteuerte Programmierung

Die klassischen "prozeduralen" Programmiersprachen haben einen definierten Anfangspunkt und arbeiten von dort aus über verschiedene Konstrukte (Verzweigung, Iteration, usw.) zu einem Endpunkt. Sie haben vielleicht schon einmal die simpelste Form einer prozeduralen Sprache gesehen: Batchdateien - wie zum Beispiel die AUTOEXEC.BAT.
Die Steuerung des Ablaufs in einer prozeduralen Sprache ergibt sich dabei aus expliziten Anweisungen, die der Programmierer vorgibt. Aufrufe von Unterroutinen werden stets von einer entsprechenden Anweisung in einer übergeordneten Routine gemacht. (Bsp.: gosub, PERFORM, call)

Bei der "ereignisgesteuerten" Programmierung liegt der Fall anders: Es gibt zwar nach wie vor nur einen Startpunkt, aber sobald Sie Ihren Dialog angezeigt haben, befinden Sie sich programmtechnisch in einem "undefinierten" Zustand: Sie wissen nicht, was als erstes passiert und was evtl. danach passiert. Wenn Sie eine Eingabemaske mit mehreren Feldern, Listen und Schaltflächen haben, dann wissen Sie nicht, ob der Anwender zuerst in der Liste blättert, etwas in einem Feld eingibt, auf Abbruch oder auf OK klickt. Daher existieren zu jedem möglichen Ereignis einzelne kleine Programmteile. Unterroutinen sozusagen. Diese liegen - wenn man so will - "zusammenhanglos im Programmcode herum" und sind funktional gesehen auch nichts anderes als "prozedurale" Anweisungsfolgen - der Unterschied liegt aber darin, daß diese Routinen nicht vom Programmierer im Code explizit aufgerufen werden ("call..."), sondern daß das automatisch durch das Betriebssystem (bzw. das Fenstermanagement) geschieht.
Die technisch versierten Fortgeschrittenen mögen diese etwas schwammige Beschreibung verzeihen. Ich denke, es ist für unsere Zwecke nicht notwendig, die genaue Funktionsweise zu erlernen.

Der komplette Ablauf eines Programms in DrDialog geschieht also auf Basis von Ereignissen. Es gibt Ereignisse, die erst bei Aktionen des Anwenders ausgelöst werden, wie z.B. das Klicken einer Schaltfläche oder das Betätigen eines Schiebereglers. Es gibt aber auch andere Ereignisse, wie z.B. das Laden eines Dialogs, die unabhängig von Benutzeraktionen ausgelöst werden.
Diese Ereignisse werden im Prinzip von DrDialog zur Verfügung gestellt, damit wir an bestimmten Punkten des Programmablaufs eine Möglichkeit haben, Aktionen durchzuführen. In unserem Beispiel könnten wir also beim Laden des Dialogs die Anweisung setzen, daß die Textbox "leer" sein soll.

Wir wir jetzt wissen, handelt es sich dabei also um ein Ereignis zu einem Dialog. Wir klicken also mit Maustaste 2 auf einen freien Bereich des Dialogfensters und wählen aus dem erscheinenden Kontextmenü den Eintrag Ereignisse ("Events").
Dann wird ein Untermenü eingeblendet, welches alle Ereignisse auflistet, die zu einem Dialog nun mal eben anfallen können - darunter das vielversprechende Open (Öffnen). Das ist also das Ereignis, welches ausgelöst wird, wenn das Dialogfenster vom Programm geöffnet wird - also genau das, was wir brauchen. Wählen Sie's aus.

Das Codeeingabefenster ist wieder da - mit genau der Stelle, die von DrDialog angesprungen wird, wenn unser Dialogfenster angezeigt wird. Ich würde sagen, wir geben da jetzt 'mal unsere Zeile ein:

call ausgabe.text("")

Die Auswahl des Ereignisses hätte man übrigens verkürzen können, indem man einfach einen Doppelklick auf eine frei Stelle des Dialogfensters gemacht hätte - aber das wäre weniger lehrreich gewesen, denn jetzt wissen Sie (wieder), wie man an die Ereignisse "herankommt". ;)
Wenn Sie wollen, können Sie jetzt erst einmal das Resultat dieser Änderung ausprobieren. Sie wissen noch, wie man das "laufende Männchen" bedient...?

Was passiert hier eigentlich?

Wir haben jetzt besprochen, wie man das Ereignis des Dialogladens dazu verwenden kann, zur Laufzeit Einfluß auf die Dialogelemente zu nehmen. Schön - hey Moment!
Haben Sie sich nicht schon einmal gefragt, wo eigentlich das Programm anfängt? Wo ist die Stelle im Code, wo alles beginnt? Und wieso wird unser Dialog überhaupt angezeigt, obwohl wir DrDialog nirgends gesagt haben, daß er das machen soll?
Die Antwort auf diese Fragen ergibt sich aus dem "Ablaufschema" (execution model) von DrDialog: Im Prinzip basiert es darauf, daß DrDialog von sich aus gar nix macht, sondern immer nur auf Ereignisse reagiert. Die einzige Ausnahme davon ist der Programmstart. Hier wurde vom Entwickler von DrDialog das folgende Verfahren fest eingebaut:

  1. Wenn es keine Prozedur namens INIT im globalen Prozedurbereich gibt, dann stelle intern eine leere Prozedur diesen Namens zur Verfügung.
  2. Alle in der Prozedur INIT definierten Dialogfenster nacheinander laden und anzeigen.
  3. Was, noch kein Dialogfenster angezeigt? Dann lade jetzt von allen Dialogen denjenigen mit der kleinsten ID-Nummer. (Erinnern Sie sich noch, daß DrDialog für alle Elemente neben einem benutzerwählbaren Namen auch eine systemspezifische Kennung vergibt? Nun - wie könnte es anders sein: Auch Dialoge selbst besitzen so eine eindeutige Nummer.)
  4. Wie jetzt? Noch immer kein Dialog angezeigt? Jetzt reicht's aber: Fehlermeldung "kein Dialog zum Laden vorhanden".

Da wir in unserer Beispielanwendung nirgends eine Prozedur namens INIT geschrieben haben, trifft also Regel 3 zu: DrDialog lädt das Dialogfenster mit der kleinsten ID-Nummer. Dieses Verfahren ist eigentlich genauso simpel wie zuverlässig: Beim Start erzeugt DrDialogs Entwicklungsumgebung automatisch einen leeren Dialog. Solange Sie keine INIT-Prozedur anlegen, wird DrDialog anhand "Regel 3" den ersten Ihrer Dialoge laden und in seinen "normalen Zustand" eintreten:

*Warten auf Ereignisse*

Als zusätzliche Sicherung hat DrDialog noch ein Feature eingebaut, das auf den ersten Blick völlig sinnlos erscheint: Wenn Sie aus einer Anwendung den letzten (bzw. einzigen) Dialog löschen, bekommen Sie postwendend einen neuen, leeren Dialog spendiert. Somit ist gesichert, daß DrDialog zumindest immer einen Dialog hat, den er zum Eintritt in seinen Betriebszustand benutzen kann.

Global und INIT

Aber kommen wir noch mal zu unserer oberen Beschreibung zurück: Globaler Prozedurbereich und INIT.

Frage 1: Was ist "Prozedurbereich" ?
Antwort: Das ist (aus unserer Sicht gesehen) alles, was im Code-Fenster eingegeben wird. Wenn wir z.B. auf das Klicken der Schaltfläche reagieren wollen, schreiben wir alle nötigen Anweisungen in die entsprechende Notizbuchseite im Code-Fenster. Eine solche Notizbuchseite stellt einen Event-Handler (Ereignisbehandlungsroutine) dar - also eine Prozedur, die vom System ausgeführt wird, wenn das zugehörige Ereignis auftritt. Jede Notizbuchseite, in der wir etwas eingetragen haben, ist also eine solche "Prozedur".

Frage 2: Was bedeutet jetzt "global" in dem Zusammenhang?
Antwort: Wie eben erklärt, gibt es zu jedem Ereignis eine Ereignisbehandlungsroutine. Darüber hinaus kann der Entwickler auch eigene Funktionen, Routinen bzw. Prozeduren definieren. Das dient vor allem dazu, bestimmte Verarbeitungen, die öfters benötigt werden, nur einmal zu definieren und somit von mehreren Stellen im Code aufrufen zu können. Stellt der Programmierer einen Fehler im Ablauf fest oder soll dieser erweitert werden, muß man die Änderung nur an einer Stelle im Code vornehmen, anstatt alle betroffenen Stellen entsprechend zu ändern. Oft werden solche "eigenen" Routinen auch einfach dazu eingesetzt, einen komplexen Ablauf innerhalb eines Programms übersichtlicher zu gestalten.
Wie dem auch sei - solche Routinen können auf Dialogebene definiert werden, d.h. sie können von jeder Code-Stelle innerhalb des Dialogs aufgerufen werden. Praktisch, hm? Was ist aber, wenn ich ein Programm mit mehr als einem Dialogfenster habe und eine Prozedur schreiben will, die ich von "überall" aufrufen kann - beispielsweise eine Routine, die Fehler behandelt oder Einstellungen aus einer INI-Datei liest? In diesem Fall muß man die Prozedur nicht auf Dialogebene sondern "global" definieren: Global bedeutet, daß diese Prozedur von jeder Code-Stelle innerhalb des Programms aufgerufen werden kann. In DrDialog werden globale Routinen in einem eigenen Bereich des Codefensters definiert - zu erkennen an der Notizbuchseite mit dem Weltkugel-Symbol.

Die "globale Hauptroutine" ist eine Prozedur, in der man DrDialog mitteilen kann, was er beim Start des Programms machen soll. Ihr Vorhandensein führt dazu, daß kein automatisches Laden und Anzeigen eines Dialogfensters geschieht. Auch hier wäre unter Umständen ein geeigneter Ort, um unsere Textbox beim Start zu "leeren". Allerdings unterliegt das einem tieferen Verständnis der Zusammenhänge des Ablaufverfahrens von DrDialog: Die Art und Weise wie DrDialog Ereignisse auslöst und verarbeitet, ist auf jeden Fall einen eigenen Serienteil wert - aber im Moment interessiert uns mehr, was die vielen controls von DrDialog alles können und wie man zum Teufel das Programm wieder beendet, wenn es erst mal gestartet wurde. ;) Wir kümmern um also später um die "globale Hauptroutine". Basta.

Nachdem Sie also nun entweder Methode 1 oder 2 benutzt haben, um die Textbox schön "leer" zu machen, könnten wir uns überlegen, das Programm noch vernünftig zu beenden. Dafür gibt es im Normalfall auch mehrere Möglichkeiten: Eine "Ende"-Schaltfläche, über einen Menüpunkt "Datei/Beenden" oder über das Systemmenü (den Fenster-Schließen-Knopf ab Warp4, <ALT-F4> oder Doppelklick auf das Fenstersymbol in der linken oberen Ecke des Fensterrahmens).
Lassen Sie mich gleich vorweg schicken, daß wir uns das mit dem "Datei/Beenden" auch erst später anschauen werden, da das Arbeiten mit Menüs noch weitere Kenntnisse voraussetzt, deshalb heute hier nur die anderen beiden Methoden...

Der Vorteil des Systemmenüs oder auch Fensterknopfs (oder <ALT-F4>) liegt darin, daß wir keine weiteren Eingaben in DrDialog machen müssen, damit es funktioniert - es ist also quasi "eingebaut", wie Sie vielleicht schon letzten Monat bemerkt haben: <ALT-F4> beendet unser Beispielprogramm.
Bleibt noch die Frage, warum unser Programm keinen "Fenster-Schließen"-Knopf hat. Das liegt an den Eigenschaften des von uns verwendeten Dialogtyps - wir haben keine zusätzlichen Angaben gemacht und einfach den von DrDialog vorgegebenen Standard verwendet. Dieser Standard erzeugt ein Dialogfenster, das in seiner Größe geändert werden kann, eine Titelzeile und ein Systemmenü hat,

aber leider keine Schaltflächen zum Minimieren/Maximieren. Um das zu ändern, wählen Sie aus dem Kontextmenü unseres Dialogs den Eintrag Style (Stil). Im dann erscheinenden Dialog interessieren uns zunächst die Sachen im Bereich optional controls (optionale Steuerelemente):

Mit Warp4 (oder diversen WPS-Erweiterungsprogrammen schon vorher) wurde der Fensterknopf "Schließen"

eingeführt. Damit unser Fenster einen solchen Knopf bekommt, muß es über ein Systemmenü und mindestens einen der beiden Knöpfe "Maximieren" oder "Symbolgröße" verfügen. Erst dann wird vom System die zusätzliche Schaltfläche im Fensterrahmen angezeigt.
Wie Sie noch aus unserer letzten Ausgabe wissen, reicht <ALT-F4> zum Beenden unseres Programms. So verhält es sich auch mit allen fenstereigenen Funktionen: "Schließen" aus dem Systemmenü oder der "Schließen"-Fensterknopf machen nichts anderes. Was uns fehlt, ist eine "eigene" Schaltfläche zum Beenden und eine entsprechende Anweisung im Code.

Legen wir also eine Schaltfläche an:
Das machen wir entweder, indem wir aus unserer Steuerelementesammlung eine Schaltfläche auf unser Dialogfenster ziehen, oder mittels dessen Kontextmenü: Hier können Sie (nachdem Sie einen Klick mit Maustaste 2 auf einen freien Bereich des Dialogfensters ausgeführt haben) das Untermenü controls aufblenden. Wählen Sie dann den Eintrag mit dem Schaltflächensymbol aus:

So. Jetzt hätten wir die Schaltfläche. Geben wir ihr noch einen "vernünftigen" Namen: Kontextmenü der Schaltfläche aufrufen und Name auswählen. Geben Sie dann btn_ende ein. Zwar braucht man kein bestimmtes Benamungsschema zu beachten, aber es empfiehlt sich. So verwende ich selbst "cmd_..." als Einleitung für die Namen von Schaltflächen, "txt_..." für die Namen von Textboxen und so weiter. Das hat den Vorteil, daß alle Elemente gleichen Typs in der Liste der Steuerelemente Ihres Dialogs schön gruppiert sind. Außerdem fällt es einfacher, sich die Namen zu merken und es ist quasi eine Art eingebauter Selbstdokumentation. Glauben Sie mir, wenn Sie nach zweimonatiger Pause wieder an einem Programm weiterarbeiten wollen, werden Sie froh sein, daß es da ein "System" für die Namensgebung gibt. ;)

Okay - Schaltfläche haben wir, einen Namen dafür auch. Aber Push als Beschriftung? Na ja. Daß man auf den Knopf klicken kann, versteht sich irgendwie von alleine - allerdings sollte man vielleicht klar stellen, was dadurch geschieht. Also wieder: Kontextmenü der Schaltfläche, Text auswählen und Beenden eingeben. Aha.

Fehlt noch die Aktion, die beim Klicken der Schaltfläche denn nun ausgeführt werden soll. Um dem Programm dies mitzuteilen, machen wir einfach einen Doppelklick auf unsere neue Schaltfläche und geben im Code-Fenster die folgende hyperkomplexe Anweisung an:

exit

Warum schwer, wenn's auch einfach geht? ;)
Okay - das ist natürlich nicht die "politisch korrekte" Art, mit der ein Programm beendet wird, denn damit wird das gesamte Programm inklusive aller evtl. geöffneten Dateien oder Dialoge sofort beendet. Das ist in unserem Fall zwar okay, aber normalerweise würde man noch bestimmte Routinen ausführen wollen, wie "Änderungen sichern ja/nein" oder das Speichern von Werten in einer INI-Datei vielleicht. Alles das müsste man vor dem exit-Befehl natürlich noch durchführen.

Aufmerksame Leser fragen sich jetzt bestimmt: Wieso funktioniert <ALT-F4>, wenn wir bisher nirgends exit angegeben haben? Jaa - das ist eine gute Frage - hier kommt die Antwort:
DrDialog verfügt neben dem exit-Befehl noch über ein eingebautes Verfahren: Das Schließen des letzten geöffneten Dialogs beendet ebenfalls das Programm. Das ist auch der Grund, warum <ALT-F4> unser Programm beendet: Hiermit wird zwar eigentlich "nur" unser Dialogfenster geschlossen, aber da es in unserem Programm das einzige ist (bzw. das "letzte noch geöffnete", wenn man so will) wird damit auch das Programm beendet.
An Stelle der Anweisung exit können wir also auch aus dem Code heraus unser Fenster schließen. Um dem Programm aber mitzuteilen, daß es den Dialog schließen soll, müssen wir dessen Namen angeben. Und der lautet (so weit ich mich erinnere) immer noch D100, da wir unserem Dialog bisher keinen eigenen Namen gegeben haben. Zeit, das zu ändern! Wie immer rufen wir also ein Kontextmenü auf - das des Dialogfensters (klicken mit Maustaste 2 auf leeren Bereich des Fensters). Name auswählen und dann dlg_test oder so eingeben und <Enter> drücken.
Doppelklick auf die Schaltfläche Beenden, um das Codefenster wieder anzuzeigen (falls es nicht mehr sichtbar sein sollte) und die Anweisung exit ersetzen durch

call dlg_test.close

Diese Anweisung bedeutet, daß wir die Methode CLOSE des Steuerelements dlg_test aufrufen, um es einmal detaillierter zu sagen. Probieren Sie es aus - klappt, nicht wahr?
Jetzt kommen wir auch direkt zu einer interessanten Frage in diesem Zusammenhang: Wo liegen die Vorteile und Unterschiede der beiden "Beenden"-Varianten?
Die Anweisung exit hat den Vorteil, daß das Programm sofort beendet wird - ungeachtet der Frage, wie viele Fenster vielleicht noch offen sind. Das Schließen des Fensters wiederum hat den Vorteil, daß natürlich entsprechend nicht alle anderen Dialoge auch geschlossen werden... außerdem wird durch das Aufrufen der Methode close das Ereignis exit unseres Dialogfensters ausgelöst. Da wir mit unserer Schaltfläche dasselbe Verfahren verwenden, das auch bei <ALT-F4> (etc.) ausgelöst wird, steht uns jetzt eine gemeinsame, zentrale Stelle im Programmcode zur Verfügung, die immer aufgerufen wird, wenn unser Beispielprogramm beendet wird - egal, wie dies im Detail zustande kam. Das exit-Ereignis.

Allerdings wird dieses Ereignis ausgelöst, wenn der Dialog geschlossen wurde - das bedeutet, daß wir diesen Umstand nicht mehr ändern können - eine Abfrage "Schließen-Ja/Nein"-Abfrage kommt hier zu spät, da das Schließen bereits geschehen ist. Eine "Änderungen sichern ja/nein"-Abfrage wäre hier allerdings an der idealen Stelle: Vor dem (unausweichlichen) Ende des Programms (bzw. Dialogs) könnte man noch notwendige Verarbeitungen ausführen.
Testweise sagen wir dem Programm jetzt, daß es beim Beenden einen kurzen Pieps von sich geben soll, indem wir uns in das exit-Ereignis einklinken:

Damit wird ein Signalton mit einer Frequenz von 500 Hertz für eine Dauer von 100 Millisekunden wiedergegeben. Zugegeben - eine ausgefeilte Routine ist das jetzt nicht gerade, aber damit können Sie sehr schön ermitteln, welche Arten von "Programmende"-Funktionen das exit-Ereignis auslösen.
Probieren Sie ruhig einmal alles aus: <ALT-F4>, Systemmenü, Fenster-Schließen-Knopf...

Da fällt mir ein - das habe ich ganz vergessen - daß der Codeeditor von DrDialog eine nette Funktion bietet, mit der Sie kontrollieren können, welche der möglichen Ereignisse zu einem Steuerelement von Ihnen "abgefangen" werden: Sobald Sie auf einer Notizbuchseite etwas geschrieben haben, ändert sich deren Registerkarte indem ein "*" (Sternchen) an den Namen des Ereignisses angehängt wird (Beispiel: "EXIT" -> "EXIT*").

Damit wären wir für diesen Monat am Ende.
Wenn Sie noch nicht genug haben oder noch etwas herumspielen möchten, können Sie ja einmal ausprobieren, welche Auswirkungen die unterschiedlichen Style-Einstellungen zu Border (Rahmen) und den oben beschriebenen "optional controls" auf das Aussehen und Verhalten unseres Beispieldialogs haben.
Falls Sie im exit-Eventhandler statt eines simplen Piepstons lieber eine Melodie ausgeben möchten, können Sie sich in der REXX-Dokumentation, die standardmäßig bei der Installation von OS/2 mit installiert wird, genauere Angaben und ein Beispiel dafür anschauen. Da auf meinem System alles ein wenig umgestellt wurde seit der OS/2-Installation, kann ich Ihnen leider nicht genau sagen, in welchem Ordner der Arbeitsoberfläche sie die REXX-Dokumentation finden - suchen Sie einfach nach der Datei REXX.INF (normalerweise in x:\OS2\BOOK, wobei x: das OS/2-Installationslaufwerk angibt).

Entschuldigen Sie bitte, daß wir diesen Monat noch nicht sehr viel weiter mit unserem Beispiel gekommen sind, aber einige Grundlagen von DrDialog bedürfen doch eines gewissen Maßes an Erklärung, um meiner Meinung nach "vernünftig" damit umzugehen. Wenn Sie das Verhalten von DrDialog erst einmal verinnerlicht haben, werden Sie auch später keine Probleme damit haben, wenn es um die Steuerung komplexer Anwendungen mit mehreren Dialogen geht.

Nächstes mal spendieren wir unserem Beispielprogramm ein Texteingabefeld, eine Auswahlliste sowie einen zweiten Dialog und schauen uns an, was man damit alles anstellen kann und worauf man achten muß. Danach werden wir uns ein paar der Standard-GUI-Bildschirmelemente und deren Verhalten anhand einiger Beispiele anschauen. Nachdem wir dann einen kleinen, einteiligen Exkurs in "REXX pur" hinter uns gebracht haben, fangen wir mit unserer "großen" Beispielapplikation an. Falls Sie eine (oder mehrere) Idee(n) für eine Beispielanwendung haben, teilen Sie sie mir mit!
Bisher liegen zwei Vorschläge vor, die in die engere Wahl kommen: Eine PIM-Software (Personal Information Management; also ein Adreß-, Termin- und Aufgabenplaner) oder eine grafische Oberfläche für's Arbeiten mit ZIP-Dateien (und/oder anderen Archivtypen...). Persönlich würde ich das ZIP-Frontend bevorzugen, da wir hierfür nicht so viel Hintergrundwissen benötigen und der Einsatzzweck "typisch" für REXX bzw. DrDialog ist.

Also: Bleiben Sie dran!

Daten und Quellen:

GuiObjectREXX Yahoo!-Gruppe: http://groups.yahoo.com/group/GuiObjectREXX/
Newsgruppe zur GUI-Programmierung mit REXX: news://news.consultron.ca/jakesplace.warp.visualrexx
Download von Hobbes: http://hobbes.nmsu.edu/cgi-bin/h-search?key=drdialog&pushbutton=Search


[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org