10/04

Hingeschaut!

von Michael Christoph

 

Auch in der intuition.library musste intern viel überarbeitet werden ­ vor allem im Zusammenhang mit der layers- und graphics.library. Das Fehlen der Custom-Chips und bessere Unterstützung von High- und True-Color-Schirmen sind die Hauptgründe. Das Aussehen und Verhalten von Bildschirmen, Fenstern, Requester und Gadgets lassen sich jetzt praktisch grenzenlos durch den User beeinflussen. Der GUI-Einsteller stellt die Schnittstelle zum Benutzer dar. Damit unter OS 4 auf die Funktionen der intuition.library zugegriffen werden kann, muss zuerst wieder die Library selber geöffnet und dann das Interface ermittelt werden. Die Vorgehensweise dürfte mittlerweile bekannt sein ­ ein Beispiel finden Sie auf der CD zur aktuellen Ausgabe. Alternativ gibt es aber auch die Möglichkeit, alle benötigten Libraries automatisch durch den Startup-Code zu öffnen. Dazu muss lediglich -lauto beim Kompilieren (bzw. Linken) angegeben werden. Alle wichtigten Libraries sollten dort bereits enthalten sein. Das gilt jedoch nur bei Verwendug des gcc. Ist man sich unsicher, hilft ein kleines Programm, das einfach die Speicheradresse der Library ausgibt. Ist diese 0 bzw. NULL, wurde sie nicht automatisch geöffnet. Wird dagegen ein Wert ausgegeben, steht auch das Interface zur Verfügung. Die Übersetzung rufen Sie so auf: gcc InterfaceOffen.c -oInterfaceOffen -lauto Hinweis: Der Library-Zeiger darf nicht im Sourcecode deklariert werden, höchstens als externe Variable. Ansonsten würde die eigene Variable die des Startupcodes »überdecken« und wäre natürlich nicht gesetzt. EasyRequester an beliebiger Stelle Die »EasyRequester« stellen eine einfache Möglichkeit dar, den Benutzer über Programmzustände zu informieren, aber auch, um einfache Rückfragen zu realisieren. Ein Nachteil bisher: Die Requester-Fenster standen bisher immer in der linken oberen Ecke. Auch das direkte Festlegen des Bildschirms, auf dem es angezeigt werden soll, konnte bisher nur indirekt über den Window-Zeiger erfolgen. Wurde aber gar kein Fenster angezeigt, bzw. konnte nicht geöffnet werden, erfolgte ein automatischer Wechsel zur Workbench. Dort wurde dann der Requester angezeigt. Beide Fälle können unter OS 4 flexibler gehandhabt werden. Dazu wurde struct EasyStruct erweitert um die beiden Felder es_Screen und es_TagList. Soll der Requester auf dem eigenen Screen angezeigt werden, so ist es_Flag auf ESF_SCREEN zu setzen und in es_Screen der eigene Bildschirm-Zeiger zu hinterlegen. Damit die Tags beachtet werden, muss in es_Flag das Flag ESF_TAGGED gesetzt sein! Bisher erlaubt die Tagliste eine Positionsangabe. Mögliche Werte für den Tag ESA_Position finden Sie in »EasyRequester: Positionen« und ein Beispiel ist in Listing 2 . Eine andere Möglichkeit zum Erstellen von Requesters ist die eher unbekannte Requester-Boopsi-Klasse. Mit OS 4 wurde die Klasse nochmal stark aufgewertet und bietet neue Tags an. Eine Übersicht finden Sie in der Tabelle »Informationen: Requester-Boopsi«. Ansonsten können auch eigene Image-Daten (struct Image *) angegeben werden. Das bisher umfangreichste Beispiel Requester.c zeigt Anwendungsmöglichkeiten. Zur Abwechslung liegt es in einer OS 3.x kompatiblen Notation vor. Daher muss es per: gcc -D__USE_INLINE__ -D__USE_BASETYPE__ Requester.c -o Requester -lauto kompiliert werden. Die Boopsi-Klassen haben jetzt auch den offiziellen Typ struct ClassLibrary * erhalten und wurden entsprechend mit eigenen Funktionen zum Öffnen und Schließen ergänzt. Bisher musste man auf OpenLibrary/Close-Library zurückgreifen und ggf. auch noch in unterschiedlichen Verzeichnissen suchen. Die Funktion OpenClass liefert außerdem im dritten Argument den Klassen-Zeiger zurück. Bei Systemklassen kann man sich darauf verlassen, bei den anderen Entwicklungen ist dieser Zeiger unbedingt zu überprüfen. Bildschirme und Fenster Fenster können jetzt auch über die Bildschirmgrenzen hinaus verschoben werden. Damit das auch bei eigenen Bildschirmen möglich ist, muss beim Öffnen der Tag SA_OffScreenDragging auf TRUE gesetzt sein. Standardmäßig ist der Tag nicht gesetzt, sodass es im Zusammenhang mit alten Programmen zu keinen Nebenwirkungen kommen kann. Musste bisher beim Durchsuchen der Fenster/ Bildschirmliste das Multitasking global über Disable() deaktiviert werden, gibt es dazu jetzt die systemfreundliche Funktion LockScreenList(). Sie liefert als Rückgabewert den ersten Bildschirm. Anhand des NextScreen- oder FirstWindows-Zeigers, kann die Liste weiter durchlaufen werden. Am Ende wird mit UnlockScreenList() die Sperre wieder aufgehoben. Während dieser Zeit kann kein Bildschirm geöffnet oder geschlossen werden, was auch auf die Fenster zutrifft. Daraus ergibt sich automatisch, dass die Sperrung nur ganz kurz ausfallen soll. Ein kleines Beispiel sehen Sie in Listing 3. Wenn ein Programm mehrere Fenster öffnet, gibt es zwei Möglichkeiten der Nachrichtenbehandlung. Entweder erzeugt jedes Fensters für sich einen Messageport. Vom Programm müssen dann alle Ports der Reihe nach behandelt werden. Alternativ kann das Programm selber einen Messageport erzeugen und diesen in allen Fenstern setzen. Dann muss aber beim Schließen eines Fenster koordiniert werden, dass keine Nachrichten mehr für dieses Fenster im Messageport liegen. Letztere Variante wurde bei OS 4 verbessert. Bereits beim Öffnen des Fensters kann über WA_UserPort der Messageport mitgegeben werden. Beim Schließen des Fensters kümmert sich dann Intuition selber darum, dass der Messageport »sauber« zurückgegeben wird. Das Erzeugen und Freigeben des Ports bleibt aber weiterhin im Aufgabenbereich der Applikation. Interessant dürfte auch der Tag WA_Hidden sein. Dieser erlaubt es, das Fenster zu erzeugen, aber nicht anzuzeigen. Über ShowWindow() und HideWindow() kann das Fenster jederzeit angezeigt oder wieder versteckt werden. Es wiederspricht zwar der speichersparenden Programmierung Ressourcen zu belegen, die man im Moment gar nicht benötigt. Aber heutzutage kann man hier sicher etwas großzügiger sein. Der Vorteil liegt klar auf der Hand: Wird das Fenster benötigt, ist es bereits da. Speicherknappheit in dieser Situation hat dann keine Auswirkungen. Zu diesem Feature finden Sie in Listing 5 ein Beispiel. Mit CTRL-E wird das Fenster angezeigt, mit CTRL-F wieder versteckt und CTRL-C beendet das Programm. Mit Hilfe des Programms »FensterListe.c« lässt sich die Existenz des Fensters prüfen. Alles variabel Wie die Überschrift schon zu verstehen gibt, können Fenster jetzt sehr variabel vom Benutzer verändert werden. Die Stärke der einzelnen Rahmenelemente lässt sich getrennt ändern. Der linke und rechte Fensterrand sind also nicht zwangsläufig gleich breit. Annahmen dieser Art führen auch dazu, dass die Position und Größe von eigenen Gadgets im Fensterrahmen nicht stimmen. arüberhinaus können die Rahmen auch mit Mustern oder Farbverläufen versehen werden. Wer direkt Text in die Titelzeile des Fensters pinselt, fällt da sehr schnell auf. Da es im Zusammenhang mit Slidern im Fensterrahmen immer wieder zu unschönen Ergebnissen kommt, zeigt das Beispiel »WinSlide.c«, wie es korrekt gemacht wird. Das Programm finden Sie auf der Heft-CD. Es ist abwärtskompatibel und liegt als OS 3.9 Source vor. Unter OS 4 nutzen Sie den Compiler- Aufruf gcc -D__USE_INLINE__ WinSlider.c -o WinSlider -lauto zur Übersetzung. Dem Programm wurde auch eine einfache Tastatursteuerung per Cursor-Tasten eingebaut. Die beiden Variablen für die vertikale und horizontale Schrittanzahl ist im Beispiel auf zehn Schritte festgelegt. Es gibt jetzt auch neue Funktionen zum Setzen und Ermitteln von Fenster- bzw. Bildschirmattributen. Die Zukunft soll dahingehen, dass nicht mehr direkt in den Screen/Window-Strukturen gelesen und gar verändert wird, sondern dass es eine genormte Schnittstelle gibt, die sich darum kümmert. Bisher können allerdings erst ein Teil der Tags für SA_xxx und WA_xxx dazu in der Praxis verwendet werden. Die Funktionsnamen lauten GetScreenAttr bzw. SetScreenAttr für Bildschirme. Für die Ermittlung bzw. das Setzen der Fenster-Attribute nutzen Sie GetWindowAttr bzw. SetWindowAttr. Eine Liste der neuen Funktionen mit kurzer Beschreibung finden Sie im Kasten auf der nächsten Seite. Weitere Programmbeispiele zum aktuellen Kursteil haben wir für Sie auf der Heft-CD im Verzeichnis "Amiga Magazin/OS4-Programmierung" abgelegt. Im nächsten Heft lesen Sie mehr zum Thema graphic- und layers.library. lb

