VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
Oktober 2002
[Inhaltsverzeichnis]
|
| 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:
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.
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...
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...?
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:
INIT im globalen Prozedurbereich gibt, dann stelle
intern eine leere Prozedur diesen Namens zur Verfügung.INIT definierten Dialogfenster nacheinander laden und anzeigen.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.
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):
Titlebar
Ist die Option aktiviert, hat unser Fenster eine Titelzeile. Der Inhalt der Titelzeile kann übrigens vom
Programmierer frei bestimmt werden.
Min Button
Gibt an, ob das Fenster eine Schaltfläche für "Symbolgröße" besitzt. Das wirkt sich auch auf den Inhalt des
Systemmenüs aus: Ist die Option aktiviert, ist der Eintrag Symbolgröße im Systemmenü selektierbar - sonst
eben nicht (der Eintrag ist dann zwar vorhanden, allerdings nicht wählbar).
Max Button
Gibt an, ob das Fenster eine Schaltfläche zum "Maximieren" besitzt. Analog zum "Min button" wirkt sich auch diese
Option auf den Inhalt des Systemmenüs unseres Dialogs aus: Ist die Option aktiviert, ist der Eintrag Maximieren
im Systemmenü selektierbar, andernfalls entsprechend nicht.
Der "Max Button" besitzt darüber systembedingt die Eigenschaft, daß er wechselweise auch die Funktion
"Wiederherstellen" anbietet: Wird das Fenster "maximiert", wird anstelle des Symbols "Maximieren" das Symbol
für "wiederherstellen" (Rückkehr zur vorherigen Fenstergröße) angezeigt. Entsprechend dazu verhalten sich auch die
Einträge des Systemmenüs unseres Fensters.
System menu
Gibt an, daß das Fenster (links oben) eine Schaltfläche im Fensterrahmen besitzt, über die bestimmte
Fenstereigenschaften eingestellt werden können, das Fenster geschlossen werden oder die Fensterliste aufgerufen
werden kann.
Vertical/Horizontal scroll bar
Fügt dem Fenster eine vertikale bzw. horizontale Bildlaufleiste hinzu - und interessiert uns erst einmal nicht. ;)
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:
call beep 500,100
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:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org