Der Falcon poppt up - Teil 2: Submenüs

Die neuen AES-Aufrufe des Falcon030 - Teil 2: Submenüs

Im zweiten Teil der neuen AES-Aufrufe des Falcon wollen wir uns mit den Submenüs befassen. Im Gegensatz zu den „gewöhnlichen" Pop-Up-Menüs, die ja bereits im Desktop des Falcon verwendet werden, werden sie vom Betriebssystem noch nicht genutzt, wohl aber unterstützt.

Ein Submenü ist ein „Untermenü" zu einem normalen Menüeintrag. Genauso, wie ein normales Menü ausgeklappt wird, wenn die Maus einen Menütitel berührt, wird ein weiterer Kasten -nämlich das Submenü -ausgeklappt, wenn die Maus in dem bereits ausgeklappten Menü einen Eintrag berührt, dem ein Submenü zugeordnet ist. Einen Menüeintrag, dem ein Submenü zugeordnet ist, erkennt man daran, daß er mit einem, Rechtspfeil „0" endet. Das Submenü, das rechts von dem ihm übergeordneten Menüeintrag erscheint, verhält sich wie ein normales Menü und sollte deshalb auch so aussehen.

Sinnvoll eingesetzt, können Submenüs durchaus eine Verbesserung darstellen, wenn sie z:B. einen überladenen Menübaum entlasten, indem selten gebrauchte Alternativen eines Befehls in ein Submenü ausgelagert werden. Ungeeigneter sind sie z.B., um irgendwelche Optionen einzustellen; die gehören in eine (Fenster)Dialogbox, bei der der Benutzer in Ruhe gleich mehrere Einstellungen übersehen und vornehmen kann, ohne sich ständig durch Menübäume "durchklappen" zu müssen.