Listingübersicht Listing 1: Test des geöffneten Interfaces. Listing 2: Arbeit mit Easy Requester Listing 3: Ein Beispiel zur Programmierung eines Requesters. Listing 4: Eine Liste mit den aktiven Fenstern erstellen. Listing 5: Ein Fenster verstecken und wieder anzeigen.   Farbmix Über den Einsteller »Define Gradient« stellt man die Farben bzw. Verläufe für die Fensterrahmen ein.   Einstellungssache Die Elemente für das Benutzer-Interface werden in den »GUI Preferences« festgelegt.   EasyRequester: Positionen REQPOS_DEFAULT Prefs-Einstellungen verwenden REQPOS_CORNER links oben vom Bildschirm REQPOS_BELOWBAR links oben unter der Titelzeile des Bildschirms REQPOS_CENTERMOUSE mittig unter der Maus REQPOS_CENTERSCREEN mittig im Bildschirm REQPOS_CENTERWINDOW mittig im angegebenen Fenster   Informationen: Requester-Boopsi Anhand von REQ_Type sind vier vordefinierte Typen wählbar: REQTYPE_INFO (Wert 0) = Information/Frage REQTYPE_INTEGER (Wert 1) = Zahleneingabe REQTYPE_STRING (Wert 2) = Texteingabe REQTYPE_PROGRESS (Wert 3) = Progressbar (noch nicht verfügbar) Besonders interessant ist Tag REQ_Image. Dieser erlaubt die Verwendung vordefinierter Symbole, die im Requester (links) angezeigt werden. REQIMAGE_DEFAULT Leer REQIMAGE_INFO Informationen anzeigen REQIMAGE_WARNING Warnung, Hinweise REQIMAGE_ERROR Fehler, Programmabbruch REQIMAGE_QUESTION bei Rückfrage REQIMAGE_INSERTDISK Diskette wird verlangt

Kommentare, Fragen, Korrekturen und Kritik bitte an Webmaster AMIGA schicken.
Zuletzt aktualisiert am 19. November 2004, Michael Christoph.