ftp.uni-stuttgart.de/pub/systems/acorn//Acorn.tar/Acorn/acornet/fun/mags/hl-03-93.arc/!HL-03_93_Text_WIMP-Kurs

Text File | 1993-06-07 | 10KB | 191 lines

ÿÿÿÿÿÿÿÿÿÿ Programmieren des WIMP ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ


Teil 3.

In der letzten Folge haben wir den Anfang des Grundgerⁿstes besprochen, aus
dem unser WIMP-Program besteht. Zum Schlu▀ haben wir sogar das Icon auf die
Iconbar gebracht, und wenn Ihr jene Programmzeilen aus der letzten Folge
als Zeilen 201-208 in das Gerⁿse einfⁿgt, so habt Ihr schon ein Programm, das
in der Taskliste und auf der Iconbar erscheint, wenn es aus dem Desktop ge-
startet wird. Ihr k÷nnt das jetzt mal ausprobieren: gebt die paar Zeilen ein,
speichert das BASIC-Programm im !Program-Directory unter dem Namen !Runimage
ab, und startet das BASIC-Programm durch Doppelklick. Achtet aber darauf, da▀
Ihr auch das Spritefile aus der letzten Ausgabe erstellt und in das !Program-
Directory abgelegt habt. Wenn Ihr alles richtig gemacht habt, so erscheint
jetzt unten in der Iconbar Euer selbsterstelltes Icon.
 Das war aber auch schon alles, was unser Programm schon kann, es hat kein
Menu, und so kann man es auch nicht beenden! Auch nicht aus dem Taskmanager!
In der Tat hat sich das Programm jetzt fest bei Euch im Rechner eingenistet
und lΣ▀t sich nicht vertreiben (es sei denn, Ihr habt ein Programm zum
Task-Terminaten zur Hand).

 Nachdem wir also einen Reset durchgefⁿhrt haben, wollen wir uns einmal ⁿber-
legen, wie wir dieses Maleur beim nΣchsten Mal vermeiden k÷nnen.
Das Menu (mit dem 'Quit'-Eintrag) auf den Bildschirm zu bringen, erfordert
etwas Vorbereitung, und so will ich zuerst die andere M÷glichkeit hier ein-
fⁿhren: Wir wollen unser Programm jetzt so prΣperieren, da▀ eine Beendigung
ⁿber den 'Quit'-Eintrag im Taskdisplay m÷glich ist!

Wenn der Benutzer im Taskdisplay ⁿber einem Tasknamen Menu drⁿckt und beim
Eintrag ╗Task '....' ë½ auf den Pfeil rechts steuert, so erscheint ein Unter-
menu, in dem der 'Quit'-Eintrag steht. WΣhlt man diesen nun an, so schickt der
WIMP eine Nachricht an unser Programm, da▀ es sich doch bitte zu entfernen
hat, sprich: da▀ es beendet werden soll. Diese Nachricht erreicht unser
Programm natⁿrlich ⁿber unseren SYS "Wimp_Poll"-Befehl in Zeile 500.
 Der eventcode%, der hierbei zurⁿckkommt, hat die Nummer 17 bzw. 18 und hei▀t
User_Message. Wir schauen uns also unser Programm an der Stelle an:

   SYS "Wimp_Poll",0,pollblock% to eventcode%
   CASE eventcode% OF
    WHEN 0 :
    WHEN 2 :
    ...

Wir fⁿgen hier als letzte WHEN-Anweisung vor dem ENDCASE ein:

    WHEN 17,18 : PROCmessage_received

womit also beim Auftreten dieses Eventcodes 17 oder 18 (die identisch behan-
delt werden) unsere erste Prozedur aufgerufen wird.

Diese Prozedur wollen wir nun schreiben (ich benutze hier die Zeilen ab
3000 zur ▄bersichtlichkeit, obwohl im ganzen Programm keine Zeilennummern ge-
braucht werden, also v÷llig frei gewΣhlt werden k÷nnen):

 3000  DEFPROCmessage_received
 3010   action_code%=pollblock%!16
 3020   CASE action_code% OF
 3030    WHEN 0 : fertig% = TRUE
 3040   ENDCASE
 3050  ENDPROC

