OLE

Microsoft hat mit der Version 3.1 von Windows ein neues Konzept zum Datenaustausch zwischen Windows-Applikationen eingeführt: "Object Linking and Embedding", kurz mit OLE bezeichnet. Nun gibt es OLE auch für Multitaskingsysteme auf ATARIs.

Unter Objekten versteht man hier Datenobjekte, also Bilder, Texte, Tabellen, etc., die von einer Windows-Applikation erstellt wurden und die mit einer Referenz auf diese Applikation ausgestattet sind. Eine zweite Applikation, der "Client", kann das Objekt einbinden. Durch den Link auf den Server ist das übernommene Objekt auch nachher noch jederzeit veränderbar. Ein Klick mit der Maus auf das eingebettete Objekt ruft automatisch den "Server" wieder auf, mit dem man das Objekt nachträglich wieder modifizieren kann. OLE ist also im Prinzip eine Art "dynamisches Klemmbrett", denn es beschränkt sich nicht darauf lediglich einen gemeinsamen Ordner zu verwalten, z.B.: "C:\CLIPBRD", sondern verwaltet statt dessen zu jeder Datei, die erzeugt oder bearbeitet wird, einen Link auf den "Server", also den sog. Erzeuger, und einen auf den "Client". Da dies ziemlich abstrakt klingt nun ein konkretes Beispiel:

So kann z.B. eine Grafik, die mit einem EBV-Programm retuschiert wurde, als eingebettetes Objekt in ein mit Calamus NT erstelltes Dokument übernommen werden. Das EBV-Programm fungiert hierbei als "Server" und Calamus NT als "Client". Selektiert man nun in Calamus NT, die eingebettete Grafikdatei, so öffnet sich automatisch das EBV-Programm, um die Grafik verändern zu können.

OLE endlich auch für Atari!

Der Gedanke ist nun folgender: Dank OLE für Atari könnte man auch Atari-Programme mit OLE-Features ausstatten. So ließe sich z.B.: auf der Calamus NT- und SL-Plattform eine noch einheitlichere Benutzerführung implementieren indem man beiden Programmen OLE-Support zur Verfügung stellt.

Unter Windows NT ist dies ohnehin bereits eingebaut und auf der AtariPlattform wäre es nun, mit OLE für Atari, auch in der Atari-Welt zu implementieren, falls man über ein Multitaskingbetriebssystem wie z.B.: MultiTOS, MagiC oder MagiC Mac verfügt. Einzige Ausnahme: MultiGEM und ältere MagiC-Versionen sind nicht verwendbar. In diesem Falle empfiehlt es sich, eine aktuelle MagiC Version zu erwerben oder auf eine solche zu aktualisieren, um sich nicht von der aktuellen Atari-Betriebssystementwicklung abzukoppeln und z.B.: in den Genuß des Drag & Drop-Protokolls zu kommen, welches für das OLE Konzept unbedingt erforderlich ist.

Vorteile des Atari OLE

Nun, welche Vorzüge hat es im Vergleich zu der Windows-Variante von OLE? Es ist nicht dateiorientiert und tätigt auch keine Pointer-Operationen. Außerdem basiert es auf dem Drag & Drop-Protokoll, so dass moderne Applikationen, die das MultiTOS-Drag & Drop-Protokoll bereits unterstützen, recht leicht auf OLE-Support zu erweitern sind. Weiterhin ist die Datenübergabe nicht an ein spezielles Format gebunden und die Effizienz des OLE für Atari zeigt sich auch in einem relativ geringen Overhead in den OLE-Applikationen. Pro Objekt/Link (Minimum) werden lediglich 16 Bytes beansprucht. Das Konzept ist wirklich gut durchdacht, schlüssig und zukunftssicher implementiert.
So werden Links jederzeit (automatisch) hergestellt, Applikationen müssen sich beim Manager nicht abmelden und das Speichermanagement ist unabhängig von Memory Protection und virtuellem Adressraum. Somit gestaltet sich der Support von OLE wirklich unkompliziert. Auch die Lauffähigkeit auf zukünftigen MagiC & MagiC Mac Versionen ist Dank des sauberen Speichermanagement, problemlos möglich ist. Links & Linkdaten können vom User geändert werden und das Updaten von Objekten ist problemlos im Manager konfigurierbar.

Das Konzept von OLE

