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

Text File | 1993-03-26 | 11KB | 214 lines

ÿÿÿÿÿÿÿÿÿÿ Programmieren des Wimp ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ


Teil 1.


In diesem Kurs werde ich den Window-Manager von RISC OS beschreiben. Dieser
ist es ja bekanntlich, durch den alle diese Applikationen so sch÷n im
Multitasking-betrieb zusammenlaufen. Wie das funktioniert, und worauf man
dabei achten sollte, werde ich nach und nach in den Folgen dieses Kurses
erlΣutern.

Ein gro▀er Vorteil unseres Window-Managers (im Folgenden nur noch WIMP
genannt - von "Windows, Icons, Menus and Pointer") ist, da▀ er sehr vieles von
sich aus macht, und wir als Programmierer oft nur noch nahezu symbolisch das
Kommando geben, mit dem die Aktionen, die der WIMP schon vorgeplant hat, auch
ausgefⁿhrt werden. Demnoch sind viele M÷glichkeiten vorhanden, Mist zu bauen,
so da▀ z.B. kein Window erscheint, oder das Window nur ein schmaler Strich
ist, oder Untermenus nicht erscheinen, sondern eine Fehlermeldung aufkommt.

Dies soll uns aber nicht abschrecken, diese Fehler sind - auch wenn es
einem wΣhrend des Programmierens wie ein Werk des Teufels vorkommt - immer
logisch begrⁿndet, und wenn Ihr nicht gerade einen Fehler im RISC OS
aufgespⁿrt habt, so liegt der Fehler doch immer bei Euch.

Wer von Euch die PRMs hat (von RISC OS 2), dem wird vieles aus diesem Kurs
bekannt vorkommen, denn viel mehr als was in den PRMs steht, kann ich hier
auch nicht bringen; ich kann nur noch zusΣtzliche ErklΣrungen anbieten, wenn
die PRMs sich mal wieder schwammig ⁿber ein heikles Thema hinwegreden, oder
Beispiele geben, wenn in den PRMs ein komplexer Sachverhalt pl÷tzlich aufh÷rt
und sich in hΣmischen Zⁿgen die Buchstaben der nΣchsten Kapitelⁿberschrift
darbieten.

------------------------------------------------------------------------------
Wichtig sind bei der WIMP-Programmierung vor allem aber auch die Richtlinien
fⁿr WIMP-Applikationen, damit sich alle RISC OS-Applikationen bei bestimmten
Aktionen in etwa gleich verhalten - dies ist ja auch einer der viel
gepriesenen Vorzⁿge einer graphischen BenutzeroberflΣche!
------------------------------------------------------------------------------


Nun noch einiges Allgemeines:
Ich werde hier alle Beispielprogrammabschnitte in BASIC geben, da es
wirklich jeder Archimedes-Benutzer besitzt und auch gegenⁿber Assembler den
Vorteil hat, da▀ es leichter zu ⁿbersehen ist, sowie da▀ es mehr Leute
verstehen, wobei BASIC fⁿr viele Anwendungen geschwindigkeitsmΣ▀ig v÷llig
ausreicht - viele bekannte Applikationen sind, assemblergestⁿtzt, in BASIC
geschrieben, so z.B. !Translatr, !Creator, !FormEd; bei vielen anderen ist
das gesamte WIMP-Interface in BASIC, der Rest dann in Assembler oder C
geschrieben, so z.B. !ProArtisan oder !Atelier !!!!.
Demnoch m÷chte ich dafⁿr plΣdieren, m÷glichst BASIC bei der endgⁿltigen
Version Eurer Programme zu vermeiden, denn es macht einen schlechten
Eindruck, sieht unprofessionell aus und, was am wichtigsten ist, man kann
dann zu leicht an Euren Programmen herumpfuschen, was nicht sein sollte,
wenn Eure Programme korrekt geschrieben sind und auf allen RISC OS-Rechnern
laufen.

Nun aber fⁿr die Assemblerprogrammierer ein sehr interessanter Aspekt der
WIMP-Programmierung, der sehr zur Vereinfachung des Programmes beitrΣgt:
Der WIMP sorgt ja dafⁿr, da▀ alle Applikationen an das obere Ende des
Applikation-Speicherbereiches geladen werden, was zur Folge hat, da▀ die
Anfangsadressen der Programme nicht bekannt sind und deshalb das gesamte
Programm relocable programmiert werden mⁿ▀te, d.h. ausschlie▀lich mit
relativen Addressierungen. Dies ist jedoch nicht so, denn der WIMP sorgt
dafⁿr, da▀ ein jedes Programm bei seiner Ausfⁿhrung "denkt", es liege bei
&8000, und dementsprechend absolute Addressierungen auf diesen Bereich
durchfⁿhren kann, welche dann umgerechnet werden und auf den richtigen
Bereich, wo das Programm liegt, angewendet werden. Ich will micht hier gar
nicht in Details verlieren, es ist ein Feature des MEMC, da▀ er
Speicherbereiche "ummappen" kann, um diesen Effekt zu erreichen.