Das ist die ganze Prozedur, wie wir sie im Moment brauchen.
Was wird nun dort gemacht? Nun, wenn also der Task Manager unserem Programm
diese Nachricht schickt, dann schickt er gleich mit, was denn ⁿberhaupt los
ist, was gemacht werden soll. Das sind Sachen wie: wer hat die Nachricht ab-
geschickt (der WIMP), eventuelle Bezugsdaten (sozusagen my_ref, your_ref),
und natⁿrlich, was von unserem Programm erwartet wird.
 Diese Daten legt der WIMP in unserem dafⁿr vorgesehenen Speicherblock ab:
im pollblock%. Alle diese Daten liegen in 32bit-Words vor.
 Dieses letztere ist das einzige was uns fⁿrs erste interessiert: der Action
Code der Nachricht ist hier 0, das ist Message_Quit, und sagt dem Task, da▀
er sich unverzⁿglich aus dem Speicher zu entfernen hat.
 Andere Action Codes sind z.B. Message_ModeChange (ein Mode Change hat statt-
gefunden), Message_TaskInitialise (ein Task meldet sich gerade mit
SYS"Wimp_Initialise" beim WIMP an) u.v.a.m. Aber all dies soll uns nicht
interessieren. Der Action Code (hier also eine 0) befindet sich im pollblock%
an der Position 16. Also holen wir uns dieses Word und legen es in der
Variablen action_code% ab, wo wir es dann in einer CASE-Schleife abfragen:
 Es mag vielleicht ein wenig overpowered aussehen, wie dort fⁿr nur einen
Wert extra eine CASE...ENDCASE-Konstruktion bemⁿht wird, doch wollen wir das
Programm ja vielleicht noch etwas erweitern und andere Action Codes hinzu-
fⁿgen. Wenn wir also den Action Code 0 (Message_Quit) erkannt haben, setzen
wir einfach unsere Endkennung fertig% auf logisch wahr (TRUE) und beenden
diese Prozedur. Das Programm wird dann in Zeile 2100 nach dem ENDCASE fort-
gesetzt, wo dann auch gleich diese Variable fertig% ⁿberprⁿft wird. Und da sie
jetzt nicht mehr FALSE ist, sondern TRUE, wie es dort abgefragt wird, wird die
gro▀e REPEAT...UNTIL-Schleife nicht erneut durchlaufen, sondern der erste
Befehl nach der Schleife wird abgearbeitet, in unserem Programm also der
Befehl

   SYS "Wimp_CloseDown"

welcher den WIMP veranla▀t, diesen unseren Task aus der Liste der aktiven
Tasks zu streichen, ebenso aus der Liste des Task Managers und von der Icon-
Bar. Der Befehl funktioniert zwar so kurz, wie er dort steht, doch sollte man
Acorn-konform die korrekte Version verwenden, und zwar:

   SYS "Wimp_CloseDown",taskhandle%,&4B534154

wobei taskhandle% dieselbe Variable ist, die wir nach unserem Wimp_Initialise
vom WIMP zugewiesen bekommen haben, und &4B534154 ist wieder der ASCII-Text
"TASK", wie schon bei der Initialisierung.
 Danach ist unser Task als Task beendet, und wir mⁿssen nur noch dem BASIC-
Interpreter mitteilen, da▀ dieses Programm jetzt v÷llig beendet ist und
aus dem Speicher gel÷scht werden kann: Dafⁿr gibt es in BASIC ein spezielles
Kommando:

   END  (kennt wohl jeder?!)

Fⁿgen wir den END-Befehl nun also noch ein (als Zeile 2300), dann k÷nnen wir
das Programm wieder abspeichern und aus dem Desktop starten, und siehe da:
Es kann jetzt aus dem Taskdisplay heraus beendet werden!

Doch fΣllt im Taskdisplay gleich auf den ersten Blick eine unangenehme Sache
auf: Unser Program belegt einen riesigen Block an Speicher. Auf meiner RO3
4MB Maschine sind das 640K, das mag bei RO2 oder weniger Speicher anders sein.
Auf jeden Fall ist es wohl etwas zu viel fⁿr ein Programm das *nichts* tut.

Fⁿr Speicherreservierung gibt es den SYS "Wimp_SlotSize", mit dem man angeben
kann, wieviel Speicher ein Programm wohl braucht. Dies macht man aber
normalerweise nicht im BASIC-Programm, sondern im !Run-File, das wir jetzt
schreiben wollen:

