Mit dem "BubbleHelp"-Hilfesystem kann sehr leicht eine kontextsensitive Hilfe realisiert werden. Dazu kann TControl-, TIcon- und TToolbar-Objekten (und davon abgeleiteten Objekten) in der jeweiligen Init-Methode ein String übergeben werden, der von der Dialogbehandlung ausgewertet wird. Im weiteren braucht dieser Hilfstext nicht weiter beachtet zu werden, einzig interessant ist noch die Methode SetHelp zum nachträglichen Ändern des Textes.
Wenn man in einem Dialog den Mauscursor auf ein solches Dialogelement bringt und die rechte Maustaste oder <Help> drückt, erscheint an der Mausposition eine Sprechblase mit dem festgelegten Hilfstext. Die Sprechblase bleibt mind. eine halbe Sekunde (ObjectGEM-intern festgelegt) sichtbar, danach kann sie mit einem Mausklick oder einem Tastendruck geschlossen werden.
Für die kontextsensitive Hilfe außerhalb von Dialogen steht die Methode TApplication.BubbleHelp zur Verfügung. Dort ist auch der Aufbau der Hilfe-Strings beschrieben.
In Zukunft wird es evtl. einen sog. "ständigen Hilfemodus" geben, bei dem eine Sprechblase erscheint, wenn sich der Mauscursor eine gewisse Zeit über einem Dialogelement befindet (wie beim Mac System 7). ObjectGEM legt dafür bereits jetzt den 'BHLP'-Cookie an, dessen Wert sich aus der Verzögerung bis zur Aktivierung der Hilfe (unterer integer, -1=Hilfemodus aus) und der Mindestzeit für die Sichtbarkeit der Sprechblase (oberes word) zusammensetzt.
Die Objekte TEdit, TWindow und TApplication besitzen das Feld Clipboard, das auf ein TClipboard-Objekt zeigt. Normalerweise gibt es nur ein globales Clipboard-Objekt, falls aber eine Spezialisierung notwendig sein sollte, steht die Methode GetClipboard zur Verfügung.
Um auf das Clipboard zugreifen zu können (lesend oder schreibend), muß man es mit OpenClipboard öffnen. Von GetClipboardFilename erhält man eine komplette Pfadangabe incl. Dateinamen für das Klemmbrett - nur die Extension fehlt noch (z.B. 'C:\CLIPBRD\SCRAP.'). Mit IsClipboardFormatAvailable und GetPriorityClipboardFormat kann man komfortabel nach bestimmten Dateitypen im Klemmbrett suchen, ansonsten kann man nun mit den "normalen" Dateifunktionen auf das Klemmbrett zugreifen. Abschließend muß man das Klemmbrett mit CloseClipboard wieder schließen und damit freigeben.
Hat man den Inhalt des Klemmbretts verändert, sollte man vorher noch SetClipboardFormat aufrufen, damit die beim Schließen verschickte SC_CHANGED-Message korrekt gesetzt werden kann.
Wichtig: Es kann immer nur ein TClipboard-Objekt Zugriff auf das Klemmbrett haben. Wenn also ein Zugriff immer bereits beim Öffnen scheitert, kann es sein, daß bei einem anderen Clipboard-Objekt das Schließen vergessen wurde.
In ObjectGEM ist das Drag&Drop-Protokoll in der Version 1.1 implementiert. Der Drag&Drop-Mechanismus steht nur unter MultiTOS und kompatiblen Betriebssystemen zur verfügung.
Wenn ein Programm Drag&Drop unterstützen soll, müssen zumindest die Methoden DDHeaderReply und DDReadData (bzw. DDReadArgs) überschrieben werden. Das Einlesen der Daten muß in letztgenannter Methode selbst vorgenommen werden. Da während des Drag&Drop-Protokolls der Bildschirm nicht blockiert werden darf, erhält man nach erfolgreicher Kommunikation in der Methode DDFinished die Möglichkeit, die Daten entsprechend auszuwerten.
Wenn der Aufbau der Kommunikation nicht unnötig in die Länge gezogen werden soll, muß dafür die Methode DDGetPreferredTypes überschrieben werden, in der man die möglichen Dateitypen einschränken kann.
Soll das Programm auch auf den 'PATH'-Parameter positiv antworten, muß DDGetPath effektiv gemacht werden.
Die ObjectGEM-Units werden wie gewohnt mit der uses-Klausel eingebunden. Dabei sollte folgende Reihenfolge eingehalten werden (abgesehen von nicht benötigten Units):
uses Objects,
OTypes,
OProcs,
OWindows,
OValidat,
ODialogs,
OStdDlgs,
OStdWnds,
ODB;
Wenn zusätzlich noch andere Units eingebunden werden (z.B. Gem, Tos etc.), sollten diese davor eingebunden werden, es sei denn, die Units greifen auf Teile von ObjectGEM zurück.
Welche ObjectGEM-Units benötigt werden, stellt man am besten mit "try and error" fest. Zuerst wird nur die Unit OWindows eingebunden, dann müssen solange die passenden Units dazugenommen werden, bis der Compiler nicht mehr "meckert".
ObjectGEM stellt eine erweiterte Dialogbehandlung zur Verfügung. Folgende Eigenschaften sind zusätzlich zu den üblichen GEM-Möglichkeiten vorhanden:
| <Shift>+<Tab>, | |
| <Cursor hoch> | geht zum vorherigen Eingabefeld |
| <Tab>, | |
| <Cursor runter> | geht zum nächsten Eingabefeld |
| <Cursor links>, | |
| <Cursor rechts> | Cursor innerhalb des Feldes bewegen |
| <Shift>+<Crs.li.> | Cursor an Feldanfang |
| <Shift>+<Crs.re.> | Cursor an Feldende |
| <ClrHome>, | |
| <Shift>+<Crs. hoch> | Cursor auf erstes Eingabefeld |
| <Shift>+<ClrHome>, | |
| <Shift>+<Crs. runter> | Cursor auf letztes Eingabefeld |
| <Backspace> | Zeichen links vom Cursor löschen |
| <Delete> | Zeichen rechts vom Cursor löschen |
| <Esc> | Feld löschen |
| <Undo> | s.u. |
Mit cs_WorkBackground können Fenster dazu gebracht werden, daß man sie im Hintergrund bedienen kann (unter allen TOS-Versionen). Dies gilt natürlich nur für den Arbeitsbereich, die Fensterkomponenten können nur im Hintergrund angewählt werden, wenn das Betriebssystem dies unterstützt (z.B. MultiTOS). Solche Fenster können nur noch durch Anklicken einer Fensterkomponente (Titelzeile etc.) getoppt werden, oder - dies ist ein ObjectGEM-spezifisches Feature - mit einem Doppelklick rechts im Arbeitsbereich!
In den TWindow-Fensterobjekten sind z.Z. folgende Tastatur-Shortcuts vorgesehen (#<...> bedeutet, daß die Taste im Ziffernblock gemeint ist):
| <Control>+<A> | Wählt alle passenden Elemente im Fenster aus |
| (siehe TWindow.SelectAll) | |
| <Control>+<C> | Führt die "Kopieren"-Operation durch |
| (siehe TWindow.Copy) | |
| <Control>+<P> | Druckt den Fensterinhalt aus |
| (siehe TWindow.Print bzw. TTextWindow.Print) | |
| <Control>+<U> | Schließt das Fenster |
| <Control>+<V> | Führt die "Einfügen"-Operation durch |
| (siehe TWindow.Paste) | |
| <Control>+<W> | Wechselt die Fenster der Applikation |
| zyklisch (mit <Shift> in umgekehrter | |
| Reihenfolge) | |
| <Control>+<X> | Führt die "Ausschneiden"-Operation durch |
| (siehe TWindow.Cut) | |
| <Control>+#<*> | Bringt das Fenster auf Maximalgröße |
| <Control>+#</> | Bringt das Fenster in den Hintergrund |
| (AES 4.0) | |
| <Control>+<Alt>+<Space> | Ikonifiziert das Fenster |
| <Delete> | Führt die "Entfernen"-Operation durch |
| (siehe TWindow.Delete) | |
| <Control>+<Q> | Verläßt das Programm |
| (dies ist eigentlich kein Fenster-Shortcut) |
Ab AES 4.10 unterstützt ObjectGEM Iconification, d.h. GetStyle liefert zusätzlich den Wert SMALLER zurück, und im Fenster erscheint links neben dem Fuller noch der "Verkleinerungsknopf".
Wenn dieser Button angewählt wird, wird das entsprechende Fenster ikonifiziert. Dem Icon-Fenster kann per GetIconTitle ein neuer Titel zugewiesen werden, außerdem wird bei einem Redraw nun die Methode IconPaint aufgerufen. Der Status eines Fensters läßt sich mit IsIconified abfragen.
Wenn beim Anklicken des SMALLERs zusätzlich die <Control>-Taste gedrückt wird, wird die gesamte Applikation ikonifiziert, d.h. alle Fenster werden in einem Icon-Fenster zusammengefaßt. Dafür stehen ähnliche Funktionen wie bei einem Fenster zur Verfügung. Wichtig: Hierbei werden die Fenster der Applikation nicht geschlossen, sondern nur rechts so weit über den Bildschirmrand geschoben, daß man sie nicht mehr sieht und der Benutzer keine Aktionen mehr an ihnen durchführen kann. Für die Applikation wird dann ein neues Icon-Fenster geöffnet.
Soll in einem ikonifizierten Fenster automatisch ein Icon angezeigt werden, muß TWindow.LoadIcon aufgerufen werden. Damit auch bei einem Applikations-Icon-Fenster ein Icon erscheint, steht die Methode TApplication.LoadIcon zur Verfügung. Dialoge übernehmen dieses Icon automatisch, wenn ihnen kein eigenes Icon zugewiesen wird.
Ist ein ICFS-Server installiert, so ist Iconification auch unter alten TOS-Versionen möglich. Wird beim Anklicken der CLOSERs die <Alternate>-Taste gedrückt, wird das Fenster ikonifiziert. Das Verkleinern aller Fenster mit <Control> ist aus technischen Gründen (noch) nicht möglich bzw. sinnvoll. In einer späteren Version wird es allerdings auch die ICFS-Iconification mit <Shift> geben (alle Fenster werden einzeln verkleinert).
Ikonifizierte Fenster oder Applikationen erhalten von ObjectGEM nur noch Timer- sowie ausgesuchte Message-Events. Evtl. kann in Zukunft aber ein Flag gesetzt werden, so daß auch in einem Icon-Fenster Aktionen durchgeführt werden können.
Die GEM-Message GO_PRIVATE ($1235) wird intern mit folgenden Sub-Opcodes in msg[3] verwendet:
| GOP_GETVERSION | 0 | dient als Aufforderung, eine GOP_VERSION- |
| Message zu schicken | ||
| GOP_TOOLBAR | 1 | siehe TToolbar.TestMessage |
| GOP_SETQUIT | 2 | wird von LoadMenu verschickt, um den Menü- |
| eintrag (msg[4]) und -titel (msg[5]) für | ||
| das <Control>+<Q>-Objekt zu setzen; beim | ||
| Empfang dieser Message ruft MUMesag die | ||
| Methode SetQuit auf | ||
| GOP_VERSION | $7fff | wird als Antwort auf GOP_GETVERSION ver- |
| schickt; in msg[4] erhält man die jewei- | ||
| lige GOVersion |
Im folgenden ist aufgelistet, bei welchem Versionssprung solche Änderungen vorgenommen wurden, die nicht ganz kompatibel zur Vorgängerversion waren und daher evtl. Veränderungen an eigenen Quelltexten nach sich ziehen.
Fenster-Toolbars bestehen aus ganz normalen Dialog-Bäumen in der Resource-Datei, die in SetupWindow mittels LoadToolbar mit dem Fenster verknüpft werden. Um eine einfach Bearbeitung zu gewährleisten, sollten danach alle Toolbar-Buttons mit TToolbar-Objekten verknüpft werden, die als Schnittstellenobjekte dienen.
Eine andere Möglichkeit sind Anwender-konfigurierbare Toolbars. Dabei kann der spätere Anwender des Programms sich seine Toolbar-Buttons mit einem Resource Construction Set zusammenstellen. Diese Buttons werden nicht mit TToolbar-Objekten verknüpft (der Programmierer kann ja nicht alle Anwenderwünsche berücksichtigen), sondern über den erweiterten Objekttyp mit einem Menüeintrag in der Menüleiste der Applikation. Dieses ist die einzige Situation, in der die Verwendung des höherwertigen Bytes von ob_type unter ObjectGEM gestattet ist! Wichtig: Wenn sich eine Anwender-konfigurierbare Toolbar auf die Fenster-Menüleiste im selben Fenster beziehen soll, muß das Flag cs_WindowMenuToolbar gesetzt werden.
Findet der Toolbar-Dispatcher im höherwertigen Byte eine Null vor (das sollte bis jetzt immer der Fall sein), passiert gar nichts. Ist dort allerdings ein Wert ungleich Null eingetragen, wird MNSelected mit eben diesem Wert als Index des gewählten Menüeintrags aufgerufen.
Wichtig: Dieser Mechanismus funktioniert auch, wenn TToolbar-Objekte eingesetzt werden, d.h. der Programmierer kann diesen Effekt bewußt ausnutzen. Der Aufruf erfolgt in diesem Fall nach dem Aufruf der Work-Methode.
Wenn Anwender-konfigurierbare Toolbars eingesetzt werden, muß der Programmierer dafür sorgen, daß die Indizes der Menüeinträge dokumentiert werden. Außerdem wäre es nett, wenn dem Anwender dann z.B. Mini-Icons für die wichtigsten Funktionen zur Verfügung gestellt würden.
In den TPopup-Menüs ist folgende Tastatursteuerung vorgesehen:
| <Return>, | Wählt den markierten Eintrag aus |
| <Enter>, | |
| <Space> | |
| <Esc>, | Bricht das Popup-Menü ab |
| <Undo> | |
| <Home>, | Markierung auf ersten Eintrag |
| <Shift>+<Crs. hoch> | |
| <Shift>+<Home>, | Markierung auf letzten Eintrag |
| <Shift>+<Crs. runter> | |
| <Cursor hoch> | Bewegt die Markierung nach oben |
| <Cursor runter> | Bewegt die Markierung nach unten |
Mit den ObjectGEM-Profile-Routinen können die bei vielen Applikationen vorhandenen INF-Dateien sehr leicht realisiert werden. Sie haben außerdem den Vorteil, daß sie als ASCII-Texte verwaltet werden, so daß sie - wenn nötig - auch "von Hand" verändert werden können.
Außerdem werden - wenn die Environmentvariable HOME und das Flag as_UseHomeDir gesetzt ist - diese Konfigurationsdateien an einem zentralen Ort (eben dem User-Home-Verzeichnis) gespeichert, so daß auch eine Multi-User-Umgebung realisierbar ist. Wenn HOME nicht gesetzt ist, werden die Dateien wie gewohnt im Ordner der Applikation angelegt.
Ein Profile setzt sich aus Blöcken zusammen. Jeder Block hat eine "Überschrift" (in eckigen Klammern, bei den Profile-Routinen auch mit "Anwendungsname" bezeichnet). Nach diese Überschrift folgen die Schlüsselnamen mit den zugehörigen Werten, Leerzeilen sind nur zum Trennen der Blöcke erlaubt. Kommentare beginnen mit einem Semikolon oder # am Zeilenanfang, Kommentarblöcke werden mit ## eingeschlossen. Ein Eintrag innerhalb eines Profiles muß durch den Anwendungs- und Schlüsselnamen eindeutig bestimmt sein, ansonsten wird nur das erste Vorkommen beachtet. Ein Profile könnte also z.B. so aussehen:
; Das ist ein Kommentar innerhalb eines Profiles
# das auch
[Block 1]
Var_1=Test-Text
Var_2=42
## hier beginnt ein Kommentarblock
und in der nächsten Zeile hört er auf
##
[nächster Block]
Var_2=die hat nichts mit o.g. Variable zu tun
Var_3=2147483647
Hallo.Welt=Das ist ein Test!
Zum Auswerten eines Profiles stehen Routinen für ganze Zahlen (GetPrivateProfileInt, WritePrivateProfileInt) und für Zeichenketten (GetPrivateProfileString, WritePrivateProfileString) zur Verfügung. Sollen Fließkommazahlen bearbeitet werden, muß man diese in Zeichenketten umwandeln (z.B. mit ftoa, atof).
Profiles, die direkt auf einer Datei arbeiten, sind recht langsam, vor allem beim Schreiben. Deshalb besteht die Möglichkeit, ein Profile mit OpenPrivateProfile in den Speicher zu laden, wo die Bearbeitung deutlich schneller ist. Da immer nur ein Profile im Speicher verwaltet werden kann, werden Zugriffe auf andere Profiles weiterhin direkt auf der Platte (bzw. Diskette) durchgeführt. ClosePrivateProfile braucht nicht explizit aufgerufen zu werden, dies geschieht automatisch beim Programmende. Man sollte allerdings nach dem Schreiben von Daten immer die Routine SavePrivateProfile aufrufen, da man z.B. bei Accessories nicht davon ausgehen kann, daß die Applikation verlassen werden kann.
Die oben erwähnten Routinen bearbeiten private Profiles, d.h. Applikations-spezifische Konfigurationsdateien. Da es aber auch wünschenswert sein kann, bestimmte Werte systemglobal festzulegen, ist z.Z. eine Datei $HOME/user.inf in der Diskussion, die von allen Applikationen verwendet werden kann. Für diese Datei stehen spezielle Routinen zur Verfügung (GetProfileString etc.). Da die Standardisierung aber noch nicht abgeschlossen ist, kann sich am Namen, Ort, Inhalt etc. der Datei noch etwas ändern.
Folgendes sollte bei der Resource-Erstellung für ObjectGEM beachtet werden:
"1 2 3
4 5 6"
Wenn ein Toolbar-Button nicht mit einem TToolbar-Objekt verknüpft wird (s. "Toolbars"), muß in ob_state SELECTABLE gesetzt sein.
ObjectGEM verwendet das XAcc-Protokoll nach der Definition vom 28.11.1992, d.h. auch unter MultiTOS ist die korrekte Protokollbehandlung gesichert.
Als Programmierer braucht man sich nicht um die Einzelheiten des Protokolls kümmern, sondern man kann direkt das Ergebnis in der XAccList (z.B. per TApplication.FindApplication) auswerten. Die einzig interessante "Verwaltungs"-Routine dürfte TApplication.XAccInsert sein.
Die XAcc-Eigenschaften des ObjectGEM-Programms werden in der Methode TApplication.GetXAccAttr festgelegt. Wenn man also besondere Eigenschaften kennzeichnen möchte, muß man diese Methode überschreiben. Man kann dort auch die "Extended names" festlegen, die dann von ObjectGEM automatisch korrekt verschickt werden.
Wichtige Methoden für das XAcc-Protokoll sind diejenigen, mit denen ein Datenaustausch durchgeführt werden kann. Dies sind die TApplication-Methoden XAccText, XAccKey, XAccMeta und XAccIMG. Diese Methoden dienen zum Empfangen von Daten; ein Verschicken wird z.Z. von ObjectGEM noch nicht direkt unterstützt.
ObjectGEM wertet außerdem das AV-Protokoll aus. Dies geschieht ebenfalls automatisch, und es werden die gleichen Datenstrukturen verwendet. Wie beim XAcc-Protokoll dürfte auch nur die Methode TApplication.AVInsert interessant sein, alle spezifischen AV-Messages werden weiterhin an TApplication.HandleAV weitergeleitet. Ist ein AV-Server vorhanden, befindet sich seine AES-ID im Feld TApplication.AVServer.
Updates von ObjectGEM gibt es ausschließlich in den verschiedenen Netzen:
Falls ObjectGEM auch in anderen Mailboxen etc. ständig zum Download bereitsteht, wäre ich für eine kurze PM dankbar (Adresse siehe "Kontakt").
Natürlich sollten Sie auch bei allen bekannten PD-Versendern die aktuelle ObjectGEM-Version erhalten können.