Die Funktionen des WIMPs werden mit Betriebssystemaufrufen benutzt, den sog.
Software Interrupts, kurz SWI. Aus BASIC werden sie mit dem Befehl SYS
aufgerufen. Von diesen Betriebssystemaufrufen gibt es eine ganze Menge, in
RISC OS 2 sind es ⁿber 400; den WIMP betreffend immerhin immer noch 52 SWIs,
die dann immer noch mehrere Unter-Funktionen innehaben. Mit diesen SWIs wird
der ganze WIMP gesteuert.
Jeder SWI hat eine Nummer (die WIMP-SWIs von &400C0-&400F3), und weil diese
Nummern extrem schlecht zu merken sind, auch noch einen beschreibenden Titel,
den man anstelle der Nummber benuzten kann. So hei▀t z.B. der SWI &400C5
"Wimp_OpenWindow", wobei das "Wimp_" hier das Prefix ist, welches angibt, von
welchem Teil des Betriebssystems dieser SWI ist. Das Prefix "Wimp_" hei▀t
dann hier, da▀ er von dem Module "Window Manager" ist. Alle SWIs, die den
WIMP ansprechen, haben das Prefix "Wimp_", und analog haben z.B. alle SWIs,
die den Fontmanager ansprechen, das Prefix "Font_". Nach diesem Prefix folgt
dann der eigentliche SWI-Name, der eigentlich auch meist schon ganz gut
erklΣrt, was denn der SWI eigentlich macht. So ÷ffnet der
    SWI "Wimp_OpenWindow"
auch ein Window, und man mu▀ nur noch sagen, welches Window, wo auf dem
Bildschirm und wie gro▀. Diese Parameterⁿbergabe erfolgt in Assembler in den
Registern, wobei meist in R1 der Pointer zu einem Block ⁿbergeben wird, wo
dann die gewⁿnschten Informationen stehen, da doch oft mehr als nur die
16 Werte ⁿbergeben werden, die in die Register passen wⁿrden.
In BASIC hingegen folgen die Parameter durch Kommata getrennt dem SWI-Namen,
was dann z.B. so aussieht:

SYS "Wimp_Initialise",200,"TASK","Application"  TO  variable1%,variable2%

Dieser SWI, der das eigene Programm (hier mit dem Namen "Applikation") dem
WIMP anmeldet, braucht 3 Informationen, um seine Aufgabe zu erfⁿllen; diese 3
Informationen werden also mit ⁿbergeben. Aber der SWI tut noch mehr, er
ⁿbergibt nΣmlich noch wieder Informationen zurⁿck an das Programm, die dann
in den angegebenen Variablen nach dem "TO" abgelegt werden. Die Ergebnisse
k÷nnen dann angeschaut und verwertet werden.



Ein Programm braucht nicht mit dem Hintergedanken "Multitasking" geschrieben
zu werden, nahezu nichts in einem Programm deutet darauf hin, da▀ noch andere
Programme gleichzeitig laufen. Wenn ein Programm korrekt geschrieben worden
ist, dann lΣuft es auch, egal ob noch andere Programme laufen, oder es das
einzige Programm im Speicher ist. Die gro▀e Ausnahme ist hier der
SWI "Wimp_Poll", der die einzige Verbindung mit der Au▀enwelt darstellt. Wird
dieser SWI nicht benutzt, so lΣuft das Programm auch nicht multi-tasking,
sondern single-tasking, d.h. alle anderen aktiven Programme werden
eingefroren, bis doch wieder der SWI "Wimp_Poll" benutzt wird oder aber das
Programm beendet wird. Dieser Umstand hat zur Folge, da▀ man zu einem
sinnvollen Umgang mit diesem SWI finden sollte; ⁿbermΣ▀iges Anwenden hat zwar
Multitasking in allen Situationen zur Folge, verlangsamt aber das Programm
doch z.T. sehr; spΣrliches Anwenden hat Geschwindigkeitszuwachs, dafⁿr aber
spartanisches Multitasking zur Folge. Bestes Beispiel sind wohl die
File-Operations: wenn man von seinem Programm aus ein langes File (200KBytes)
nachlΣdt, so kann man dies in einem Stⁿck tun, kann aber wΣhrend der ganzen
Ladezeit (von Diskette ja noch recht lang) nichts tun; man kann aber auch die
einzelnen Sektoren von Diskette laden, dafⁿr aber dann zwischen den Sektoren
ein "Wimp_Poll" einfⁿgen, womit auch wΣhrend des Ladens ein Multitasking
gewΣhrleistet ist, wie es z.B. bei RISC OS 3 z.B. beim Kopieren vorhanden ist.
Es liegt nun am Programmierer, welcher der beiden M÷glichkeiten er wahrnimmt
und welche der beiden ⁿberhaupt sinnvoll ist. Zudem ist die zweite immer
schwieriger zu handhaben, es mⁿssen Vorsichtsma▀nahmen getroffen werden, was
beim Laden z.B. nicht gemacht werden darf etc.


