VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
September 2002
[Inhaltsverzeichnis]
|
| Von Thomas Klein © September 2002 |
Liebe Leser, ich starte heute einmal einen Versuch eines etwas anderen
Artikels: Nachdem mir andere Autoren und die Herausgeber des Newsletters
Rückendeckung versprochen haben, wage ich den Versuch einer Serie zum
Thema "Einführung in REXX mit DrDialog".
Die Serie richtet sich in erster Linie an Leute, die entweder noch gar
keine Erfahrung mit REXX haben, oder solche, die zwar REXX mehr oder
weniger beherrschen, dann aber entweder nicht wissen, wie sie GUI-Programme
erstellen können, oder vor DrDialog und seiner Bedienung
zurückschrecken.
Ich tue das nicht aus reiner Menschenliebe - nein! Ich erwarte,
daß alle bis jetzt verzweifelten nicht-Entwickler "Hurra"
schreien und wir in spätestens vier Monaten eine wahre Flut von neuer
OS/2-Software vor uns haben...;)
Scherz beiseite: Ich dachte, daß es vielen vielleicht so geht, wie es
mir ging: Ein paar Ideen im Kopf, aber keine geeignete Programmiersprache
für OS/2 gelernt... tja. Das habe ich jetzt hinter mir und möchte
anderen die Chance bieten, es auch zu schaffen: Wenn ich das kann,
können Sie's auch! ;)
In all den Jahren, in denen ich OS/2 einsetze - es sind immerhin schon
bald 10 - habe ich mich immer erfolgreich davor drücken können,
mit REXX zu arbeiten. Es war für mich ein Buch mit sieben Siegeln. Ein
Kollege, der damals mein Interesse an OS/2 teilte und nicht so befangen
war, erzählte mir, wie unglaublich mächtig, cool und schnell REXX
sei - besonders für eine interpretierte Sprache. Und,
daß ich es mir einmal anschauen solle. Wahrscheinlich machte mich das
noch unsicherer.
Zu jener Zeit belief sich meine Programmiererfahrung auf COBOL, COBOL, und
nochmals COBOL. Okay - ich war verdammt gut darin, das kann ich ehrlich
zugeben. Und es hat mich redlich ernährt. Dennoch hat mich meine
COBOL-Sucht damals scheinbar davon abgehalten, neben REXX auch einmal solche
Sachen wie Java, C oder irgendetwas anderes anzuschauen. Das bereue ich
heute sehr. Mein Programmiersprachen-Portfolio hat sich seither lediglich
um VisualBasic erweitert, aber lassen wir das.
Im letzten Jahr konnte ich bei Warpstock Europa beobachten, wie leicht
es mit Hilfe der Pilotlink-Software ist, eine Sicherung meiner Palm-Daten
unter OS/2 durchzuführen. Das habe ich dann sofort übernommen -
und mußte plötzlich zu meiner Bestürzung feststellen,
daß alle im Gerät als "privat" geschützten Daten
in der Backup-Datei ganz prima einzusehen waren.
Da kam mir die Idee, ein kleines Skript zu schreiben, das nichts anderes
tun sollte, als automatisch nach dem Sichern der Dateien diese mittels ZIP
mit Paßwortschutz einzupacken. Der Archivname sollte das Tagesdatum
tragen. Obwohl ich bis zu diesem Zeitpunkt eigentlich noch nie wirklich mit
REXX gearbeitet hatte, wußte ich sofort, daß dies eine
"klassische Aufgabenstellung" für ein REXX-Skript sein
müßte.
Das stimmte auch. Außerdem war/ist VisualAge Basic grotteninstabil
und die Batch-Umgebung bot mir keine der benötigten Funktionen... es
mußte also REXX sein. Nun, was soll ich sagen? Es hat geklappt. Das
Programm läuft noch heute und mittlerweile habe ich REXX so ziemlich
im Griff. Glaube ich. ;)
Eine Sache, die mich mit der Zeit aber zu stören begann, war das
Fehlen einer Entwicklungsumgebung, die es mir auch erlaubte, graphische
Oberflächen in REXX zu entwickeln. Ich fragte mich, ob es nicht so
etwas wie Visual Basic auch für OS/2 gäbe. Nachdem ich VisualAge
für Basic bei ebay besorgt hatte und mir nach fünf Minuten klar
war, warum es dieses Produkt nicht mehr gibt, fiel mir plötzlich ein,
daß ich schon seit Jahren dieses seltsame "DrDialog" auf
meiner Platte herumliegen hatte und beschloß, es mir einmal genauer
anzuschauen.
Zugegeben, der Einstieg war nicht leicht für mich. Neben der Tatsache,
daß ich damals (und zum Teil noch heute) mit der Syntax von REXX zu
kämpfen hatte, gelang es mir nur äußerst mühsam, selbst
die elementarsten Dinge mit den DrDialog-Controls zu bewerkstelligen -
beispielsweise das Ausgeben eines Textes in einem Anzeigefeld über
entsprechende REXX-Anweisungen.
Irgendwann jedoch fiel der Groschen und das Konzept der DrDialog-Umgebung
wurde allmählich greifbar. Ich bin überzeugt, daß das ganze
nicht so kompliziert gewesen wäre, wenn nicht meine "MS'sche
VisualBasic-Denke" im Weg gestanden hätte. Tja - so ist's
halt: Ehe man sich versieht, haben die Redmonder einen schon
indoktriniert... oder heißt das "assimiliert"... na ja,
Schwamm drüber. ;)
Womit wir zum Kern kommen: Je weniger Sie im Vorfeld mit Objekten und REXX zu tun hatten - um so besser.;) Ein grundlegendes Verständnis für den Ablauf von Programmen sollten Sie allerdings schon mitbringen - es wäre aber noch nicht einmal unbedingt Voraussetzung. Als grobe Marschrichtung für diese Serie schwebt mir vor, daß ich Ihnen zunächst einmal erkläre, woher sie DrDialog bekommen, wie man es installiert und für was diese vielen Knöpfchen gut sind... Danach sollten wir schnell einen Crash-Kurs in GUI-Elementen (also den Bestandteilen einer graphischen Oberfläche) durchziehen, das eine oder andere Beispiel durchgehen, um die Funktionalität und das Verhalten der dafür verwendeten DrDialog-Objekte ("controls") zu verinnerlichen, bevor wir uns einer etwas komplexeren Aufgabe widmen. (Dabei fällt mir ein, daß ich noch immer keine vernünftigen Ideen für Beispielanwendungen habe...) Im weiteren Verlauf der Artikelreihe werden wir uns mit dem näheren OS/2-Umfeld aus REXX-Sicht beschäftigen - seinen es WPS-Objekte oder Ein- und Ausgabe von Dateien. Eventuell wird danach auch ein anderer Autor einen Exkurs zu den TCP/IP-Sockets (FTP, WWW), Interprozesskommunikation ("named pipes", "Semaphoren") oder auch in die "Königsklasse" (Datenbankprogrammierung) unternehmen. Mir ist es dabei wichtig, daß nach Möglichkeit nur kostenlose und frei erhältliche Bestandteile besprochen werden, damit es wirklich für jedermann möglich ist, der Serie zu folgen. Und damit fangen wir auch direkt an:
DrDialog ist EWS (employee-written software, von Mitarbeitern
geschriebene Software) der IBM. Es wurde 1993/94 von Herrn David C. Morrill
entwickelt, der zu jener Zeit (sofern meine Quellen stimmen) in den T.J.
Watson Forschungslaboratorien der IBM in Austin/Texas beschäftigt war.
Das besondere an EWS ist, daß sie von der IBM frei verfügbar
gemacht wurde, alle Urheberrechte jedoch bei der IBM bleiben, ohne daß
diese auch nur ansatzweise eine Art von Gewährleistung oder
Unterstützung für die Produkte bietet... nun ja, wenigsten
ist's umsonst.
DrDialogs Oberfläche und sämtliche begleitende Dokumentation ist
naturgemäß in englischer Sprache. Wenn Sie einmal Hilfe
benötigen und mit den Dingern nicht klar kommen, scheuen Sie sich
nicht, News-Gruppen mit Ihrem Anliegen zu überfallen. Selbst wenn dort
"englisch" als Forumssprache gewählt wurde, wird sich
bestimmt jemand finden, der sich um Sie kümmert. Lassen Sie sich von
dem einen oder anderen "hey-hier-nur-englisch"-Nörgler nicht
stören! Ignoranten gibt es überall. Setzen Sie sich durch - wenn
Sie ein fachliches/technisches Problem haben, sollte es nicht an der
Sprache scheitern! (Bisher habe ich allerdings noch nie erlebt, daß
man es jemandem übel nahm, wenn er eine bestimmte Sprache nicht
beherrschte.)
Sicherlich können Sie DrDialog von Hobbes laden - die
entsprechende Adresse steht am Ende des Artikels. Aber an dieser Stelle
möchte ich die Gelegenheit nutzen, Ihnen eine andere Quelle zu
empfehlen, denn dann wissen Sie auch sofort, daß Hilfe immer in der
Nähe ist...: Die Diskussionsgruppe "GuiObjectREXX" bei
Yahoo!Groups (ehemals egroups).
Obwohl ich bereits mehrmals alle Yahoo!-Groups nach dem Kriterium
"OS/2" durchsucht hatte, gehört diese erst seit kurzem zu
meinen Besuchsstellen. Das habe ich Chris Wohlgemuth zu verdanken, der
mich darauf aufmerksam machte. Ich hatte eine Frage und wußte nicht,
an wen ich mich wenden sollte, da auch ich auf einer OS/2-Insel in einem
Meer vom Windoofs lebe. Vom letztjährigen Besuch der Warpstock Europa
war mir aber im Hinterkopf geblieben, daß Chris auch mit DrDialog
"herummacht". Ich fragte ihn und er antwortete (und wies mich auf
die Gruppe hin). Ha! Da können Sie mal sehen, was man auf einer
Warpstock alles lernen kann, und daß auch Sie unbedingt einmal dahin
gehen und einfach mit den Leuten an den Ständen reden sollten. Die
freuen sich - versprochen!
Zurück zur Yahoo-Group: Sie benötigen hierfür keinen
Newsreader - es ist eine auf HTML basierende Webseite, wo man Mitteilungen
ansehen und Dateien "tauschen" kann. Hier treffen sich
Anfänger und "Profis" zur gegenseitigen Hilfestellung oder
Diskussion in Sachen DrDialog, VX-REXX, Vispro und so weiter... und zwar
für OS/2.
Okay, wirklich aktiv ist die Gruppe nicht gerade, aber es gibt eben nicht
so viele Fragen... noch nicht. ;) Es liegt an Ihnen, das zu ändern...
als ich kürzlich meine erste Frage als Neuling stellte, hatte ich noch
am selben Tag eine Antwort. Natürlich gibt es aber auch die bekannten
"normalen" News-Gruppen, in denen man Ihnen bei Problemen weiter
hilft; zudem ist in den de.* Gruppen auch Deutsch die
"Amtssprache".
[Anm.d.Red.: Auch der öffentliche Newsserver news.consultron.ca bietet eine Newsgruppe zum Thema Entwicklung von REXX-Programmen mit graphischer Oberfläche an: jakesplace.warp.visualrexx]
Um die Dateien herunterzuladen oder die Diskussionsbeiträge anzuschauen, müssen Sie kein Mitglied sein. Wenn Sie allerdings selbst eine Nachricht schreiben oder auf eine Nachricht antworten möchten, müssen Sie der Gruppe erst beitreten - keine Panik: Kostet nix. ;) Dafür haben die Yahoo!-Groups allerdings den Nachteil, daß öfters einmal eine Werbeeinblendungen auftaucht, bevor man sich zum eigentlichen Ziel weiterklicken kann.
Wenn Sie also die Internetseite http://groups.yahoo.com/group/GuiObjectREXX/ aufgerufen haben, wird Ihnen zunächst der Begrüßungsbildschirm mit den aktuellsten 5 Nachrichten der Gruppe angezeigt:
Am linken Rand finden Sie eine Übersicht der Forumsaktivitäten (messages, chat, files, photos...). Dort klicken Sie dann auf die Verknüpfung files und landen ein wenig später hier:
Laden Sie sich die Datei drdialog.zip herunter. Die Leser, die sich "hinter" einer feindlich gesonnenen (oder schlecht konfigurierten) Firewall befinden, werden diese Downloadmöglichkeit wahrscheinlich auch sehr begrüßen, da es sich nicht um FTP- sondern um HTTP-Download handelt...;)
...sind die folgenden Fixes, die ebenfalls direkt im "Files"-Verzeichnis der Diskussionsgruppe vorhanden sind:
DrDlgFix.zip (enthält ein geändertes Modul für die Erweiterungsmöglichkeit der Entwicklungsumgebung)
DrDlgRc.zip (enthält eine ältere Version des resource-Compilers rc.exe)
Das mit der älteren Version des Ressource-Compilers habe ich noch nicht ganz verstanden. Es handelt sich um eine Version vom 30.05.1995. Das ist mit Abstand die älteste Version, die ich in Warp 4 bislang gefunden habe unter Berücksichtigung des Exemplars in der GA-Version von Warp 4 und diversen Toolkits. Fragen Sie mich nicht, was es soll. Ich habe diese alte Version anweisungsgemäß (man könnte auch "treudoof" sagen) eingesetzt und bislang noch keine Probleme gehabt. Andere Anwender berichten, daß sie mit den neueren Versionen von RC.EXE ebenfalls keine Probleme haben - was soll's: Nehmen Sie diese alte Version, testen Sie's und wechseln Sie ggf. zurück zu einer griffbereiten neueren Version, falls es Probleme gibt.
Es gibt zwei Typen von Installationsprogrammen. Die einen kopieren
Dateien von einem Quellverzeichnis in ein anzugebendes Zielverzeichnis und
legen falls gewünscht/erforderlich entsprechende Ordner bzw.
WPS-Objekte an. Der andere Typ (zu denen das im ZIP-Archiv von DrDialog
enthaltene INSTALL.CMD gehört) erzeugt WPS-Objekte für
den aktuellen Ablageort der mitgelieferten Dateien.
Das bedeutet, daß Sie vor der Ausführung des
Installationsskriptes den Inhalt der ZIP-Datei bereits in das Verzeichnis
ablegen sollten, welches als endgültiges Programmverzeichnis für
DrDialog dienen soll. Starten Sie dann das Skript INSTALL.CMD,
welches alle weiteren Schritte durchführen wird... oder auch nicht, so
wie bei mir...:
Tja... kein Wunder, daß er die Objekte nicht anlegen konnte, denn
die angegebenen Dateien befinden sich nicht im Archiv. Ebenso die Datei
DREXAM.RAM, die einige Beispiele enthält. Normalerweise
würde man jetzt das Modul DrExam.RES über DrDialog
starten. Dieses würde über Aufruf des (ebenfalls nicht
enthaltenen) Archivierungsprogramm LOADRAM2.EXE die enthaltenen
Dateien entpacken und als Beispielprogramme im Programmverzeichnis ablegen.
Tja. Da scheint wohl damals noch etwas schief gelaufen zu sein...
jedenfalls habe ich bis jetzt vergeblich nach der DrExam.RAM
gesucht. Gut, ich habe nicht gerade sehr viel Energie in die Suche
gesteckt, aber dennoch: Seltsam.
Andererseits funktioniert das Ganze auch ohne diese Dateien - und Beispiele
bekommen Sie ja von mir. ;) Wie auch immer - das Installationsskript hat
dann den Ordner DrDialog auf der Arbeitsoberfläche erzeugt:
Jetzt kümmern wir uns noch um den Inhalt der beiden zusätzlichen ZIP-Dateien: Den Inhalt von DrDlgFix.zip (die Datei DRSAIDE.RES) kopieren Sie in das Installationsverzeichnis von DrDialog - es ersetzt die bereits vorhandene gleichnamige Datei. Auch der Inhalt der Datei DrDlgRc.zip (RC.EXE) wird in das Installationsverzeichnis von DrDialog kopiert.
Eigentlich würde ich an dieser Stelle Schluß machen und in den Urlaub verschwinden, aber das wäre wohl ziemlich gemein - schauen wir uns also im Vorfeld des zweiten Teils (in dem es dann "an's Eingemachte" geht) einmal näher an, womit Sie sich bis zum Oktober trösten können...
Starten Sie die Entwicklungsumgebung durch Doppelklick auf das Symbol "DrDialog" (ja, das mit der Hand). Es sollte dann ein Fenster wie das folgende erscheinen...:
DrDialog hat jetzt ein neues "Projekt" für Sie gestartet
und Ihnen auch schon eine leere Vorlage für einen Dialog
bereitgestellt. Das Fenster im Hintergrund stellt den
"Arbeitsbereich" für DrDialog dar. Alle Bestandteile von
DrDialog (Werkzeugleisten, Farbauswahlfenster, Codeeingabefenster, etc.)
können frei auf dem Bildschirm verteilt werden. Wenn Sie das jetzt mit
den bereits geöffneten Fenstern anderer Programme ein wenig mischen,
haben Sie im Handumdrehen die Übersicht verloren. Daher dient der
Arbeitsbereich dazu, alle nicht zu DrDialog gehörenden Fenster zu
"überlagern".
Interessehalber können Sie nun einmal den Menüpunkt Tools
anklicken. Nicht erschrecken... ja, es sind wirklich nur graphische
Schaltflächen vorhanden - kein Text. Klicken Sie auf das unterste
Symbol in der dritten Spalte von links - voilá: David C. Morril, der
Entwickler von DrDialog.
Das ist die Produktinformation zu DrDialog. In der Titelteile erkennen Sie die Versionsnummer. Viel mehr läßt sich hier nicht machen: Mit EDIT kehren Sie zurück in den Bearbeitungsmodus (schließt diesen Dialog) und mit HELP wird die Online-Hilfe zu DrDialog aufgerufen.
Bevor wir mit einem kleinen "Hallo Welt"-Beispiel beginnen, noch ein Hinweis zur Bedienung: Wie Sie sehen können, besitzt das leere Dialogfenster an seinen Ecken und Mittelpunkten des Rahmens kleine Griffpunkte.
Sie können sich jetzt unschwer vorstellen, daß man mit diesen
Markierungen die Größe des Fensters verändern kann.
Allerdings wird es nicht funktionieren, wenn Sie "wie
üblich" die Maustaste 1 dafür verwenden, denn damit
können Sie während der Entwicklung lediglich das
Entwicklungsprogramm steuern, d.h. Sie klicken Objekte an, die Sie
bearbeiten möchten oder treffen Menüauswahlen. Um aber die
Position oder Größe eines Elements zum Zeitpunkt der Entwicklung
zu verändern, müssen Sie Maustaste 2 verwenden.
Hinter diesem Umstand verbirgt sich eine ganz einfache Begründung:
Wären diese Operationen auch über die Maustaste 1 zu
tätigen, würde es Ihnen öfters passieren, daß Sie
versehentlich Ihre mühsam ausgerichteten Elemente auf dem Dialog
verschieben. So weit ich mich erinnern kann, hat Microsoft dieses Problem
bei Visual Basic 4 dadurch gelöst, daß jedes Objekt über
eine separate Eigenschaft "gesperrt" werden konnte und eine
Änderung in Größe und Position danach nur mittels
Werteingabe im Eigenschaftendialog oder durch "entsperren"
möglich war... eine tolle Idee - das beschleunigt die Sache
natürlich immens. Da gefällt mir die pragmatische Lösung der
Maustasten bei DrDialog um Lichtjahre besser.
Wenn Ihr Programm später einmal wirklich läuft dann verhält
sich der Dialog natürlich wie ein echtes Fenster, was das Ändern
von Größe und Position mittels Mausaktion angeht. Momentan
jedoch befinden Sie sich im Entwicklungsmodus - und da ist er auch nichts
anderes als eines von vielen "controls".
Alle Bestandteile, die Sie zur Gestaltung einer graphischen
Benutzeroberfläche (graphical user interface, "GUI")
verwenden können, werden als "controls"
("Steuerelemente") bezeichnet. Dazu gehören neben dem Dialog
wie wir ihn momentan sehen auch Befehlsschaltflächen
("Knöpfe" bzw. "Buttons"), Auswahllisten,
Texteingabefelder oder auch ein Menü und natürlich viele andere
mehr.
Wagen wir doch einmal den ersten Schritt in unserem Beispiel und spendieren
wir dem Dialog einen "OK"-Knopf. Was wir jetzt brauchen, ist eine
Liste oder ein Katalog der verfügbaren controls - kurz gesagt: Wie
kommen wir jetzt bloß an einen Knopf? Nun, viele Wege führen
nach Rom und drei Wege führen uns zum Knopf:
der offensichtliche:
Wählen Sie im Menü des Arbeitsbereichs den Eintrag
controls. Direkt der erste Eintrag steht für einen Knopf
(das P bedeutet "Pushbutton"). Wenn Sie diesen Eintrag
auswählen, hat DrDialog eine leere Vorlage für einen Knopf
bereitgestellt und erwartet nun von Ihnen (wie Sie am geänderten
Mauszeiger sehen können), daß Sie entscheiden, wo das Ding
hin soll. Dazu bewegen Sie den Mauszeiger an die gewünschte Stelle
des Dialogs und klicken. Fertig.
der schnelle:
Klicken Sie mit Maustaste 2 ("Kontextmenütaste") in
einem leeren Bereich des Dialogs - momentan haben Sie da ja noch viel
Auswahl <g>. Aus dem Menü wählen Sie den Eintrag
controls - Rest siehe oben.
der übersichtliche:
Das ist meine liebste Variante. Klicken Sie im Menü des
Arbeitsbereichs auf den Eintrag Tools (Werkzeuge). Herrjeh! Noch
mehr Bildchen... keine Panik, dazu kommen wir später.
Zunächst wählen Sie den Eintrag aus, der auch wie ein
Pushbutton aussieht (mittlerer Eintrag, rechte Spalte). Ohhh! Ahhh!
Na, das sieht doch super aus. Da sind sie ja alle - und unser Knopf ist ganz oben. Klicken Sie ihn ruhig einmal an - passiert nix, hm? Des Rätsels Lösung: Es funktioniert wie eine Schablone - mit Maustaste 2 klicken und auf die gewünschte Stelle im Dialog ziehen. So geschafft - jetzt direkt zu einem wichtigen Punkt: Klicken Sie noch einmal mit Maustaste 2 auf eine leere Stelle im Dialog. Ups - jetzt ist die Liste der controls weg. Und genau das ist ein Umstand, der mich anfangs zur Verzweiflung trieb: Warum so ein gutes Konzept mit Maustasten und abgekoppelten Fenstern, wenn die dummen Dinger immer wieder verschwinden? Aber: Manche Sachen brauchen eben länger, bis sie es in's Hirn schaffen. Vor allem bei mir. Beim Blättern durch die Online-Hilfe stieß ich auf einen Hinweis, wie man das ganz leicht verhindern kann. Jedes der Werkzeug- und Steuerungsfenster in DrDialog hat drei zusätzliche Einträge in seinem Systemmenü:
Auto Open: Wenn markiert, wird das jeweilige Fenster beim Start von DrDialog direkt mit aufgerufen
Auto hide: Wenn markiert, verschwindet das Fenster automatisch, wenn ein anderes geöffnet wird. Dummerweise gehören zu dieser Kategorie auch Kontextmenüs.
Float: Das Fenster wird auch im inaktiven Status "über" den Dialogen angezeigt, die gerade bearbeitet werden. (Nützlich z.B. beim Vergleichen von Größen- und Positionsangaben mehrerer hierfür anzuklickender controls.)
Die oben beschriebenen drei Wege schließen sich natürlich nicht gegenseitig aus, sondern stehen Ihnen immer zur Verfügung. Auch wenn Sie sich nicht für Variante 3 entscheiden, sollten Sie zu Beginn dafür sorgen, daß die Fenster zumindest nicht mit AutoHide eingestellt sind. Wenn Sie gerade dabei sind, die Entwicklungsgrundlagen zu lernen, werden Ihre Programme wahrscheinlich eher eine kleinere Dimension haben und Sie brauchen mehr Platz um alle die Fenster anzuzeigen, die Sie sonst nur nach längerem Suchen erst wieder finden würden. Später wissen Sie ja, wie Sie an die Klamotten heran kommen und brauchen eher mehr Platz für die gigantischen Oberflächen, die Sie dann entwickeln. ;)
Wenn Sie nun den Mauszeiger über den gerade abgelegten Knopf führen, wird am unteren Bildschirmrand in der Statuszeile des Arbeitsbereichs 101 (PUSHBUTTON) angezeigt.
Damit können Sie erkennen, wie der Name für Ihren Knopf lautet
- 101 ist ein vom System generierter Name, der auf der System-ID
des controls basiert. Jedes Element (Knopf, Dialog, etc.) wird vom System
mittels einer eindeutigen ID (Kennung) angesprochen. Sämtliche
Aktionen, die Sie mit einem control im Rahmen der Programmierung machen,
benötigen grundsätzlich die eindeutige Referenz des controls.
"Der Knopf da" reicht dem System eben nicht, um zu wissen, was
Sie meinen. ;)
Neben dieser etwas kryptischen Benamsung mittels ID können Sie die
Elemente auch über deren Namen ansprechen - der im Moment jedoch auch
nicht viel besser ist. Also ändern wir das: Klicken Sie mit Maustaste
2 auf die Schaltfläche und wählen Sie im Kontextmenü den
Eintrag Name. Es erscheint eine Eingabefeld. Geben Sie
"saghallo" (ohne Anführungszeichen) ein und bestätigen
Sie mit <ENTER>.
Wenn Sie nun mit der Maus über den Knopf fahren, erscheint in der
Statuszeile 101 - saghallo (PUSHBUTTON). Jetzt hat der Knopf auch
einen Namen. Was fehlt uns noch für's erste Beispiel?
Eine Textbox. Das ist ein reines Ausgabefeld, d.h. man kann darin keinen
Text eingeben. Besorgen Sie sich das control auf die gleiche Art und Weise
(oder einen anderen der 3 Wege), wie wir es vorhin mit dem Knopf gemacht
haben. Bei der Textbox ist das einfach: "Text" steht ja schon auf
dem Symbol drauf. Also her damit.
Und auch die Textbox soll einen Namen bekommen - schließlich ist
102 nicht gerade sehr vielsagend. Also wie eben: Klick mit
Maustaste 2 (Kontextmenü) auf die Textbox. Aus dem Menü
Name auswählen und diesmal nehmen wir
"ausgabe" - natürlich auch wieder ohne die
Anführungszeichen.
Einen Namen können Sie übrigens nicht doppelt vergeben - beim
Versuch, der Textbox den Namen saghallo zu geben, würde
DrDialog diese Eingabe sofort umwandeln in saghallo_2 und diesen
Wert in's Eingabefeld stellen... Sie könnten das dann akzeptieren
oder sich einen anderen Namen ausdenken. Zumindest wird hier nichts ohne
Ihr Wissen unter der Oberfläche heimlich umbenannt.
Jetzt hauchen wir dem ganzen ein wenig Leben ein, indem wir dem Programm mitteilen, was passieren soll, wenn der Anwender auf unseren Knopf drückt: In der Textbox soll dann "Hallo Welt!" stehen. Gut, das ist jetzt nicht unbedingt originell, aber für's erste muß das reichen. ;)
Jedes control besitzt neben seinen Eigenschaften auch die
Möglichkeit, auf Ereignisse zu reagieren. Im Beispiel unserer
"Schaltfläche" wäre dies das
"Click"-Ereignis. Dieses Ereignis wird vom System ausgelöst,
wenn die Schaltfläche betätigt wurde - egal, ob Mausklick oder
Leertaste.
Auch hier gibt es mehrere Möglichkeiten, zum richtigen Ziel zu kommen:
Am schnellsten geht es, wenn Sie einfach einen Doppelklick auf die
Schaltfläche machen. Ebenfalls relativ schnell gelangen Sie dorthin,
wenn Sie Maustaste 2 auf der Schaltfläche klicken, im Kontextmenü
den Eintrag Events (Ereignisse) auswählen und in dessen
Untermenü den Eintrag Click.
Mit dieser zweiten Methode können Sie übrigens sehr flink
herausfinden, welche Ereignisse für die einzelnen Typen von controls
existieren...
Aber gut - jetzt sind wir also hier gelandet:
Es ist so weit - Programmierung in REXX? Nicht ganz, denn es ist
"DrREXX". der Unterschied ist, daß es sich zwar um REXX
handelt, aber eine große Anzahl an Erweiterungen darin steckt, um mit
den graphischen Elementen arbeiten zu können.
Wir befinden uns nun an genau der Stelle, die vom System aufgerufen wird,
wenn unser Knopf geklickt wird...und was steht da? Nichts. Und genau das
wird auch passieren, wenn wir das Programm in seiner jetzigen Form laufen
lassen und auf den Knopf drücken würden: Nichts. Also sagen wir
dem Ding doch, was es gefälligst tun soll:
call ausgabe.text("Hallo Welt!")
Und das war es auch schon. Allerdings wird sich ein wenig trockene
Materie nicht verhindern lassen, um zu verstehen, was das bedeutet. Jedes
Objekt hat Eigenschaften. Das Objekt (oder control) "ausgabe" ist
eine Textbox und somit die Eigenschaft "text" - das ist das, was
es anzeigt.
Um eine Eigenschaft zu verändern, bedient man sich einer
"Methode". In diesem Fall heißt die Methode genauso wie die
Eigenschaft: "Text".
Mittels der Anweisung CALL rufen wir eine Methode auf. Die Methode
heißt "text" und wir übergeben der Methode den
Parameter "Hallo Welt!". Damit das Programm auch weiß,
wessen Methode wir hier aufrufen, geben wir noch den Namen des controls mit
an. "Ausgeschrieben" würde
call ausgabe.text("Hallo Welt!")
bedeuten:
RUFE für das control AUSGABE die Methode TEXT auf und übergebe ihr "Hallo Welt!"
So läuft das. Wenn Sie bis hierher mitgekommen sind, darf ich Sie
quasi in der Welt der objektorientierten Programmierung willkommen
heißen. ;) Scherz beiseite - es gehört natürlich noch etwas
mehr dazu, um in der OO-Welt zurecht zu kommen, aber hey! Sie haben die
ersten Begriffe gelernt und schon etwas damit zu Stande gebracht.
Obwohl - sollten wir es nicht erst einmal ausprobieren? Okay: Wählen
Sie aus dem Menü des Arbeitsbereichs den Punkt Tools und dann
das "laufende Männchen". Hiermit wird der Run-time
Monitor gestartet.
Was man damit alles machen kann und was "Run-Time" bedeutet, besprechen wir das nächste mal, denn Südfrankreich und zwei noch nicht gepackte Koffer warten auf mich und meine Frau. ;) Klicken Sie erneut auf das Symbol des laufenden Männchens - wow! Jetzt sieht Ihr Dialog schon anders aus, nicht wahr? Läßt sich wie gewohnt verschieben... na los, klicken Sie schon! ;)
Toll. Leider haben wir noch keinen Knopf, um das Programm zu beenden -
und Fensterknöpfe haben wir auch keine, weil wir nicht den
"geeigneten" Typ von Dialog verwendet haben. Machen Sie's
also für dieses mal mit <ALT-F4> oder Doppelklick auf
das Systemmenü.
Jetzt sind wir wieder im Entwicklungsmodus. Speichern Sie das Beispiel,
indem Sie aus den Menüpunkt File (Datei) verwenden, dann
Save (Speichern). Wählen Sie Laufwerk und Verzeichnis aus und
geben Sie einen Namen im oberen Feld ein. Eine Erweiterung brauchen Sie
nicht angeben, achten Sie aber darauf, daß unten rechts das Feld
Resource markiert ist:
Klicken Sie auf SAVE und das war's.
Bevor ich Sie in Ruhe herumfummeln lasse, noch eine kleine Hausaufgabe
für Oktober: Wie Sie bemerken, steht bereits beim Starten unseres
Programms "Text" in der Textbox. Dumm, hm? Hierbei handelt es
sich um einen Vorgabewert für den Inhalt des Feldes. Das ist dann
nützlich, wenn Sie zum Beispiel eine Eingabemaske erstellen
möchten, wo "Name:" vor dem Feld steht, in das der Anwender
seinen Namen eingeben soll. Damit brauchen Sie nicht zur Laufzeit erst alle
Textboxen mit Werten zu bestücken, sondern machen das schon ganz
komfortabel, während Sie die Oberfläche des Programms
zusammenstellen.
Wir möchten natürlich, daß unsere Textbox zu Beginn leer
ist. Dafür gibt es zwei Möglichkeiten:
Im Entwicklungsmodus geben wir als Vorgabe statt "Text" einfach gar nichts an.
Wenn der Dialog startet, verwenden wir eine entsprechende Methode...
Ich weiß, das ist ziemlich schwer, wenn man DrDialog gerade erst kennengelernt hat und einem jetzt schon der Kopf vor lauter Begriffen brummt. Versuchen Sie doch 'mal, ob Sie das Rätsel lösen können. Wenn Sie es nicht schaffen, spielen Sie einfach ein bißchen herum mit unserem Beispiel... und seien Sie nicht frustriert: Rom wurde auch nicht an einem Tag erbaut - egal, wie viele Wege dort hin führen mögen. ;)
Daten und Quellen:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org