Denken Sie als Programmierer bei der Programmentwicklung ab und zu auch an Laien und Gelegenheits-User, die schon mit normalen Menüs ihre Last haben, wenn diese immer im falschen Moment herunterfallen. Nehmen wir als Anwendungsbeispiel das normale DESKTOP: Hier könnte man z.B. auf die Idee kommen, die Sortierkriterien im „lndex"-Menü („ordne Namen", „ordne Datum" usw.) in ein Submenü zu packen, das einem „ordnen nach"Eintrag zugeordnet wird. Das wäre aber in diesem Fall unnötig, da im Menü genug Platz ist, und deshalb ungünstig, weil die Übersichtlichkeit durch diesen Schritt nicht zu sondern abnimmt (man sieht das zur Zeit eingestellte Ordnungskriterium jetzt ja erst nach dem Ausklappen des Submenüs). Andererseits könnte man im „Datei"-Menü den Befehl „Dateimaske setzen" mit einem Submenü versehen, das einem einige häufig benötigte Beispielmasken als Vorgabe anbietet („*.ACC", „*.DOC", „*.C" usw.). Man kann dieses Submenü ignorieren und den Menüpunkt wie bisher direkt anwählen oder sich für eine der zusätzlichen Optionen entscheiden.

Bisher sind Submenüs nicht sehr verbreitet, was vor allem daran liegen dürfte, daß es bisher nicht gerade einfach war, sie zu realisieren. Doch mit der Unterstützung von Submenüs durch das AES seit Version 3.31 könnte sich das schnell ändern.

Wie werden Submenüs vom AES verwaltet?

ATARI hätte natürlich eine neue Menübaumstruktur definieren können, in der Submenüs bereits ihre feste Zuordnung hätten; man ist jedoch einen anderen Weg gegangen, vermutlich aus Kompatibilitätsgründen. An den bisherigen Menübäumen ändert sich zunächst einmal überhaupt nichts. Sie werden wie bisher entwickelt, eingebunden und verwaltet. Jedes einzelne Submenü wird als eigener Objektbaum angelegt und erst zur Laufzeit mit dem Hauptmenü verbunden.

Ein Submenü ist ein ganz normales PopUp-Menü, wie es im letzten Teil beschrieben wurde; am sinnvollsten sind Text-Pop-Ups: ein Vaterobjekt vom Typ „G_BOX", die einzelnen Einträge als Kinder vom Typ „G_STRING". Zur optischen Unterscheidung vom Hauptmenü kann die Submenübox schattiert werden. Sowohl der eigentliche Menübaum als auch die einzelnen Submenüs sollten sich an die allgemeinen Konventionen halten: Zwei Leerzeichen vor den Einträgen (für das „Checked"-Häckchen) und mindestens eins am Ende. Für jedes Submenü muß wieder - wie bei normalen Pop-Ups - eine „MENU_STRUCT" angelegt werden Struct_Menu ( Me_Mdata%L, Mn_Tree% , Mn_Menu% , Mn_Item% , Mn_Scroll%, Mn_Keystate% ) Mn_Tree% ist die Adresse des Submenüobjektbaumes, Mn Menu% der Index des Vaterobjekts, also normalerweise des Submenükastens, Mn_Item% der Submenüeintrag, an dem das Submenü beim Ausklappen ausgerichtet wird, Mn_Scroll% kann bei ordentlichen Textsubmenüs 1 sein für Scrollen, muß aber bei allen anderen Submenüs auf 0 gesetzt werden. Mn_Keystate% ist im Moment bedeutungslos und sollte 0 sein, Me_Mdata%L liefert die Adresse der angelegten Struktur zurück.

Danach kann man die Submenüs über die „MENU_STRUCT" zur Laufzeit mit dem neuen AES Aufruf 37 „MENU_ATTACH" mit einem Hauptmenüeintrag verbinden:

Menu_Attach (Me_Mflag% , Me_Tree%L ,  Me_Item%, Me_Mdata%L )

Me_Tree%L ist die Adresse des Hauptmenübaumes, Me_Item% der Index des Hauptmenüeintrages, mit dem das Submenü verbunden werden soll, und Me_Mdata%L ist die Adresse der MENU-Struktur, die von „Menu_Struct" zurückgeliefert wurde. Me_Mflag% = -1 bedeutet verbinden oder eine bestehende Verbindung ändern, 0 bedeutet abfragen und bei 2 wird die Verbindung wieder gelöscht.

Intern werden die Submenüs über die untersten 6 Bits des High-Bytes von OB_TYPE verwaltet und ermöglichen so bis zu 64 Submenüs pro Menübaum, die in bis zu vier Ebenen verschachtelt sein können, aber das ist weder sinnvoll, noch braucht es uns zu kümmern.

Mit dem Herstellen der Verbindung ist fast alle Arbeit getan, den Rest übernimmt das AES. Vor allem fügt es den Rechtspfeil „ V" in den Hauptmenüeintrag Me_Item% ein, der dem Benutzer signalisiert, daß es sich um einen Eintrag mit Submenü handelt.

Der Rechtspfeil wird vom AES anstelle des zweitletzten Zeichens des Menüeintrages gesetzt, egal was sich dort befindet. D.h., Sie müssen beim Erstellen des Menübaumes unbedingt darauf achten, daß erstens jeder Eintrag, der später mit einem Submenü gekoppelt werden soll, am Ende mindestens 3 Leerzeichen besitzt, und zweitens, daß der Text (inklusive Anfangsund Endleerzeichen) des Eintrages genauso lang ist wie der Submenükasten breit. Nur so ist gewährleistet, daß der Pfeil an vorletzter Stelle des Menükastens erscheint, gefolgt von einem Leerzeichen und mit mindestens einem Zeichen Abstand zum Eintragstext.

Es gibt leider kein mir bekanntes RCS, das einem diese Arbeit abnimmt. Selbst INTERFACE 2, das eine Optimierung für Menüs besitzt, ist noch nicht auf die neuen Submenüs eingerichtet; weshalb man die Optimierung ausschalten und die Anpassung „zu Fuß" vornehmen muß.

Um die Verwaltung des Menübaumes braucht man sich nicht zu kümmern, das Ausklappen und Selektieren wird, wie gewohnt, vom AES übernommen; erst wenn ein Submenü selektiert wurde, ist man wieder gefragt. Zum Glück war im Messagebuffer des AES für die Nachricht Mn_Selected noch etwas Platz, so daß die Informationen über eventuell angewählte Submenüs dort noch untergebracht werden konnten. Bisher bekam man:

Mbuf%(3) = Objektindex des Menütitels 
Mbuf%(4) = Objektindex des gewählten Menüeintrages

Da der Index des Eintrages eindeutig war, benötigte man den Titel, nur um ihn wie der zu deselektieren. Jetzt kann man Mbuf%(4) erst verwenden, wenn man

Mbuf%(5) & Mbuf%(6) = Adresse des Objektbaumes (Langwort)

betrachtet hat. Dort steht dann entweder die Adresse des Menübaumes oder die Adresse des Objektbaumes eines Submenüs, wenn der gewählte Menüeintrag aus einem solchen stammt. Zusätzlich gibt es jetzt noch Mbuf%(7) = Vaterobjekt des Eintrages, was man aber eher selten benötigen wird.

Die neuen AES-Aufrufe unter Omikron.Basic

AES 36 - MENU_POPUP DEF PROC Menu_Pop-Up(Addrin%L(0), Intin%(0), Intin%(1), Addrin%L(1)) AES (36,Global%(15),Intin%(2),Addrin%L(2),Intout%(1),Addrout%L(0)) RETURN AES 37 - MENU_ATTACH DEF PROC Menu_Attach(Intin%(0),Addrin%L(0),Intin%(1),Addrin%L(1)) AES (37,Global%(15),Intin%(2),Addrin%L(2),Intout%(1),Addrout%L(0)) RETURN AES 38 - MENU_ISTART DEF PROC Menu_Istart(Intin%(0),Addrin%L(0),Intin%(1),Intin%(2)) AES (38,Global%(15),Intin%(3),Addrin%L(1),Intout%(1),Addrout%L(0)) RETURN AES 39 - MENU SETTINGS *) DEF PROC Menu_Settings(Intin%(0),R Addrin%L(0)) AES (39,Global%(15),Intin%(1),Addrin%L(1),Intout%(1),Addrout%L(0)) RETURN

Pop-Up-Menüs mit Submenüs

Natürlich kann man auch Text-Pop-Up-Menüs mit Text-Submenüs ausstatten. Der MENU_ATTACH-Aufruf funktioniert analog, und auch hier übernimmt das AES die Aus- und Einklapperei, nur daß es jetzt keine komfortable AES-Message gibt, die einem den angewählten Eintrag mitteilt. Man muß vor Aufruf des Pop-Ups eine leere MENÜ-Struktur definieren:

Struct_Menu ( Ret_Str%L , 0 , 0 , 0 , 0 , 0 )

und diese beim Aufruf des Pop-Ups angeben:

Menu_Pop-Up(Menu_Str%L , X%, Y%, Ret_Str%L )

In dieser Struktur findet man dann den Index des gewählten Eintrags und die Adresse des Objektbaumes, dem dieser Eintrag angehört:

FN Mn_Tree%L ( Ret_Str%L) , 
FN Mn_Item% ( Ret_Str%L )

Man darf natürlich nicht vergessen zu prüfen, ob diese Einträge überhaupt gültig sind (Nach Menu_Pop-Up muß intout%(0) = 1 sein).

Besonderheiten unter MultiTOS

Da seit dem Verfassen des ersten Teils schon einige Zeit vergangen ist, haben sich einige Änderungen ergeben, die teilweise auch den ersten Teil betreffen. Zum einen ist die Betriebssystemversion der ausgelieferten Falcons inzwischen bei TOS 4.04 angelangt, was nicht nur Fehlerkorrekturen, sondern auch eine Umstellung der Behandlung von 3D-Buttons mit sich brachte {siehe [3]}. Zum anderen ist inzwischen auch MultiTOS für jedermann erhältlich. Da MultiTOS auf absehbare Zeit nur als Nachladeversion verfügbar sein wird, haben wir durch den Umstand, daß sich die AES-Aufrufe für die Pop-Upund Submenüs schon im normalen Falcon-AES befinden, die Möglichkeit Falcon-Programme zu schreiben, die fleißig von den neuen AES-Funktionen Gebrauch machen können, auch wenn man das MulfiTOS einmal nicht nachgeladen hat. Man 'muß allerdings beachten, daß unter MultiTOS die Menüzeile munter gewechselt werden kann. Will man also an ein aktives Menü mittels MENU_ATTACH ein Submenü anhängen, muß man unter MultiTOS erfragen, welchem Prozeß die Menüleiste momentan gehört. Dazu ruft man MENU_BAR mit intin%(0)=-1 auf und erhält dann in intout%(0) die AES-Pid des Menüleisfenbesitzers. Da dieser neue MENU_BAR-Rückgabewert im Falcon-TOS noch nicht implementiert ist, muß man entweder zuerst prüfen, ob MultiTOS aktiv ist, oder sich darauf beschränken, nur dann an seinen Menübäumen herumzubasteln, wenn sie noch nicht aktiviert sind - was in den meisten Fällen ausreichen sollte.

Die Beispielprogramme

Es gibt wieder zwei Beispielprogramme: das erste verwaltet ein Pop-Up-Menü mit angehängtem Submenü, die beide mit der POPDEF.LIB erstellt wurden. Das zweite demonstriert die Benutzung einer normalen Menüleiste mit einem Submenü; hier wurden die Ressourcen mit einem RCS erstellt.

Die POPDEF.LIB und die POPUP.LIB liegen in leicht verbesserter Version vor, so daß man mit der POPDEF.LIB jetzt auch problemlos Einträge erstellen kann, an die später ein Submenü angehängt werden soll. Der OMIKRON.BASIC-Interpreter 3.6 ist zur Zeit noch nicht unter MultiTOS lauffähig, die Compilate können jedoch angepaßt werden.

Zunächst einmal muß jedes OMIKRON.BASIC-Programm vor dem Compilieren mit dem Compiler-Steuerwort

COMPILER "NO EXCEPTIONS"

oder einfacher

COMPILER "NOEX"

versehen werden. Das führt dazu, daß in das Compilat kein Exceptionhandler eingebaut wird, der sonst dafür zuständig ist, die beliebten Bömbchen abzufangen und wenn er sonst nichts retten kann - sie in lesbare Fehlermeldungen umzuwandeln. Das ist in einer Single-Tasking-Umgebung zwar sehr praktisch, führt aber unter MultiTOS dazu, daß der MiNT-Kernel den bombenden Prozeß (also das Compilat).nicht sauber entfernen kann. Mit großer Wahrscheinlichkeit stürzt das System schon bei der bloßen Manipulation der Exception-Vektoren ab. Das reicht für normale Programme aus. Programme die AES-Funktion verwenden, egal ob aus der GEMLIB oder Systemeigene, wie „FORM_ALERT" und „FILESELECT", können unter Umständen MEMORY-VIOLATIONS bei anderen Prozessen hervorrufen; in diesem Fall sollte man mit

COMPILER "FLAGS 10"

oder

COMPILER "FLAGS 11"

den Prozeßstatus des Compilates von PRIVATE auf GLOBAL setzen. Die zweite Ziffer setzt lediglich das Fastload-Flag, was mit den MultiTOS-Problemen nichts zu tun hat. Dieser Eingriff ist nur eine Notlösung, bis eine angepaßte Version von OMIKRON verfügbar ist, an der wohl im Moment noch gearbeitet wird. Beim Austesten von Programmen unter MultiTOS, die AES-Aufrufe verwenden, sollte man das dem MultiTOS Paket beiliegende „ALERT.ACC" nicht booten bzw. es vorher entfernen (es kann gefahrlos aus U:\PROC\ auf den Mülleimer gezogen werden). Dieses ACC sorgt nämlich dafür, daß die MiNT-Fehlermeldungen statt auf dem DESKTOP in einer Alertbox erscheinen. Das ist zwar ganz nützlich (vor allem für den allerersten Fehler, der von MiNT in die oberste Bildschirmzeile geschrieben und dann von der Menüzeile gleich wieder verdeckt wird), ist aber unbrauchbar, wenn man ein Programm testet, das z.B. genau dann abstürzt, wenn es eine Dialogbox oder die Fileselectbox anzeigt, weil dann der Bildschirm für das AES gesperrt ist und sich das ganze System beim Versuch, die Fehlermeldung in einer Alertbox anzuzeigen, kommentarlos aufhängt.

Literatur:
[l] Hendricks, Herzlinger, Pittelkow: „Das Buch zum ATARI Falcon030; Data Becker
[2] Jankowski, Reschke, Rabfch: „ATARI Profibuch",Sybex
[3] Uwe Seimet: „Das AES von MultiTOS und Falcon", ST Computer 6/93

Neuerungen in der POPDEF.LIB

Def Pop (State%) und Def Pop (State%, Max-W%, Max-H%) Mit State% kann dem Vaterobjekt des Pop-Ups jetzt ein Objektstatus übergeben werden. Sinnvoll ist eigentlich nur Shadowed% = 32. Übergibt man nichts, wird wie bisher Normal% = 0 gesetzt. Einträge, die später ein Submenü erhalten sollen, definiert man ganz normal mit Pop_Entry, beendet den Text jedoch mit einem Leerzeichen und dann einem Rechtspfeil, den man im Interpreter mit [CONTROL] [A],[CONTROL][#] erhält. Pop_Entry ( "Submenü" , Index% )

Neuerungen der POPUP.LIB

FN Pop-Up% ( Menu_Str%L , X% , Y% , Ret_Str%L ) Funktioniert wie das bisherige FN Pop-Up%, nur daß man in Ret Str%L jetzt eine leere MENU-Struktur übergibt, die man mit Struct_Menu ( Ret_Str%L , 0 , 0 , 0 , 0 , 0 ) angelegt hat. In dieser erhält man dann genauere Informationen: FN Mn_Item% ( Ret_Str%L ) liefert den gewählten Eintrag. Die neue Funktion FN Mn_Tree%L ( Ret_Str%L ) liefert den Objektbaum des gewählten Eintrags. Der Rückgabewert von FN Pop-Up% ist im Moment nur noch wahr oder falsch für Eintrag angewählt oder nicht.

Kai Michael Speck

---

---