Nun aber m÷chte ich schon anfangen mit dem ersten Beispielprogramm, welches
das Gerⁿst darstellt, auf das alle WIMP-Applikationen basieren, eine
Schleife, die so oder in Σhnlicher Form in allen WIMP-Programmen zu finden
ist. Es geht hier um die sog. Polling-Schleife, die die einzige Verbindung
nach au▀en darstellt:


-----------------------------------------------
 1  SYS "Wimp_Initialise"
 2  DIM pollblock% 256
 3  fertig% = FALSE

 4  REPEAT
 5   SYS "Wimp_Poll",0,pollblock% TO eventcode%
 6   CASE eventcode% OF
 7    WHEN 0 : do nothing
 8    WHEN 2 : open window
 9    WHEN 3 : close window
10    WHEN 6 : mousebutton was pressed

      ...

20   ENDCASE
21  UNTIL fertig% = TRUE

SYS "Wimp_CloseDown"
-----------------------------------------------

Der SWI in Zeile 1 meldet die Applikation als Task beim WIMP an.
In Zeile 2 wird dann ein Speicherblock von 256 Bytes reserviert, der dann zum
▄bergeben aller WIMP-Parameter benutzt wird. Die Anfangsadresse wird in der
Variablen pollblock% abgelegt.
In Zeile 3 wird dann die Endkennung auf logisch falsch gesetzt. Dies kann man
vielfΣltig l÷sen, diese M÷glichkeit ist jedoch recht ⁿberschaubar, weshalb ich
sie hier vorfⁿhre. Soll das Programm beendet werden, so wird einfach nur die
Variable fertig% auf logisch wahr gesetzt (TRUE), und beim nΣchsten
Schleifendurchlauf trifft die UNTIL-Bedingung aus Zeile 21 zu, und das
Programm wird beendet.
Zeile 4 und Zeile 21 bilden dann die Schleife, die ewig durchlaufen wird, bis
einmal vom Programm aus die Variable fertig% auf TRUE gesetzt wird.
Zeile 5 ruft dann die Pollroutine auf, ⁿbergibt u.a. die Adresse des
Speicherblocks, in den etwaige Informationen geschrieben werden sollen, und
verlΣ▀t dieses Programm. Jetzt ist die Zeit, in der die anderen Programme
durchlaufen werden, jedes bekommt einmal die Kontrolle, einige machen
vielleicht gar nichts, andere berechnen vielleicht ganze Fraktale, aber
irgendwann kehrt der WIMP sich wieder unserem Programm zu, z.B. wenn ⁿber
unserem Icon auf der Iconbar (das wir jetzt noch nicht installiert haben,
aber gehen wir mal davon aus, wir hΣtten eines) der Benutzer die mittlere
Maustaste gedrⁿckt hΣtte, um ein Menu auf den Bildschirm zu bringen. Nun
stellt der WIMP fest: es wurde ein Mausklick getΣtigt. Diese Information
wandelt er in eine Zahl um (die Zahl 6), nennt sie "eventcode" und ⁿbergibt
sie an die Variable "eventcode%", die bei uns diese Information auffangen
soll. Nun ist also eventcode%=6. Mit der CASE...ENDCASE-Konstruktion wird
jetzt abgefragt, welchen Wert eventcode% innehat. Hier ist es 6, also wird
der Befehl hinter "WHEN 6 :" abgearbeitet. ▄blicherweise steht dort nur ein
Unterroutinenaufruf, der dann den Rest erledigt.
Nach der Unterroutine fΣhrt das Programm fort, kommt zum UNTIL fertig% = TRUE,
stellt fest, da▀ dies nicht der Fall ist, und kehrt zum ersten Befehl der
Schleife zurⁿck, dem SWI "Wimp_Poll", verlΣ▀t also unser Programm wieder, um
auch die anderen Programme zu Wort kommen zu lassen.

Haben wir jedoch in unserer Unterroutine die Variable fertig% auf TRUE
gesetzt, so fΣhrt das Programm auch fort und stellt beim UNTIL fest,da▀ diese
Aussage zutrifft und arbeitet den nΣchsten Befehl ab:

SYS "Wimp_CloseDown"

Dieser Befehl beendet dieses Programm als Task, schlie▀t automatisch alle
dazugeh÷rigen offenen Windows, l÷scht das Programm aus der Liste der aktiven
Tasks und schlie▀lich auch aus dem Speicher.
Das ist genau die Wirkung, die der "Quit"-Eintrag eines Applikation-Menus
erzielt.


                                                            - Martin Willers -