OEP ermöglicht zwischen Objekten (Bilder, Samples, Texte etc.), die in unterschiedlichen GEM Applikationen verwendet werden, eine Verbindung (Link) herzustellen. Dieser Link wird, zumindest in den meisten Fällen, vom User mittels einer Drag & Drop-Operation vollzogen. Die Applikationen können allerdings auch jederzeit selbst Objekte austauschen. Wird ein "verbundenes" Objekt vom User/von einer Applikation verändert, kann mittels OEP, jede Applikation, die dieses Objekt ebenfalls verarbeitet, davon unterrichtet werden, und das Objekt somit systemweit auf den neuesten Stand gebracht werden. Eine Applikation (bzw. der Programmierer) muss wissen, welches Protokoll benötigt wird. Natürlich können OLGA (Object Linking for GEM Applications) und OEP gleichzeitig unterstützt werden. In der Regel wird dies allerdings nicht der Fall sein, da meist nur ein Manager im System installiert ist.

Was Programmierer beachten müssen.

Damit es für Applikationsprogrammierer einfacher ist, OLGA und/oder OEP zu unterstützen, haben Thomas Much (OLGA) und Alexander Lorenz eine gemeinsame Initialisierung entwickelt, die unter dem Oberbegriff "OLE" steht. Um herauszufinden, ob ein OEP-Manager installiert ist, sollte man wie folgt vorgehen:

1. appl-find()-Aufruf mit folgenden Dateinamen: für OEP: "OEPMANGR", für OLGA: "OLGA" für OLE (OLGA und/oder OEP):"OLEMANGR".
2. Environment-Variable überprüfen, für OEP: "OEPMANAGER", für OLGA: "OLGAMANAGER", für OLE: "OLEMANAGER".
3. erneut appl-find() mit dem Dateinamen von 2.
4. das unter 2. angegebene Programm nachstarten (sofern möglich/nötig).

Die neuen Eigenschaften der OEP-Applikationen basieren auf dem MultiTOS-Drag & Drop-Protokoll. Applikationen die dieses bereits unterstützen, können mit relativ geringem Aufwand OEP-fähig gemacht werden. Sollte das Drag & Drop-Protokoll noch nicht unterstützt werden, erhält die Applikation durch OEP zusätzlich die Eigenschaft, das normale Drag & Drop dem User anzubieten.

Um dem Manager mitteilen zu können, das ein Objekt verändert wurde, sollte dem User die Möglichkeit gegeben werden, dieses Ereignis explizit auslösen zu können. Die einfachste Möglichkeit ist, das Versenden von OEP- UPDATE mit dem Speichern des Dokumentes / Objektes zu verbinden. Eleganter wäre es, einen neuen Menüpunkt (z.B. "Aktualisieren") oder ein spezielles Icon anzubieten, womit der Benutzer auch einzelne Objekte innerhalb eines Dokumentes aktualisieren könnte.

Dies ist nur ein kurzer Abriß der Hilfestellungen, die wir Ihnen zu diesem Programm abgedruckt haben. Eine detaillierte Version dieses Artikels inklusive vieler Hilfestellungen und einer Fülle von Fallbeispielen, finden Sie auf der diesmonatigen Spezial-Diskette.

Ausblick in die Zukunft:

Es wäre schön wenn aktive Atari-Softwarehäuser wie z.B. Adequate Systems, ASH, COMPO, Digital Arts, DMC, Overscan GbR und R.O.M. logicware (und die anderen Atari-Softwarehäuser und -Entwickler natürlich auch) "OLE für Atari" in ihren Produkten unterstützen würden, da es nicht mehr zeitgemäß ist, den Datenaustausch zwischen Applikationen lediglich auf das GEM-Klemmbrett zu beschränken, da OLE ein dynamisches, interaktives und modernes Konzept verfolgt. So wären z.B.: Calamus SL, DA's Coloursystem, Papyrus, Script, Signum, That's Write etc. mit OLE-Support eine Bereicherung für die Atari-Plattform. Dank der Lauffähigkeit von OLE unter MultiTOS auf dem Falcon MKI/II, der Medusa und dem Eagle und außerdem auch unter MagiC und Magic Mac, ist eine Verbreitung auf allen gängigen Atari-Plattformen möglich. Somit sollte eine breite Akzeptanz von OLE möglich sein.