Wir nehmen uns !Edit vor und erstellen ein Obey-File (Filetype &FEB) mit
folgendem Text:

   Set Program$Dir <Obey$Dir>
   Iconsprites <Program$Dir>.!Sprites
   Wimpslot -min 32K -max 32K
   Run <Program$Dir>.!Runimage

und speichern es unter dem Namen !Run in unser !Program-Directory ab.
Und da wir jetzt gerade !Edit geladen haben, wollen wir noch schnell ein
!Boot-File erstellen. Dieses !Boot-File soll so aussehen:

   Set Program$Dir <Obey$Dir>
   Iconsprites <Program$Dir>.!Sprites

Dies speichern wir dann unter dem Namen !Boot ab. Zusammen mit dem Spritefile
!Sprites haben wir damit alle essentiellen !-Files zusammen.

   !Boot   !Run   !Runimage   !Sprites

Nun zu den Zeilen: *Set Program$Dir <Obey$Dir> definiert eine neue Variable
mit Namen Program$Dir, die wir zwar jetzt noch nicht brauchen, die aber
spΣter von Nutzen sein wird. Der Inhalt dieser Variable ist jetzt der kom-
plette Pfad des Directories, in dem sich das Obey-File befindet, das gerade
ausgefⁿhrt wird. Wenn also z.B. das !Run-File ausgefⁿhrt wird, so ist die
System-Variable Obey$Dir genau der Pfad, wo das Programm bei Euch liegt.
Im Root-Directory auf einer Diskette mit Namen 'Diskette_1' in Laufwerk 0
wΣre das also:

   ADFS::Diskette_1.$.!Program

Damit fⁿllen wir also unsere eigene Variable Program$Dir und k÷nnen nun immer
auf unser Directory zugreifen, indem wir Program$Dir als Pfad benutzten, auch
wenn Obey$Dir lΣngst auf irgendein anderes Directory umgestellt ist, weil der
User ein anderes Obey-File gestartet hat.
 Mit *Iconsprites laden wir noch einmal explizit das Sprite in unserem Sprite-
File !Sprites in den WIMP-Sprite-Pool, was der WIMP zwar automatisch macht,
wenn diese Anweisung nirgendwo steht, doch kann es Situationen geben, in denen
es nicht geschieht, so z.B. wenn man mit der gedrⁿckten Taste CONTROL bzw.
STRG ein Directory ÷ffnet, was zuvor noch nie ge÷ffnet war. Probiert es aus,
die !Boot-Files werden nicht ausgefⁿhrt, und es werden keine Sprites geladen,
wodurch natⁿrlich alle Icons fehlen, und nur die Standard-Applikations-Icons
angezeigt werden. Wenn nun im !Run-File nicht die Sprites geladen werden, so
kann sich das Icon nicht auf der Iconbar installieren, weil der WIMP das
Sprite mit diesem Namen gar nicht kennt!
 Dann wird endlich mit *WimpSlot -min 32K -max 32K der Speicher reserviert,
den unser Programm verbraucht. Hier mⁿ▀te man am Schlu▀ ein wenig herum-
experimentieren, um einen genaueren Wert zu finden, 32K sind wohl auch noch
zu viel, m÷glicherweise reichen schon 8K, doch mu▀ auch der Platz berⁿck-
sichtigt werden, den die Variablen beanspruchen. Und zudem sind 8K-Schritte
sowieso das Minimum auf einer 1MB-Maschine, wΣhrend 32K auf einer 4MB-Maschine
der kleinstm÷gliche Block ist. Gibt man auf einer 4MB-Maschine einen kleineren
Wert als 32K an, so rundet der WIMP das auf 32K auf.
 In der letzten Zeile wird dann endlich das eigentliche Programm gestartet.

Nun k÷nnen wir also das !Program-Filer-Window schlie▀en und direkt das
Applikations-Icon (Euer selbstgemaltes) anklicken, woraufhin dann automatisch
das !Run-File und damit letztendlich auch das !Runimage-Programm gestartet
wird. Nun belegt unser Programm nur noch 32K an Speicher, was wohl ein wenig
angemessener ist.

                                                            -  Martin Willers -