home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Computer Club Elmshorn Atari PD
/
CCE_PD.iso
/
pc
/
0600
/
CCE_0620.ZIP
/
CCE_0620.PD
/
WINX22
/
WINXPROG.GER
< prev
Wrap
Text File
|
1993-10-17
|
15KB
|
314 lines
HINWEISE FÜR ENTWICKLER (zur WINX Version 2.2 [17.10.1993])
Diese Datei enthält Hinweise zum Umgang mit der Fensterverwaltung des
GEM im allgemeinen und der von WINX im speziellen.
- In der Testphase eigener Programme sollte man WINX immer so
konfigurieren, daß fehlerhafte wind_-Aufrufe angezeigt werden.
Die einzige wind_-Funktion, die man mit einer ungültigen
Fensterkennung aufrufen darf ohne eine Fehlermeldung zu
bekommen, ist übrigens wind_get( WF_OWNER).
- wind_get()/wind_set()
Diese beiden Funktionen liefern jetzt im Fehlerfall den Wert
0, sonst 1 (bisher wurde immer der Wert 1 zurückgegeben).
Ein Fehler wird z.B. gemeldet, falls ein WF_-Modus nicht
implementiert ist, bzw. ein Funktionsaufruf mit einer ungültigen
Fensterkennung erfolgte. Beim Start eines Programms sollte
man zunächst prüfen, ob wind_get() einen sinnvollen Rückgabe-
wert liefert.
#define WF_RETURN 1
retok = (wind_get( 0, WF_RETURN, &ign, &ign, &ign, &ign) == 0);
Es ist unkritisch unter den bisherigen GEM-Versionen einen
unbekannten WF_-Modus zu benutzen, da dieser ignoriert wird.
- wind_get( 0, WF_WINX(=22360='WX'), &version, &date, &func_h, &func_l)
Liefert WF_WINX, falls WINX >= 2.1 installiert ist, sonst 0.
version: Bit [15..12] Beta-Kennung
Bit [11.. 8] Major (momentan 2)
Bit [ 7.. 4] Minor (momentan 1)
Bit [ 3.. 0] Interne Kennung
date: Erstellungsdatum im GEMDOS-Format
func_h/l: High- und Lowword der Adresse der WINX-Cookiefunktion,
falls der WINX-Cookie intalliert ist, sonst NULL.
- wind_get( 0, WF_WINXCFG(=22361), &gmask, &gflags, &lmask, &lflags)
Liefert die für die Applikation gültigen Konfigurationsschalter.
gmask: Ein gesetztes Bit bedeutet, daß der Schalter existiert.
gflags: Globale Konfigurationsschalter. Ein Schalterwert ist nur
dann gültig, wenn das entsprechende Bit in gmask gesetzt
ist (Bit 0 entspricht Schalter 1, etc.).
lmask: Ein gesetztes Bit bedeutet, daß der Schalter existiert.
lflags: Lokale Konfigurationsschalter. Ein Schalterwert ist nur
dann gültig, wenn das entsprechende Bit in lmask gesetzt
ist (Bit 0 entspricht Schalter 1, etc.).
Obwohl man die Konfigurationsschalter mit dieser Funktion abfragen
kann, sollte man trotzdem möglichst darauf verzichten. Der
Funktionswert muss unbedingt geprueft werden!
- wind_get( rsv0, 22362-22400, &rsv2, &rsv3, &rsv4, &rsv5)
wind_set( rsv0, 22362-22400, rsv2, rsv3, rsv4, rsv5)
Undokumentierte bzw. reservierte WINX-Erweiterungen.
- wind_get( 0, WF_TOP, &topwin, &topowner, &belowwin)
Liefert die Kennung des obersten Fensters im Fensterstapel.
Ist kein Fenster offen, enthält topwin 0.
- wind_get( win, WF_OWNER(=20), &owner, &isopen, &abovewin, &belowwin)
Liefert Informationen über ein Fenster. Das Fenster kann auch
geschlossen sein (d.h. es ist nicht im Fensterstapel), bzw.
gar nicht existieren (dann liefert die Funktion 0).
- wind_set( win, WF_BOTTOM(=25), 0, 0, 0, 0)
WF_BOTTOM stellt ein Fenster im Fensterstapel nach hinten. Das
Fenster muß offen sein.
- wind_get( 0, WF_BOTTOM(=25), &bottomwin)
Liefert die Kennung des untersten Fensters im Fensterstapel.
Ist kein Fenster offen enthält bottomwin -1 (NOWINDOW).
- wind_set( win, WF_BEVENT(=24), 0/1, 0, 0, 0)
WF_BEVENT sorgt dafür, daß der Besitzer des Fensters beim Klick
in das Fensterinnere keine WM_TOPPED-Nachricht erhält, wenn das
Fenster nicht aktiv ist. Stattdessen wird ein MU_BUTTON aus-
gelöst, falls der Besitzer eine entsprechende Anforderung bei
evnt_multi() gestellt hat.
- wind_get( win, WF_BEVENT, &v1, &v2, &v3, &v4)
Liefert den BEVENT-Status des Fensters im Bit 0 von v1.
- wind_get( win, WF_NEWDESK, &treehig, &treelow, &treeroot, &ign)
Liefert den aktuellen Hintergrundbaum und sein Wurzelobjekt.
ACHTUNG: Bisher ist nicht dokumentiert wie man diese Information
nutzen kann.
- wind_get( win, WF_COLOR, &obj, &col1, &col2);
Liefert die Farben eines Objekts des Fensterrahmens.
ACHTUNG: obj muß in intin[ 2] übergeben werden. contrl[ 1] muß
auf 3 vergrößert werden!
- wind_get( 0, WF_DCOLOR, &obj, &col1, &col2);
Liefert die Defaultfarben eines Objekts des Fensterrahmens.
ACHTUNG: obj muß in intin[ 2] übergeben werden. contrl[ 1] muß
auf 3 vergrößert werden!
- Position und Größe des ROOT-Objekts eines eigenen Hintergrund-
baums, der mit wind_set( WF_NEWDESK) angemeldet wird, sollten
vorher mit einen Aufruf von
wind_get( 0, WF_WORKXYWH, &deskx, &desky, &deskw, &deskh)
bestimmt werden (also nicht mit WF_CURRXYWH).
- wind_set( win, WF_CURRXYWH, x, y,w, h), wind_open( win, x, y, w, h)
Nach diesen Operationen sollte man immer mit
wind_get( win, WF_CURRXYWH, &currx, &curry, &currw, &currh)
die tatsächlichen Werte ermitteln, da das AES Position und Größe
eventuell automatisch korrigiert hat.
- wind_set( win, WF_NAME, text), wind_set( win, WF_INFO, text)
Man sollte keine Annahmen darüber machen, ob die Fensterverwaltung
eine Kopie des Strings <text> anlegt oder nur den Zeiger ablegt.
<text> sollte nach dem Aufruf der Funktion nicht mehr verändert
werden.
- [WM_BOTTOMED(=33) apid 0 win 0 0 0 0]-Nachricht
Diese Nachricht benutzt der SCRENMGR um die Applikation aufzu-
fordern, das Fenster mit
wind_set( win, WF_BOTTOM, 0,0,0,0)
nach hinten zu stellen.
Nach dieser Aktion sollte die Applikation NICHT explizit ein
eigenes Fenster aktivieren. Hat die Applikation mehr als ein Fenster
offen, und will sie deren Reihenfolge nicht ändern, sollte sie
alle eigenen Fenster nach hinten stellen (praktisch wäre es,
wenn das AES dafür eine Funktion anbieten würde...).
- inverse 'Fenster wechseln' Funktion
Ein Applikation die diese Funktion anbietet, sollte dabei
ihr oberstes Fenster mit WF_BOTTOM nach hinten stellen und
das jetzt oberste in der eigene Fensterliste mit WF_TOP
aktivieren (um sicherzustellen, daß die Applikation die
Tastaturkontrolle behält.
- [WM_UNTOPPED(=30) apid 0 win 0 0 0 0]-Nachricht
[WM_ONTOP(=31) apid 0 win 0 0 0 0]-Nachricht
Diese Meldungen werden dazu benutzt, um Applikationen über eine
Veränderung des aktiven Fensters zu informieren. WM_UNTOPPED
wird nach dem Öffnen bzw. Aktivieren eines Fensters an den
Besitzer des vorher aktiven Fensters geschickt. WM_ONTOP
wird nach dem Schließen bzw. Deaktivieren des aktiven Fensters
an den Besitzer des danach aktiven Fensters geschickt.
Zum Zeitpunkt der Ankunft der Nachricht kann sich der Fenster-
stapel bereits wieder verändert haben.
- [WM_ARROWED apid 0 win WA_aaa speed_aaa WA_bbb speed_bbb]
Die WM_ARROWED-Nachricht wurde in WINX erweitert um - über das neu
Kontrollelement 'Scrollbox' - in beliebige Richtungen mit variierbarer
Geschwindigkeit scrollen zu können.
Die Auswertung könnte in C etwa folgendermaßen aussehen:
switch (mesag[ 0]) {
case WM_ARROWED:
scrollx = scrolly = 0;
speed = (mesag[ 5] < 0) ? -mesag[ 5] : 1;
switch (mesag[ 4]) {
case WA_UPLINE: scrolly = -speed; break;
case WA_DNLINE: scrolly = speed; break;
case WA_LFLINE: scrollx = -speed; break;
case WA_RTLINE: scrollx = speed; break;
case WA_UPPAGE: scrolly = -(speed * linesperpage); break;
case WA_DNPAGE: scrolly = (speed * linesperpage); break;
case WA_LFPAGE: scrollx = -(speed * linesperpage); break;
case WA_RTPAGE: scrollx = (speed * linesperpage); break;
};
if (mesag[ 7] < 0) {
speed = -mesag[ 7];
switch (mesag[ 6]) {
case WA_UPLINE: scrolly = scrolly - speed; break;
case WA_DNLINE: scrolly = scrolly + speed; break;
case WA_LFLINE: scrollx = scrollx - speed; break;
case WA_RTLINE: scrollx = scrollx + speed; break;
case WA_UPPAGE: scrolly = scrolly - (speed * linesperpage); break;
case WA_DNPAGE: scrolly = scrolly + (speed * linesperpage); break;
case WA_LFPAGE: scrollx = scrollx - (speed * linesperpage); break;
case WA_RTPAGE: scrollx = scrollx + (speed * linesperpage); break;
};
};
if ((scrollx != 0) || (scrolly != 0)) {
scroll_window( mesag[ 3], scrollx, scrolly);
};
};
ACHTUNG: Diese Erweiterung wurde von ATARI noch nicht abgesegnet!
Sie ist aber kompatibel zu den bisherigen TOS-Versionen [Stand 6/93]
- wind_update() speicherte bisher Applikationen, die auf die
Update-Kontrolle warteten, in einer LIFO-Warteschlange (d.h.
der letzte der die Update-Kontrolle anforderte erhielt sie als
nächster). WINX benutzt hingegen eine FIFO.
- wind_update( BEG_UPDATE|0x100); wind_update( BEG_MCTRL|0x100);
WINX implementiert den 'check and set mode' von AES 4.0.
Dabei wird die Update-Kontrolle nur noch übernommen, falls
keine andere Applikation die Kontrolle hat bzw. die eigene
Applikation besitzt. Kann die Applikation die Kontrolle nicht
übernehmen, liefert die Funktion den Wert 0.
- wind_update( END_...) wird jetzt auf Unterlauf geprüft und im
Fehlerfall mit einem Alert gewürdigt.
- wind_new() loeschte bisher immer rigoros alle anstehenden
Update-Anforderungen. WINX interpretiert wind_new() als Aufräum-
funktion für eine abgestürzte Hauptapplikation und löscht daher
auch nur noch deren Update-Anforderungen. Die Neuinitialisierung
der Fensterverwaltung führt WINX jetzt unter Update-Kontrolle
durch, dadurch ist garantiert, daß die Fenster nicht verschwinden
während ein ACC die Update-Kontrolle besitzt.
- appl_getinfo()
Ab der Version 2.2 stellt WINX die AES-Funktion appl_getinfo() über
den Trap 2 zur Verfügung. Die momentan von WINX implementierten Sub-
funktionen 11 und 12 liefern als Funktionswert 1, die anderen 0.
ACHTUNG: Bevor man appl_getinfo() aufruft, muß man prüfen, ob das
AES diese Funktion unterstützt, da ansonsten ein Fehlermeldungsalert
ausgegeben wird. appl_getinfo() wurde von ATARI ab der AES-Version
4.00 implementiert. Momentan kann man z.B. folgende Testfunktion
benutzen:
#define WF_WINX 22360
int has_appl_getinfo( void)
/* Liefert TRUE, falls das AES appl_getinfo() bereitstellt */
{
static int hagi = -1;
int ign;
if (hagi < 0) {
hagi = ((_GemParBlk.global[ 0] >= 0x400) ||
(wind_get( 0, WF_WINX, &ign, &ign, &ign, &ign) == WF_WINX));
};
return( hagi);
} /* has_appl_getinfo */
- Echtzeitaktionen
Während einer Echtzeitaktion gibt der SCRENMGR die Ausgabekontrolle
ab. Die Mauskontrolle bleibt hingegen beim SCRENMGR (allerdings kann
sie temporär von einer Applikation übernommen werden). Während der
Echtzeitaktion wird die Applikation, der das zugeordnete Fenster
gehört, gezwungen mehr Zeit an das AES abzugeben.
- Musterbezugspunkt
Ist die Schalter eingeschaltet, sorgt WINX dafür, daß bei der
Ausgabe eines GEM-Objekts der Bezugspunkt eines Füllmusters in
der linken oberen Ecke des Objekts liegt (statt wie bisher bei
0/0). Nur so ist es z.B. möglich, nach dem Verschieben eines
Fensters, die Ausgabe auf die vorher unsichtbaren Teile der
Objekte zu beschränken.
- Redraw von Fenstern
Die Fensteroperationen wind_open(), wind_set( WF_CURR|WF_TOP), etc.
senden Redraws für die Bereiche des Fensters, die neu sichtbar
werden. Einige AES Version senden statt dieser Teilredraws Redraws
für das komplette Fenster (dies ist unter Umständen notwendig,
damit Füllmuster, etc. zusammenpassen). Will/muß man gleichzeitig
zur Fensteroperation den Fensterinhalt ändern, sollte man sich
selbst mit appl_write() ein Komplettredraw schicken, welches dann
mit den von der Fensterverwaltung erzeugten Redraws vereinigt wird.
Unter AES 4.00 werden die Redraws momentan nicht vereinigt, daher
kann man für dieses AES entweder eine Sonderbehandlung implementieren
oder hoffen, daß ATARI irgendwann zur alten Lösung zurückfindet.
- Der WINX-Cookie enthält als Wert einen Zeiger auf eine Funktion
über die bestimmte Eigenschaften der akt. WINX-Version erfragt
werden können.
long cdecl winxfunc( short funcid, ...); /* PureC-Syntax */
Die Parameter werden auf dem Stack übergeben, der Resultatwert
wird in D0 zurückgegeben. Wenn es nicht anders angegeben ist,
bedeutet der Resultatwert -1L, daß die Funktion nicht existiert
bzw. momentan nicht ansprechbar ist.
Einige Funktionen sind für die interne Kommunikation reserviert.
Außer dem Register D0 werden keine weiteren Register verändert.
Der Zugriff auf einige internen Variablen von WINX ist für
TSR-Programme möglich. Diesbezügliche Informationen können
beim Autor bezogen werden.
- Zuordnung der Mausklicks zu den Applikationen
Mausklick || vorderstes Fenster | hinteres Fenster | Desktop | Menü |
|| Rahmen Inneres | Rahmen Inneres | | |
----------++--------------------+--------------------+----------+----------+
|| |
|| AES Versionen <= 3.20 |
|| |
links || SCRENMGR Besitzer | SCRENMGR SCRENMGR | Besitzer | SCRENMGR |
|| | | | |
rechts || Besitzer Besitzer | BdvF BdvF | BdvF | BdvF |
|| |
|| MultiTOS 1.01 (Stand 5/93) |
|| |
links || SCRENMGR Besitzer | SCRENMGR SMoB | Besitzer | SCRENMGR |
|| | | | |
rechts || SCRENMGR Besitzer | SCRENMGR Besitzer | Besitzer | SCRENMGR |
|| |
|| WINX 2.1 |
|| |
links || SCRENMGR Besitzer | SCRENMGR SMoB | Besitzer | SCRENMGR |
|| | | | |
rechts G2+|| SCRENMGR Besitzer | SCRENMGR Besitzer | Besitzer | SCRENMGR |
G2-|| Besitzer Besitzer | BdvF BdvF | BdvF | BdvF |
----------++--------------------+--------------------+----------+----------+
BdvF = Besitzer des vordersten Fensters
SMoB = SCRENMGR oder Besitzer (bei gesetztem BEVENT-Flag)
Nachdem der Empfänger des Klicks bestimmt ist, wird geprüft, ob der Zustand der
Maustasten der BUTTON-Anforderung der Applikation entspricht. Ist dies der
Fall, wird das Ereignis der Applikation gemeldet.
Leider kann es auch vorkommen, daß andere Applikation den Klick erhalten (z.B.
bei der Benutzung des Timers). Dieses Problem ist in MultiTOS und in WINX 2.1
behoben.