3127 lines
96 KiB
Plaintext
3127 lines
96 KiB
Plaintext
Object Linking for GEM Applications
|
||
|
||
OLGA Rev 1.5
|
||
|
||
16. Juni 1998
|
||
|
||
von
|
||
|
||
Thomas Much
|
||
|
||
|
||
Inhaltsverzeichnis
|
||
==================
|
||
|
||
1 Einleitung
|
||
|
||
2 Was ist Object Linking?
|
||
2.1 Die OLGA-Architektur
|
||
|
||
3 Installation des OLGA-Managers
|
||
3.1 OLGA-Tools
|
||
|
||
4 Das OLGA-Protokoll...
|
||
4.1 ...als Minimalversion
|
||
4.1.1 Server
|
||
4.1.2 Client
|
||
4.2 ...f<>r Server und Client
|
||
4.2.1 Nachstarten des OLGA-Managers
|
||
4.2.2 OLE_INIT
|
||
4.2.3 OLGA_INIT
|
||
4.2.4 OLE_EXIT
|
||
4.2.5 OLE_NEW
|
||
4.3 ...aus der Sicht des Servers
|
||
4.3.1 OLGA_UPDATE
|
||
4.3.2 OLGA_GETINFO
|
||
4.3.3 OLGA_INFO
|
||
4.3.4 OLGA_RENAME
|
||
4.3.5 OLGA_BREAKLINK
|
||
4.3.6 OLGA_CLIENTTERMINATED
|
||
4.4 ...aus der Sicht des Clients
|
||
4.4.1 OLGA_OPENDOC
|
||
4.4.2 OLGA_CLOSEDOC
|
||
4.4.3 OLGA_LINK
|
||
4.4.4 OLGA_UNLINK
|
||
4.4.5 OLGA_UPDATED
|
||
4.4.6 OLGA_RENAMELINK
|
||
4.4.7 OLGA_LINKRENAMED
|
||
4.4.8 OLGA_LINKBROKEN
|
||
4.4.9 OLGA_START
|
||
4.4.10 OLGA_SERVERTERMINATED
|
||
|
||
5 InplaceDrawing
|
||
5.1 ID4-Client
|
||
5.1.1 OLGA_GETOBJECTS
|
||
5.1.2 OLGA_ACTIVATE
|
||
5.1.3 OLGA_EMBED
|
||
5.1.4 OLGA_ID4UPDATE
|
||
5.1.5 cbColorTable
|
||
5.1.6 cbClientID
|
||
5.2 ID4-Server
|
||
5.2.1 OLGA_EMBEDDED
|
||
5.2.2 OLGA_UNEMBED
|
||
5.2.3 OLGA_INPLACEUPDATE
|
||
5.2.4 CBDraw
|
||
5.2.5 CBUnembed
|
||
5.2.6 CBXDraw
|
||
5.2.7 cbServerID
|
||
|
||
6 Notification
|
||
6.1 OLGA_REQUESTNOTIFICATION
|
||
6.2 OLGA_RELEASENOTIFICATION
|
||
6.3 OLGA_NOTIFY
|
||
|
||
7 Idle-Test
|
||
|
||
8 Konfigurationsabfrage
|
||
8.1 OLGA_GETSETTINGS
|
||
8.2 OLGA_GETSERVERPATH
|
||
8.3 OLGA_GETEXTENSION
|
||
|
||
9 Das OLGA-Info-Dateiformat
|
||
|
||
10 Abschliežende Hinweise
|
||
|
||
|
||
Anhang
|
||
======
|
||
|
||
A FAQ
|
||
|
||
B Glossar
|
||
|
||
C Liste der OLGA-Applikationen
|
||
|
||
D Extensions
|
||
|
||
E Dateien
|
||
E.1 OLGA.H
|
||
E.2 OLGA.INC
|
||
E.3 OLGA.INF
|
||
|
||
F History
|
||
|
||
G K<>nftige Weiterentwicklungen
|
||
|
||
H Kontakt
|
||
|
||
I Rechtliches
|
||
|
||
J Dank
|
||
|
||
|
||
|
||
1 Einleitung
|
||
*************
|
||
|
||
Dies ist die Anleitung zu OLGA 1.5, d.h. zum OLGA-Protokoll Revision
|
||
1.5 (08.06.98) und zum OLGA-Manager Version 1.51 (16.06.98).
|
||
|
||
Anwender werden sich vermutlich haupts„chlich f<>r "Was ist Object
|
||
Linking?" (siehe "Was ist Object Linking?") und die Installation des
|
||
OLGA-Managers interessieren, aber auch im Anhang gibt es ein paar
|
||
n<EFBFBD>tzliche Informationen.
|
||
|
||
Programmierer sollten daneben auch einen Blick auf "Die OLGA-
|
||
Architektur" (siehe "Die OLGA-Architektur") werfen, um einen šberblick
|
||
<EFBFBD>ber die M”glichkeiten zu bekommen. Aužerdem ist der Rest dieser
|
||
Dokumentation ganz speziell f<>r sie bestimmt.
|
||
|
||
Bitte beachten Sie auch "Rechtliches".
|
||
|
||
|
||
|
||
2 Was ist Object Linking?
|
||
**************************
|
||
|
||
Object Linking (OL) dient zur besseren (automatischen) Interaktion
|
||
zwischen verschiedenen Programmen. Wenn z.B. bei einem Vektorgrafik-
|
||
programm in einem Dokument (Vektorgrafik) ein beliebiges Objekt (hier
|
||
z.B. eine Rastergrafik) dargestellt wird und dieses - eine Multitas-
|
||
king-Umgebung vorausgesetzt - von einem anderen Programm (hier also
|
||
ein Rastergrafikprogramm) ge„ndert wird, w„hrend beide Programme lau-
|
||
fen, w<>rde die Rastergrafik nach der Žnderung (d.h. dem Speichern) in
|
||
der Vektorgrafik automatisch neu angezeigt.
|
||
|
||
Ein solches OL ist recht einfach zu bewerkstelligen, damit aber belie-
|
||
bige Programme mit beliebigen Objekten kompatibel arbeiten k”nnen,
|
||
wird ein etwas umfangreicheres Protokoll ben”tigt, das mit dem OLE-
|
||
(wird f<>r die Initialisierung verwendet) und OLGA-Protokoll (ist f<>r
|
||
das eigentliche Object Linking zust„ndig) nun zur Verf<72>gung steht.
|
||
|
||
OLGA ist dokumentenzentriert, d.h. das Protokoll ist daf<61>r vorberei-
|
||
tet, daž eine Applikation mehrere Dokumente (evtl. sogar mit komplett
|
||
verschiedenen Datentypen) verwaltet.
|
||
|
||
Zur Verwaltung des OL wird ein OLGA-Manager (Manager) eingesetzt. Die
|
||
Kommunikation bzgl. OL zwischen den Applikationen wird komplett <20>ber
|
||
diesen Manager abgewickelt. Es kann immer nur einen Manager im System
|
||
geben! Die Installation des OLGA-Managers ist im n„chsten Abschnitt
|
||
beschrieben.
|
||
|
||
Drei wichtige Begriffe sind noch zu kl„ren: Ein OLGA-Client (Client)
|
||
ist eine Applikation, mit der Dokumente bearbeitet werden k”nnen, in
|
||
denen Objekte anderer Applikationen benutzt werden. Ein OLGA-Server
|
||
(Server) ist eine Applikation, die die Bearbeitung dieser Objekte
|
||
erm”glicht. Und wer das jetzt zu schnell durchgelesen hat und meint,
|
||
daž beides identisch ist, hat nur ein kleines bižchen Unrecht: In der
|
||
Tat ist es ohne Probleme m”glich, daž eine Applikation gleichzeitig
|
||
Server und Client ist - in den meisten F„llen ist dies sogar sehr
|
||
sinnvoll. Die Programmierung eines Clients ist allerdings aufwendiger,
|
||
das Erweitern einer bestehenden Applikation zu einem Server sollte
|
||
dagegen nur wenige Minuten in Anspruch nehmen!
|
||
|
||
Die Verbindung zwischen Client und Server wird mit sog. Links herge-
|
||
stellt. Ein Link ist eine Referenz des Clients auf ein Objekt. Diese
|
||
Referenz (bei OLGA ist das nur ein Dateiname mit absolutem Pfad) muž
|
||
vom Client im Dokument gespeichert werden. Wenn nun ein Server ein
|
||
Objekt „ndert, auf das ein Link besteht, wird der Client davon unter-
|
||
richtet und kann das ge„nderte Objekt neu darstellen.
|
||
|
||
Und jetzt bitte nicht gleich von dem langen Text abschrecken lassen,
|
||
das meiste sind nur Informations- bzw. Best„tigungsmessages, die f<>r
|
||
das einfache Funktionieren des Protokolls gar nicht ausgewertet werden
|
||
m<EFBFBD>ssen. Weiter unten befindet sich eine Liste der Funktionen, die mi-
|
||
nimal unterst<73>tzt werden m<>ssen (Minimalprotokoll).
|
||
|
||
|
||
2.1 Die OLGA-Architektur
|
||
=========================
|
||
|
||
Das OLGA-Architekturmodell zeigt die Verteilung der Dienste zwischen
|
||
OLGA-Manager und der nutzenden Applikation (d.h. Client oder Server).
|
||
W„hrend Linking, InplaceDrawing und Notification auf einer recht
|
||
ausgewogenen Kommunikation zwischen Manager und Applikation beruhen,
|
||
obliegt das Embedding vollst„ndig der Client-Applikation. Die Info-
|
||
Dateien schliežlich werden durch den Manager koordiniert, laufen aber
|
||
dann direkt zwischen Server- und Client-Applikation ab. Schematisch
|
||
sieht die Kommunikation in etwa wie folgt aus:
|
||
|
||
|
||
|
||
3 Installation des OLGA-Managers
|
||
*********************************
|
||
|
||
Zun„chst sei noch einmal darauf hingewiesen, daž das OLGA-Protokoll
|
||
zwingend ein Multitasking-Betriebssystem voraussetzt (MultiTOS, N.AES,
|
||
MagiC etc.).
|
||
|
||
Man muž sich nun <20>berlegen, ob man den OLGA-Manager st„ndig im
|
||
Speicher haben m”chte oder ob dieser bei Bedarf nachgeladen werden
|
||
soll. Der erste Fall ist sehr einfach, man kopiert den Manager
|
||
OLGA.APP einfach in das Wurzelverzeichnis der Bootpartition und
|
||
benennt die Datei in OLGA.ACC um. Nach einem Neustart des Rechners
|
||
steht OLGA nun permanent zur Verf<72>gung.
|
||
|
||
Der andere Fall ist ein klein wenig komplizierter, hat aber den
|
||
Vorteil, daž sich der OLGA-Manager nur dann im Speicher befindet, wenn
|
||
auch eine OLGA-f„hige Applikation geladen ist. Dazu kopiert man
|
||
OLGA.APP an eine beliebige Stelle (z.B. C:\GEMSYS\OLGA\OLGA.APP) und
|
||
setzt dann die Environmentvariable OLGAMANAGER auf diese Pfadangabe.
|
||
F<EFBFBD>r MultiTOS tr„gt man daf<61>r in GEM.CNF folgendes ein:
|
||
|
||
|
||
setenv OLGAMANAGER=C:\GEMSYS\OLGA\OLGA.APP
|
||
|
||
|
||
MagiC erwartet in MAGX.INF folgende Zeile:
|
||
|
||
|
||
#_ENV OLGAMANAGER=C:\GEMSYS\OLGA\OLGA.APP
|
||
|
||
|
||
Wird nun eine OLGA-f„hige Applikation gestartet, wird der Manager
|
||
automatisch nachgeladen. Aužerdem entfernt sich ein so gestarteter
|
||
Manager selber wieder aus dem System, sobald die letzte OLGA-f„hige
|
||
Applikation beendet wurde.
|
||
|
||
Wie sich OLGA in einer Applikation bemerkbar macht, h„ngt nur von
|
||
dieser selbst ab. Um bei dem Beispiel des Vektorgrafikprogramms zu
|
||
bleiben, k”nnte z.B. beim Doppelklick auf die Rastergrafik ein
|
||
entsprechendes Rastergrafikprogramm nachgeladen werden. Damit sich ein
|
||
Programm auch darum nicht selbst zu k<>mmern braucht, gibt es im OLGA-
|
||
Protokoll die M”glichkeit, den Manager nach einer passenden
|
||
Applikation suchen und diese dann starten zu lassen. Dazu muž
|
||
allerdings der Anwender einmalig seine Lieblingskonfiguration
|
||
festlegen, was in der Datei OLGA.INF geschieht. Diese Datei wird in
|
||
das Verzeichnis von OLGA.APP bzw. OLGA.ACC kopiert (oder nach C:\ -
|
||
allgemeiner: ins Wurzelverzeichnis des Bootlaufwerks - oder nach
|
||
$HOME) und ist wie folgt aufgebaut:
|
||
|
||
|
||
[Extensions]
|
||
.EXT=Dateipfad+Programmname oder ein Alias
|
||
...
|
||
|
||
[Types]
|
||
XY=Dateipfad+Programmname oder ein Alias
|
||
...
|
||
|
||
[Objects]
|
||
.EXT=Klartextbeschreibung des Dateityps
|
||
...
|
||
|
||
[Applications]
|
||
Alias=Dateipfad+Programmname
|
||
...
|
||
|
||
[Manager]
|
||
;NoCrashChecking
|
||
|
||
|
||
Ein ausf<73>hrliches, konkretes Beispiel findet sich im Abschnitt
|
||
"OLGA.INF".
|
||
|
||
Im Block [Extensions] werden also die Programme eingetragen, die
|
||
bestimmte Dateitypen besonders gut bearbeiten k”nnen. Dieses Verfahren
|
||
ist von der Desktop-Funktion "Anwendung anmelden" bekannt. Pro
|
||
Extension kann zur Zeit nur eine Applikation angegeben werden, was
|
||
aber reichen sollte, schliežlich kann der Benutzer hier sein
|
||
"Lieblingsprogramm" eintragen.
|
||
|
||
Im Block [Types] ist es dann noch m”glich, bestimmten Programmtypen
|
||
eine Applikation zuzuweisen. Z.B. kann man unter "ED" einen Editor
|
||
eintragen, mit dem alle m”glichen Textformate bearbeitet werden
|
||
k”nnen. Folgende Typen sind bis jetzt definiert:
|
||
|
||
|
||
+----+----------------------------+
|
||
| CD | CAD |
|
||
+----+----------------------------+
|
||
| DB | Datenbank |
|
||
+----+----------------------------+
|
||
| DC | Datenkommunikation |
|
||
+----+----------------------------+
|
||
| DP | DTP |
|
||
+----+----------------------------+
|
||
| DT | Desktop |
|
||
+----+----------------------------+
|
||
| ED | Texteditor |
|
||
+----+----------------------------+
|
||
| GG | allgemeines Grafikprogramm |
|
||
+----+----------------------------+
|
||
| MU | Musikanwendung |
|
||
+----+----------------------------+
|
||
| MV | Movie/Video |
|
||
+----+----------------------------+
|
||
| PE | Programmierumgebung |
|
||
+----+----------------------------+
|
||
| RG | Rastergrafikprogramm |
|
||
+----+----------------------------+
|
||
| SS | Tabellenkalkulation |
|
||
+----+----------------------------+
|
||
| VG | Vektorgrafikprogramm |
|
||
+----+----------------------------+
|
||
| WP | Textverarbeitung |
|
||
+----+----------------------------+
|
||
|
||
Wem die Typen bekannt vorkommen: Es sind die beim XAcc-Protokoll
|
||
verwendeten maschinenlesbaren Programmtypen.
|
||
|
||
[Objects] ist f<>r InplaceDrawing (ID4-OLGA) interessant. Damit ID4
|
||
funktioniert, m<>ssen hier die von den vorhandenen ID4-Servern
|
||
unterst<EFBFBD>tzten Extensions eingetragen werden. Diese Extensions m<>ssen
|
||
auch in [Extensions] der entsprechenden Applikation zugeordnet sein.
|
||
|
||
[Applications] schliežlich dient dazu, die šbersicht in OLGA.INF zu
|
||
verbessern. Dieser Block ist optional und muž nicht verwendet werden.
|
||
|
||
Im Abschnitt [Manager] werden ab OLGA 1.5 Konfigurationsflags f<>r den
|
||
OLGA-Manager selbst eingetragen. Im Moment gibt es nur den Schalter
|
||
"NoCrashChecking". Wenn dieser Eintrag vorhanden (und nicht
|
||
auskommentiert) ist, pr<70>ft der Manager nicht auf abgest<73>rzte
|
||
Applikationen. Normalerweise sollte der Eintrag daher fehlen.
|
||
|
||
Damit ist die Installation abgeschlossen. Starten Sie Ihren Rechner
|
||
neu und <20>berpr<70>fen Sie mit den OLGA-Tools, ob die Installation
|
||
erfolgreich war.
|
||
|
||
|
||
3.1 OLGA-Tools
|
||
===============
|
||
|
||
Mit dem Programm "OLGA-Tools" k”nnen Sie eine bestehende OLGA-
|
||
Installation komfortabel und einfach bearbeiten. Aužerdem kann man per
|
||
Knopfdruck <20>berpr<70>fen lassen, ob alle Programmangaben etc. in OLGA.INF
|
||
korrekt sind.
|
||
|
||
Dieser Abschnitt beschreibt das Arbeiten mit den OLGA-Tools in der
|
||
Version 1.50 vom 08.06.1998. Derzeit ist "nur" das šberpr<70>fen der
|
||
Installation, nicht aber das Einrichten des OLGA-Managers m”glich -
|
||
dazu wird immer noch ein externer Editor ben”tigt.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Um OLGA.INF zu <20>berpr<70>fen, starten Sie die OLGA-Tools und rufen den
|
||
Dialog "Optionen - šberpr<70>fen..." auf. Derzeit k”nnen Sie nur OLGA.INF
|
||
auf fehlerhafte Eintr„ge <20>berpr<70>fen lassen, weitere Optionen werden in
|
||
einer sp„teren Version folgen.
|
||
|
||
Wenn Sie das Ergebnis der šberpr<70>fung als Bugreport verwenden wollen,
|
||
schalten Sie bitte auch "Systeminformationen ausgeben" ein. Dadurch
|
||
werden die wichtigsten Eigenschaften und Versionsnummern Ihres Systems
|
||
nach dem Pr<50>fbericht ausgegeben.
|
||
|
||
Durch Anw„hlen von "OK" wird die šberpr<70>fung gestartet. Es erscheint
|
||
ein Ausgabefenster, in dem eventuelle Fehlermeldungen (mit der
|
||
Zeilenangabe in OLGA.INF) ausgegeben werden. Wenn Sie diese Liste
|
||
durcharbeiten, k”nnen Sie Ihre OLGA.INF nach und nach korrigieren.
|
||
Wenn als Anzahl der Fehler und Warnungen jeweils Null ausgegeben
|
||
wurde, ist Ihre OLGA.INF korrekt.
|
||
|
||
Sollten Sie zu Beginn der šberpr<70>fung mit einer Dateiauswahlbox nach
|
||
Ihrer OLGA.INF gefragt werden, ist dies kein gutes Zeichen... In
|
||
diesem Fall ist nicht garantiert, daž der OLGA-Manager die von Ihnen
|
||
gew<EFBFBD>nschte Datei auch wirklich findet und auswertet. Optimale Orte f<>r
|
||
OLGA.INF sind $HOME oder das Boot-Wurzelverzeichnis.
|
||
|
||
|
||
|
||
4 Das OLGA-Protokoll...
|
||
************************
|
||
|
||
|
||
4.1 ...als Minimalversion
|
||
==========================
|
||
|
||
Im folgenden sind die Messages aufgelistet, die Server bzw. Client
|
||
minimal unterst<73>tzen m<>ssen, um eine korrekte Protokollbehandlung zu
|
||
gew„hrleisten.
|
||
|
||
|
||
4.1.1 Server
|
||
-------------
|
||
|
||
ù OLE_INIT verschicken
|
||
|
||
ù OLE_NEW auswerten
|
||
|
||
ù OLGA_INIT empfangen
|
||
|
||
ù OLE_EXIT verschicken
|
||
|
||
ù VA_START unterst<73>tzen (s. Gemini-Doku, AV-Protokoll)
|
||
|
||
Damit der Server auch wirklich als solcher fungiert, muž nat<61>rlich
|
||
noch die Message OLGA_UPDATE verschickt werden.
|
||
|
||
|
||
4.1.2 Client
|
||
-------------
|
||
|
||
ù OLE_INIT verschicken
|
||
|
||
ù OLE_NEW auswerten
|
||
|
||
ù OLGA_INIT empfangen
|
||
|
||
ù OLE_EXIT verschicken
|
||
|
||
ù auf OLGA_RENAMELINK mit OLGA_LINKRENAMED antworten
|
||
|
||
ù auf OLGA_LINKBROKEN mit OLGA_UNLINK antworten
|
||
|
||
Ein Client sollte sinnvollerweise auch auf OLGA_UPDATED reagieren.
|
||
|
||
|
||
4.2 ...f<>r Server und Client
|
||
=============================
|
||
|
||
Das OLGA-Protokoll besteht im wesentlichen aus dem Kommunikation mit
|
||
dem OLGA-Manager. Dazu muž man die AES-ID des Managers kennen, die wie
|
||
folgt ermittelt wird:
|
||
|
||
1. Wenn appl_find("OLGA ") erfolgreich ist, hat man den Manager
|
||
schon gefunden.
|
||
|
||
2. Ansonsten wird nun die Environmentvariable OLGAMANAGER
|
||
ausgewertet. Dort kann ein kompletter Zugriffspfad stehen!
|
||
Zun„chst extrahiert man aus diesem Pfad einen Programmnamen f<>r
|
||
appl_find() und geht entsprechend wie unter dem ersten Punkt vor.
|
||
Konnte auch dieser Name nicht gefunden werden, startet man das
|
||
Programm, das von OLGAMANAGER bezeichnet wird, mit shel_write()
|
||
nach.
|
||
|
||
3. Wenn das bisherige nicht zum Erfolg gef<65>hrt hat, kann man die
|
||
ersten beiden Punkte nochmal mit einem appl_find("OLEMANGR") bzw.
|
||
der Environmentvariablen OLEMANAGER durchf<68>hren. Dieser Punkt ist
|
||
aber mittlerweile obsolet und kann daher auch problemlos
|
||
ignoriert werden.
|
||
|
||
Hat man die AES-ID des OLGA-Managers gefunden, wird dieser zun„chst
|
||
mit dem OLE-Protokoll initialisiert.
|
||
|
||
|
||
4.2.1 Nachstarten des OLGA-Managers
|
||
------------------------------------
|
||
|
||
In diesem Abschnitt gibt es einen Algorithmus zum Finden bzw.
|
||
Nachstarten des OLGA-Manager als Pseudo-Pascal-Code, der mit MagiC,
|
||
MultiTOS etc. funktioniert.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
|
||
OLGAManager:=appl_find('OLGA ');
|
||
|
||
if (OLGAManager < 0) then
|
||
begin
|
||
envstr:=GetEnv('OLGAMANAGER');
|
||
|
||
if (length(envstr) > 0) then
|
||
begin
|
||
// Dateinamen in Groábuchstaben und ohne Extension
|
||
// aus envstr extrahieren
|
||
datei:=StrPUpper(GetFilename(envstr,false));
|
||
|
||
// Dateinamen evtl. mit Leerzeichen auff<66>llen, damit
|
||
// der Name exakt acht Zeichen lang ist
|
||
datei:=datei+StrPSpace(8-length(datei));
|
||
|
||
OLGAManager:=appl_find(datei);
|
||
|
||
if (OLGAManager < 0) then
|
||
begin
|
||
// der Manager l„uft noch nicht, wir m<>ssen
|
||
// ihn also nachstarten
|
||
|
||
OLGAManager:=StartApp(datei);
|
||
end
|
||
end
|
||
end;
|
||
|
||
if (OLGAManager >= 0) then
|
||
begin
|
||
// OLE_INIT an OLGAManager schicken
|
||
end;
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
|
||
function StartApp(prg: string): integer;
|
||
|
||
begin
|
||
ret:=-1;
|
||
|
||
if (MultiTOS or MagiC) then
|
||
if (Exist(prg)) then
|
||
begin
|
||
if MagiC then ret:=shel_write(1,100,@prg,NULL)
|
||
else
|
||
ret:=shel_write(0,1,@prg,NULL);
|
||
end;
|
||
|
||
StartApp:=ret;
|
||
end;
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
|
||
4.2.2 OLE_INIT
|
||
---------------
|
||
|
||
Hat man einen (bzw. zwei, s.o.) Manager gefunden, schickt man ihm
|
||
folgende Message:
|
||
|
||
|
||
OLE_INIT
|
||
(Client/Server -> Manager)
|
||
msg[0] $4950 (18768)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3] Bitmap, OL_SERVER und/oder OL_CLIENT gesetzt, OL_IDLE
|
||
msg[4] max. von der App. verstandene Stufe des Protokolls
|
||
(z.Z. immer 0)
|
||
msg[5] reserviert (auf 0 setzen)
|
||
msg[6] reserviert (auf 0 setzen)
|
||
msg[7] maschinenlesbarer XAcc-Programmtyp (oder 0):
|
||
"WP" = Textverarbeitung
|
||
"DP" = DTP
|
||
"ED" = Texteditor
|
||
"DB" = Datenbank
|
||
"SS" = Tabellenkalkulation
|
||
"RG" = Rastergrafikprogramm
|
||
"VG" = Vektorgrafikprogramm
|
||
"GG" = allgemeines Grafikprogramm
|
||
"MU" = Musikanwendung
|
||
"MV" = Movie/Video
|
||
"CD" = CAD
|
||
"DC" = Datenkommunikation
|
||
"DT" = Desktop
|
||
"PE" = Programmierumgebung
|
||
|
||
OL_SERVER = $0001 Applikation ist OLGA-Server
|
||
OL_CLIENT = $0002 Applikation ist OLGA-Client
|
||
OL_PEER = $0003 Applikation ist Client und Server
|
||
OL_IDLE = $0800 Applikation unterst<73>tzt den Idle-Test
|
||
OL_PIPES = $1000 Applikation m”chte nicht <20>ber Pointer, sondern
|
||
<20>ber MTOS-D&D-Pipes kommunizieren; der Manager
|
||
meldet dann, ob er diese Kommunikation beherrscht
|
||
bzw. ob sie auf dem aktuellen System m”glich ist
|
||
(s.u.); das Verfahren wird z.Z. noch nicht unter-
|
||
st<73>tzt, eine genauere Definition folgt sp„ter
|
||
|
||
|
||
Daraufhin erh„lt man vom Manager eine OLGA_INIT-Message.
|
||
|
||
|
||
4.2.3 OLGA_INIT
|
||
----------------
|
||
|
||
Der OLGA-Manager verschickt als Best„tigung die OLGA_INIT-Message.
|
||
Wichtig: Applikationen sollten den OLGA-Mechanismus erst verwenden,
|
||
nachdem sie folgende Message erhalten haben und diese keinen Fehler
|
||
signalisiert hat (f<>r Applikationen, die w„hrend der Startphase
|
||
Dokumente ”ffnen, kann es sinnvoll sein, auch ohne empfangene
|
||
OLGA_INIT-Message die n”tigen OLGA-Messages zu verschicken, nur
|
||
sollten bei der Applikation keine Fehlfunktionen auftreten, falls sich
|
||
der Manager doch nicht meldet).
|
||
|
||
|
||
OLGA_INIT
|
||
(Manager -> Client/Server)
|
||
[0] $1236 (4662)
|
||
[1] apID
|
||
[2] 0
|
||
[3] Bitmap, OL_MANAGER+OL_START+OL_IDLE+OL_CONF gesetzt
|
||
[4] Stufe des verwendeten (!) Protokolls (z.Z. immer 0)
|
||
[5] 0
|
||
[6] 0
|
||
[7] 0=Fehler, sonst: OL-Mechanismus verf<72>gbar
|
||
|
||
OL_CONF = $0400 Manager unterst<73>tzt OLGA_GETSETTINGS
|
||
OL_IDLE = $0800 Manager unterst<73>tzt den Idle-Test
|
||
OL_PIPES = $1000 Manager verwendet zur Kommunikation MTOS-D&D-
|
||
Pipes (nur nach Anforderung, s.o., wird z.Z.
|
||
noch nicht unterst<73>tzt und ist daher nie
|
||
gesetzt!)
|
||
OL_START = $2000 Manager kann OLGA_START ausf<73>hren
|
||
OL_MANAGER = $4000 Applikation ist der OLGA-Manager
|
||
|
||
|
||
|
||
4.2.4 OLE_EXIT
|
||
---------------
|
||
|
||
Beim Programmende wird dem Manager folgende Message geschickt (die
|
||
Nachricht wird aužerdem von Manager an die Applikationen verschickt,
|
||
sollte dieser terminieren). Wenn sich ein OLGA-Client abmeldet, werden
|
||
automatisch alle zugeh”rigen Links und Documents gel”scht.
|
||
|
||
|
||
OLE_EXIT
|
||
(Client/Server -> Manager, Manager -> Client/Server)
|
||
msg[0] $4951 (18769)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3] 0
|
||
msg[4] 0
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
|
||
4.2.5 OLE_NEW
|
||
--------------
|
||
|
||
Wenn ein Manager nachgestartet wird, verschickt er an alle
|
||
erreichbaren Applikationen folgende Message:
|
||
|
||
|
||
OLE_NEW
|
||
(Manager -> Client/Server)
|
||
msg[0] $4952 (18770)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3] Bitmap (OL_MANAGER, OL_START, OL_IDLE, OL_CONF)
|
||
msg[4] max. Manager-Stufe des OLGA-Protokolls
|
||
msg[5] reserviert (auf 0 setzen)
|
||
msg[6] reserviert (auf 0 setzen)
|
||
msg[7] Versionsnummer des Managers, z.B. $0114 f<>r 1.14
|
||
|
||
|
||
Nach Empfang und Auswertung dieser Message sollte eine Applikation
|
||
OLE_INIT verschicken. Die Werte in OLE_NEW ersetzen nicht die R<>ckgabe
|
||
von OLGA_INIT, sie dienen nur zu Informationszwecken!
|
||
|
||
|
||
4.3 ...aus der Sicht des Servers
|
||
=================================
|
||
|
||
|
||
4.3.1 OLGA_UPDATE
|
||
------------------
|
||
|
||
Wenn der Server irgend eine Datei abgespeichert hat, wird an den
|
||
OLGA-Manager folgende Message geschickt: (Die Grož-/Kleinschreibung
|
||
des Dateinamens wird im Moment ignoriert, damit das Linking nicht an
|
||
unterschiedlichen Benutzereingaben scheitert; auf erweiterten
|
||
Filesystemen wird das sp„ter allerdings nicht mehr so sein.)
|
||
|
||
|
||
OLGA_UPDATE
|
||
(Server -> Manager)
|
||
[0] $1238 (4664)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den kompletten Dateinamen incl. (absolutem!) Pfad
|
||
[4]
|
||
[5] 0 bzw. Server-interne (eindeutige) Index-Nummer, falls eine Info-Datei
|
||
zur Verf<72>gung steht oder erzeugt werden kann (s. OLGA_GETINFO)
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Als Antwort erh„lt der Server folgende Message, worauf er z.B.
|
||
allozierten Speicherplatz f<>r den Dateinamen wieder freigeben kann:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Server)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ exakt dieselben Wert von OLGA_UPDATE
|
||
[4]
|
||
[5] 0
|
||
[6] 0
|
||
[7] OLGA_UPDATE
|
||
|
||
|
||
|
||
4.3.2 OLGA_GETINFO
|
||
-------------------
|
||
|
||
Wenn der Server bei OLGA_UPDATE eine Index-Nummer f<>r eine Info-Datei
|
||
bekanntgegeben hat, kann ein Client (!) letztere nun direkt beim
|
||
Server abfragen. Nach dem Empfangen von OLGA_GETINFO kann der Server
|
||
eine solche Datei erzeugen (Aufbau s.u.), falls sie noch nicht
|
||
existiert. Zu beachten ist, daž die <20>bergebene Index-Nummer nicht
|
||
g<EFBFBD>ltig sein muž, die OLGA_GETINFO-Message muž dann vom Server
|
||
ignoriert werden!
|
||
|
||
|
||
OLGA_GETINFO
|
||
(Client -> Server)
|
||
[0] $1247 (4679)
|
||
[1] apID
|
||
[2] 0
|
||
[3] 0
|
||
[4] 0
|
||
[5] Index-Nummer der gew<65>nschten Info-Datei
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
|
||
4.3.3 OLGA_INFO
|
||
----------------
|
||
|
||
Als Antwort auf OLGA_GETINFO verschickt der Server direkt an den
|
||
Client (!) folgende Message (nachdem die Info-Datei erzeugt wurde -
|
||
falls sie nicht sogar st„ndig vorhanden ist).
|
||
|
||
|
||
OLGA_INFO
|
||
(Server -> Client)
|
||
[0] $1248 (4680)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den kompletten Info-Dateinamen incl. (absolutem!) Pfad
|
||
[4]
|
||
[5] Index-Nummer der gew<65>nschten Info-Datei
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Der Client darf sich allerdings nicht auf eine solche Antwort
|
||
verlassen, der Server k”nnte ja mittlerweile terminiert haben.
|
||
Aužerdem darf der Client nur lesend auf die Datei zugreifen.
|
||
|
||
Sobald der Client die Datei wieder geschlossen hat, teilt er dies dem
|
||
Server direkt (!) mit, damit dieser die Datei evtl. wieder l”schen
|
||
kann.
|
||
|
||
|
||
OLGA_ACK
|
||
(Client -> Server)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ exakt dieselben Werte von OLGA_INFO
|
||
[4]
|
||
[5] Index-Nummer der gew<65>nschten Info-Datei
|
||
[6] 0
|
||
[7] OLGA_INFO
|
||
|
||
|
||
|
||
4.3.4 OLGA_RENAME
|
||
------------------
|
||
|
||
Wenn der Benutzer eine Datei im Server umbenennt (oder verschiebt!),
|
||
schickt der Server dem Manager die OLGA_RENAME-Message. Es liegt im
|
||
Ermessen des Servers, ob er nach "Speichern als..." eine solche
|
||
Message verschickt (das h„ngt z.B. auch davon ab, ob der Server selbst
|
||
die neue Pfadangabe bzw. den neuen Dateinamen f<>r das bestehende
|
||
Dokument <20>bernimmt); nach M”glichkeit sollten Links aber immer nur f<>r
|
||
Dateien auf nicht wechselbaren Medien bestehen (A: und B: sind also
|
||
denkbar schlechte Kandidaten). Wenn zus„tzlich der Dateiinhalt
|
||
ver„ndert wurde, muž nach der OLGA_RENAME-Message aužerdem noch eine
|
||
OLGA_UPDATE-Message verschickt werden!
|
||
|
||
|
||
OLGA_RENAME
|
||
(Server -> Manager)
|
||
[0] $123a (4666)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den alten Dateinamen incl. absolutem Pfad
|
||
[4]
|
||
[5]
|
||
+ Pointer auf den neuen Dateinamen incl. absolutem Pfad
|
||
[6]
|
||
[7] 0
|
||
|
||
|
||
Als Antwort erh„lt der Server wiederum eine Message, die er z.B. zum
|
||
Freigeben des alten Speicherplatzes verwenden kann. Diese Best„tigung
|
||
bedeutet allerdings nur, daž der Manager das Umbenennen weitergemeldet
|
||
hat, wenn ein Client nicht darauf reagiert, ist der entsprechende Link
|
||
dann "tot".
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Server)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ exakt dieselben Wert von OLGA_RENAME
|
||
[4]
|
||
[5]
|
||
+ exakt dieselben Wert von OLGA_RENAME
|
||
[6]
|
||
[7] OLGA_RENAME
|
||
|
||
|
||
|
||
4.3.5 OLGA_BREAKLINK
|
||
---------------------
|
||
|
||
Sollte der Server eine Datei l”schen (oder anderweitig f<>r den Client
|
||
unbrauchbar machen), muž er dies dem Manager mit folgender Message
|
||
mitteilen. Der Manager verst„ndigt dann alle Clients, die einen Link
|
||
auf diese Datei gesetzt hatten.
|
||
|
||
|
||
OLGA_BREAKLINK
|
||
(Server -> Manager)
|
||
[0] $1244 (4676)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den Dateinamen incl. absolutem Pfad
|
||
[4]
|
||
[5] 0
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Auch hierauf verschickt der Manager eine Antwort an den Server:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Server)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ exakt dieselben Wert von OLGA_BREAKLINK
|
||
[4]
|
||
[5] 0
|
||
[6] 0
|
||
[7] OLGA_BREAKLINK
|
||
|
||
|
||
|
||
4.3.6 OLGA_CLIENTTERMINATED
|
||
----------------------------
|
||
|
||
Wenn ein Client terminiert, der einen Server per OLGA_START aufgerufen
|
||
hat, erh„lt dieser Server folgende Message:
|
||
|
||
|
||
OLGA_CLIENTTERMINATED
|
||
(Manager -> Server)
|
||
[0] $1255 (4693)
|
||
[1] manID
|
||
[2] 0
|
||
[3] AES-ID des terminierten Clients
|
||
[4] Anzahl der Clients, die den Server noch benutzen (>=0)
|
||
[5] 0
|
||
[6] 0
|
||
[7] 1, wenn der Server bei OLGA_START schon lief; 0 sonst
|
||
|
||
|
||
|
||
4.4 ...aus der Sicht des Clients
|
||
=================================
|
||
|
||
|
||
4.4.1 OLGA_OPENDOC
|
||
-------------------
|
||
|
||
Wenn ein OLGA-Client ein Dokument ”ffnet (egal ob schon bestehend oder
|
||
neu), kann (!) dem OLGA-Manager folgende Message geschickt werden. Sie
|
||
dient z.Z. nur zu Informationszwecken, die ben”tigten internen
|
||
Strukturen werden vom Manager ansonsten beim Empfangen der ersten
|
||
OLGA_LINK-Message angelegt. Die Gruppenkennung sollte allerdings
|
||
trotzdem (wenn auch nur Client-intern) festgelegt werden, da sie f<>r
|
||
die Links ben”tigt wird.
|
||
|
||
|
||
OLGA_OPENDOC
|
||
(Client -> Manager)
|
||
[0] $123b (4667)
|
||
[1] apID
|
||
[2] 0
|
||
[3] 0
|
||
[4] 0
|
||
[5] Gruppenkennung (eine innerhalb des Clients eindeutige, vom Client
|
||
frei w„hlbare Zahl, mit der die Links innerhalb des Clients den
|
||
Dokumenten zugeordnet werden k”nnen)
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Als Antwort erh„lt der Client folgende Message:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Client)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3] 0
|
||
[4] 0
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0
|
||
[7] OLGA_OPENDOC
|
||
|
||
|
||
|
||
4.4.2 OLGA_CLOSEDOC
|
||
--------------------
|
||
|
||
Schliežt ein Client ein Dokument, das Links enth„lt, sollte dem OLGA-
|
||
Manager folgende Message geschickt werden, die alle Links mit der
|
||
entsprechenden Gruppenkennung l”scht. Das kann zwar auch mit einzelnen
|
||
OLGA_UNLINK-Aufrufen geschehen, aber so k”nnen Manager-interne
|
||
Strukturen einfacher freigegeben werden (aužerdem ist es einfacher f<>r
|
||
den Programmierer :-). Darf beim Programmende nicht verwendet werden,
|
||
da OLE_EXIT alle Documents l”scht.
|
||
|
||
|
||
OLGA_CLOSEDOC
|
||
(Client -> Manager)
|
||
[0] $123c (4668)
|
||
[1] apID
|
||
[2] 0
|
||
[3] 0
|
||
[4] 0
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Als Antwort erh„lt der Client folgende Message:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Client)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3] 0
|
||
[4] 0
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0
|
||
[7] OLGA_CLOSEDOC
|
||
|
||
|
||
|
||
4.4.3 OLGA_LINK
|
||
----------------
|
||
|
||
Mit der folgendes Message teilt ein Client dem Manager mit, daž eine
|
||
Datei in eines seiner Dokumente eingebunden wurde - allerdings in der
|
||
Form, daž nur eine Referenz (hier der Dateiname mit absolutem Pfad)
|
||
gespeichert wird. Wenn diese Datei von einem OLGA-Server ver„ndert
|
||
wird (oder eine AV_PATH_UPDATE-Message von einem Programm empfangen
|
||
wird, das kein Server ist), erh„lt der Client dann eine OLGA_UPDATED
|
||
Message.
|
||
|
||
|
||
OLGA_LINK
|
||
(Client -> Manager)
|
||
[0] $123d (4669)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den Dateinamen, der <20>berwacht werden soll
|
||
[4] (incl. absolutem Pfad)
|
||
[5] Gruppenkennung des Dokuments (s. OLGA_OPENDOC)
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Als Best„tigung verschickt der Manager folgende Message:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Client)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ exakt dieselben Wert von OLGA_LINK
|
||
[4]
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0=Fehler, sonst: Link eingerichtet
|
||
[7] OLGA_LINK
|
||
|
||
|
||
|
||
4.4.4 OLGA_UNLINK
|
||
------------------
|
||
|
||
Soll die šberwachung f<>r eine Datei beendet werden, muž der Client dem
|
||
Manager folgende Message schicken. Beim Schliežen eines Dokuments
|
||
sollte stattdessen allerdings OLGA_CLOSEDOC verwendet werden, beim
|
||
Beenden der Client-Applikation werden die Links mit OLE_EXIT
|
||
automatisch gel”scht.
|
||
|
||
|
||
OLGA_UNLINK
|
||
(Client -> Manager)
|
||
[0] $123e (4670)
|
||
[1] apID
|
||
[2] 0
|
||
[3] Pointer auf den Dateinamen (incl. absolutem Pfad), der nicht mehr
|
||
+ <20>berwacht werden soll (muá exakt mit der Zeichenkette aus OLGA_LINK
|
||
[4] <20>bereinstimmen)
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Als Best„tigung erh„lt der Client folgende Message:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Client)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ exakt dieselben Wert von OLGA_UNLINK
|
||
[4]
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0=Fehler, sonst: Link entfernt
|
||
[7] OLGA_UNLINK
|
||
|
||
|
||
|
||
4.4.5 OLGA_UPDATED
|
||
-------------------
|
||
|
||
Und mit der n„chsten Message werden dem Client Žnderungen an einer
|
||
Datei vom Manager mitgeteilt! Wenn der Client also eine solche Message
|
||
empf„ngt, sollte das zugeh”rige Dokument neu angezeigt werden. Der
|
||
Pointer ist solange g<>ltig, wie der Link besteht.
|
||
|
||
|
||
OLGA_UPDATED
|
||
(Manager -> Client)
|
||
[0] $123f (4671)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den Dateinamen (incl. absolutem Pfad) der Datei,
|
||
[4] die ver„ndert wurde
|
||
[5] 0 bzw. Index-Nummer, falls eine Info-Datei angefordert werden kann
|
||
[6] apID des Updaters (Server); garantiert gesetzt, wenn [5] ungleich null;
|
||
an diese ID kann eine OLGA_GETINFO-Message geschickt werden
|
||
[7] Gruppenkennung des Dokuments
|
||
|
||
|
||
Wenn dem Client bei dieser Message das Vorhandensein einer Info-Datei
|
||
(Aufbau s.u.) gemeldet wird und der Client diese anfordern m”chte,
|
||
sollte er so schnell wie m”glich dem Server direkt (!) eine
|
||
OLGA_GETINFO-Message schicken. Dieses Vorgehen ist bereits weiter oben
|
||
("...aus der Sicht des Servers") beschrieben.
|
||
|
||
|
||
4.4.6 OLGA_RENAMELINK
|
||
----------------------
|
||
|
||
Wenn ein Server eine Datei umbenannt oder verschoben hat, erh„lt der
|
||
Client folgende Message. Sie dient nur dazu, daž der Client seine
|
||
interne Referenz aktualisiert, d.h. das Dokument muž nicht neu
|
||
gezeichnet werden! Der Pointer auf den neuen Namen ist solange g<>ltig,
|
||
wie der Link besteht.
|
||
|
||
|
||
OLGA_RENAMELINK
|
||
(Manager -> Client)
|
||
[0] $1240 (4672)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den alten Dateinamen incl. absolutem Pfad
|
||
[4]
|
||
[5]
|
||
+ Pointer auf den neuen Dateinamen incl. absolutem Pfad
|
||
[6]
|
||
[7] Gruppenkennung des Dokuments
|
||
|
||
|
||
|
||
4.4.7 OLGA_LINKRENAMED
|
||
-----------------------
|
||
|
||
Als Antwort auf OLGA_RENAMELINK muž der Client an den Manager folgende
|
||
Message schicken, damit letzterer seine Referenz aktualisiert und
|
||
unn”tigen Speicherplatz freigibt (der Client muž dazu nur die
|
||
Messagenummer austauschen). Unterbleibt diese Antwort, ist der
|
||
entsprechende Link "tot", kann also nicht mehr <20>berwacht werden (da ja
|
||
im Manager dann noch der alte Name gespeichert ist).
|
||
|
||
|
||
OLGA_LINKRENAMED
|
||
(Client -> Manager)
|
||
[0] $1241 (4673)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den alten Dateinamen incl. absolutem Pfad
|
||
[4]
|
||
[5]
|
||
+ Pointer auf den neuen Dateinamen incl. absolutem Pfad
|
||
[6]
|
||
[7] Gruppenkennung des Dokuments
|
||
|
||
|
||
|
||
4.4.8 OLGA_LINKBROKEN
|
||
----------------------
|
||
|
||
Wenn eine Datei dem Client pl”tzlich nicht mehr zur Verf<72>gung steht
|
||
(z.B. weil sie gel”scht wurde), wird dies vom Manager mit folgender
|
||
Message mitgeteilt. Der Client kann daraufhin z.B. den Benutzer
|
||
informieren oder per Fileselectbox eine andere Datei ausw„hlen lassen.
|
||
|
||
|
||
OLGA_LINKBROKEN
|
||
(Manager -> Client)
|
||
[0] $1245 (4677)
|
||
[1] apID
|
||
[2] 0
|
||
[3]
|
||
+ Pointer auf den Dateinamen incl. absolutem Pfad
|
||
[4]
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
Aužerdem sollte der Client den jetzt ung<6E>ltigen Link mit der normalen
|
||
Unlink-Message aufl”sen:
|
||
|
||
|
||
OLGA_UNLINK
|
||
(Client -> Manager)
|
||
[0] $123e (4670)
|
||
[1] apID
|
||
[2] 0
|
||
[3] Pointer auf den Dateinamen (incl. absolutem Pfad), der nicht mehr
|
||
+ <20>berwacht werden kann (es k”nnen auch exakt die Werte aus
|
||
[4] OLGA_LINKBROKEN <20>bergeben werden!)
|
||
[5] Gruppenkennung des Dokuments
|
||
[6] 0
|
||
[7] 0
|
||
|
||
|
||
|
||
4.4.9 OLGA_START
|
||
-----------------
|
||
|
||
F<EFBFBD>r Clients bietet der Manager eine einfache M”glichkeit, passende
|
||
Server nachzustarten bzw. aufzurufen. Dazu wird (bei OLS_TYPE und
|
||
OLS_EXTENSION) die Datei OLGA.INF ausgewertet. Zun„chst wird der darin
|
||
gefundene Server im Speicher gesucht und bei Erfolg mit VA_START (s.
|
||
Gemini-Doku) aufgerufen. Ansonsten wird das Programm unter MultiTOS
|
||
bzw. MagiC mit shel_write() nachgestartet.
|
||
|
||
|
||
OLGA_START
|
||
(Client -> Manager)
|
||
[0] $1246 (4678)
|
||
[1] apID
|
||
[2] 0
|
||
[3] eine der OLS-Konstanten (s.u.)
|
||
[4]
|
||
+ Angaben, welches(r) Programm(typ) gestartet werden soll
|
||
[5] (abh„ngig von [3], s.u.)
|
||
[6]
|
||
+ Pointer auf Kommandozeile (i.A. die zu ladende Datei) oder NULL
|
||
[7]
|
||
|
||
OLS_TYPE = $0001 [4]=0, in [5] steht ein XAcc-Programmtyp
|
||
OLS_EXTENSION = $0002 in [4]+[5] steht eine Extension (z.B. ".GEM")
|
||
OLS_NAME = $0003 in [4]+[5] steht ein Pointer auf den absoluten
|
||
Dateinamen der zu startenden Applikation
|
||
|
||
|
||
Als Best„tigung erh„lt man folgende Message:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Client)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3] OLS-Konstante von OLGA_START
|
||
[4]
|
||
+ exakt dieselben Wert von OLGA_START
|
||
[5]
|
||
[6] 0=Fehler, sonst: Server gestartet
|
||
[7] OLGA_START
|
||
|
||
|
||
Um die Kommandozeile leichter freigeben zu k”nnen, erh„lt man aužerdem
|
||
noch eine zweite Message (wenn f<>r die Kommandozeile nicht NULL
|
||
<EFBFBD>bergeben wurde).
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Client)
|
||
[0] $1239 (4665)
|
||
[1] apID
|
||
[2] 0
|
||
[3] 0 (!)
|
||
[4]
|
||
+ exakt dieselben Wert von OLGA_START [6]+[7]
|
||
[5]
|
||
[6] 0=Fehler, sonst: Server gestartet
|
||
[7] OLGA_START
|
||
|
||
|
||
|
||
4.4.10 OLGA_SERVERTERMINATED
|
||
-----------------------------
|
||
|
||
Wenn ein Server terminiert, erhalten alle Clients, die diesen Server
|
||
per OLGA_START aufgerufen haben, folgende Message:
|
||
|
||
|
||
OLGA_SERVERTERMINATED
|
||
(Manager -> Client)
|
||
[0] $1254 (4692)
|
||
[1] manID
|
||
[2] 0
|
||
[3] AES-ID des terminierten Servers
|
||
[4]
|
||
+ Extension oder (0,XAcc-Typ) oder NULL
|
||
[5]
|
||
[6] reserviert
|
||
[7] 0
|
||
|
||
|
||
Je nachdem, in welchem Modus der Server nachgestartet wurde, enthalten
|
||
die Felder [4..5] unterschiedliche Werte. Beim Start mit OLS_EXTENSION
|
||
steht dort eben diese Extension, beim Start mit OLS_TYPE ist [4]=0 und
|
||
[5] enth„lt den XAcc-Programmtyp. Beim Start mit OLS_NAME sind beide
|
||
Felder ausgenullt.
|
||
|
||
|
||
|
||
5 InplaceDrawing
|
||
*****************
|
||
|
||
Damit InplaceDrawing (ID4-OLGA, ID4) funktionieren kann, muž der
|
||
OLGA-Manager korrekt installiert (siehe "Installation des OLGA-
|
||
Managers") und OLGA.INF entsprechend angepažt sein (Abschnitte
|
||
[Extensions] und [Objects]). ID4-Server und -Clients sind ganz normale
|
||
OLGA-Server und -Clients, die sich zus„tzlich an das im folgenden
|
||
vorgestellte Protokoll halten.
|
||
|
||
|
||
5.1 ID4-Client
|
||
===============
|
||
|
||
ID4-Clients betten Objekte in ihre Dokumente ein (man nennt diese
|
||
Clients deshalb auch "Containerapplikationen"). Ein Client ermittelt
|
||
mit OLGA_GETOBJECTS alle in OLGA.INF eingetragenen ID4-Objekte, um dem
|
||
Anwender z.B. den folgenden Dialog anbieten zu k”nnen:
|
||
|
||
Pro Objekt, das eingebettet werden soll, muž ein ID4-Client folgende
|
||
Struktur im globalen Speicher anlegen (siehe auch OLGA.H und
|
||
OLGA.INC):
|
||
|
||
|
||
typedef struct ObjectInfo
|
||
{
|
||
char *Filename;
|
||
AESPB *ClientGEMPB;
|
||
long ClientData,
|
||
ServerData;
|
||
int CBLock,
|
||
CBCount;
|
||
void cdecl (*CBDraw) (ObjectInfo *objectinfo,
|
||
int outScreen,
|
||
int outHandle,
|
||
int outDevID,
|
||
GRECT *Size,
|
||
GRECT *Clip);
|
||
void cdecl (*CBUnembed) (ObjectInfo *objectinfo);
|
||
void cdecl (*CBXDraw) (ObjectInfo *objectinfo,
|
||
int outScreen,
|
||
int outHandle,
|
||
int outDevID,
|
||
GRECT *Size,
|
||
GRECT *Clip,
|
||
long Width_mm1000,
|
||
long Height_mm1000,
|
||
long Scale);
|
||
OLGAColorTable *cbColorTable;
|
||
int cbClientID;
|
||
int cbServerID;
|
||
} OLGAObjectInfo;
|
||
|
||
|
||
Danach werden die n”tigen ID4-Server mit OLGA_ACTIVATE nachgestartet
|
||
und alle Objekte einzeln mit OLGA_EMBED eingebunden.
|
||
|
||
Zum Zeichnen eines Objekts geht ein Client folgendermažen vor:
|
||
Zun„chst wird OLGAObjectInfo.CBLock des zugeh”rigen Objekts um eins
|
||
erh”ht. Direkt danach testet der Client, ob in CBLock ein Wert gr”žer
|
||
Null eingetragen ist. Ist dies nicht der Fall, darf der Client die
|
||
Callback-Routinen nicht aufrufen! Ansonsten testet der Client, ob
|
||
CBDraw ungleich NULL ist - wenn ja, ruft er denn Callback auf. Zum
|
||
Schluž wird CBLock wieder um eins erniedrigt.
|
||
|
||
Clients sollten beim Empfang von OLGA_INPLACEUPDATE das in dieser
|
||
Message angegebene Objekt neu zeichnen lassen.
|
||
|
||
Beim L”schen eines Objekts (oder Schliežen eines Dokuments bzw.
|
||
Terminieren des Clients) muž f<>r jedes Objekt CBUnembed() aufgerufen
|
||
werden, sofern der Callback ungleich NULL ist. Die Absicherung mit
|
||
CBLock erfolgt wie oben beschrieben. Der Server weiž dann, das f<>r
|
||
dieses Objekt keine ID4-Verkn<6B>pfung mehr besteht (bzw. eine weniger).
|
||
|
||
Umgekehrt schickt ein Server dem Client OLGA_UNEMBED, wenn der Server
|
||
ein eingebettetes Objekt nicht mehr zur Verf<72>gung stellen (d.h.
|
||
zeichnen) kann. Der Client kann dann das Objekt ung<6E>ltig machen (z.B.
|
||
als weižes, rot durchgestrichenes Rechteck darstellen). In „hnlicher
|
||
Weise sollte ein Client auf OLGA_SERVERTERMINATED reagieren.
|
||
|
||
|
||
5.1.1 OLGA_GETOBJECTS
|
||
----------------------
|
||
|
||
Mit dieser Message kann ein ID4-Client den Manager abfragen, welche
|
||
Dateitypen per ID4-OLGA eingebettet werden k”nnen.
|
||
|
||
|
||
OLGA_GETOBJECTS
|
||
(Client -> Manager)
|
||
msg[0] $1242 (4674)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3] erstes (0) oder weiteres (1) Objekt
|
||
msg[4] 0
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
Als Antwort erh„lt der Client die Message OLGA_OBJECTS, die ihm neben
|
||
der Extension auch die Klartextbeschreibung des Dateityps f<>r die
|
||
Benutzerauswahl (siehe "ID4-Client") liefert.
|
||
|
||
|
||
OLGA_OBJECTS
|
||
(Manager -> Client)
|
||
msg[0] $1243 (4675)
|
||
msg[1] manID
|
||
msg[2] 0
|
||
msg[3] Anzahl der noch abrufbaren Objekte (0=dies ist das letzte Objekt)
|
||
msg[4]
|
||
+ Extension des Dateiformats, z.B. ".GEM"
|
||
msg[5]
|
||
msg[6]
|
||
+ Pointer auf Klartext-Objektbeschreibung
|
||
msg[7] (g<>ltig bis zum Terminieren des Managers)
|
||
|
||
|
||
Die Message OLGA_GETOBJECTS muž nun so lange an den Manager geschickt
|
||
werden, bis OLGA_OBJECTS in msg[3] eine Null zur<75>ckgibt.
|
||
|
||
|
||
5.1.2 OLGA_ACTIVATE
|
||
--------------------
|
||
|
||
Irgendwann vor dem Zeichnen, am besten auch vor dem Einbetten des
|
||
ersten Objekts, aužerhalb (!) einer wind_update()-Blockierung, schickt
|
||
der ID4-Client dem Manager folgende Message. Falls der Client vor dem
|
||
n„chsten wind_update() nicht mehr in seine Eventschleife geht, muž er
|
||
danach einen evnt_timer() (mind. 1000ms) machen.
|
||
|
||
|
||
OLGA_ACTIVATE
|
||
(Client->Manager)
|
||
msg[0] $124a
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ Pointer auf 4-Zeichen Extensions (z.B. ".GEM.CWG"),
|
||
msg[4] evtl. k<>rzen oder mit Nullbytes (!) auff<66>llen
|
||
msg[5] Anzahl der Extensions (>=1)
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
In dieser Message sollten alle verschiedenen Extensions aller
|
||
eingebetteten Objekte angegeben werden, damit der Manager die
|
||
passenden Server starten kann.
|
||
|
||
Der Manager verschickt daraufhin als Best„tigung folgende Message:
|
||
|
||
|
||
OLGA_ACK
|
||
(Manager -> Client)
|
||
[0] $1239 (4665)
|
||
[1] manID
|
||
[2] 0
|
||
[3] derselbe Wert wie in empfangener OLGA_ACTIVATE-Message
|
||
[4] derselbe Wert wie in empfangener OLGA_ACTIVATE-Message
|
||
[5] derselbe Wert wie in empfangener OLGA_ACTIVATE-Message
|
||
[6] 0
|
||
[7] OLGA_ACTIVATE
|
||
|
||
|
||
|
||
5.1.3 OLGA_EMBED
|
||
-----------------
|
||
|
||
Zum Einbetten eines Objekts legt ein Client eine OLGAObjectInfo-
|
||
Struktur im globalen Speicher an, setzt die Felder Filename (absoluter
|
||
Dateiname, nullterminiert; die Datei muž nicht existieren, der Server
|
||
sollte in diesem Fall ein neues Dokument anlegen), ClientGEMPB (ein
|
||
Pointer auf die Struktur, die Pointer zu den GEM-Arrays global[] etc.
|
||
enth„lt), ClientData (beliebige Client-Daten), CBLock (konstant auf
|
||
-16000), CBCount (Anzahl der folgenden 32bit-Langworte; derzeit 5),
|
||
cbClientID (auf die eigene AES-ID) sowie cbServerID (-1) und nullt
|
||
alle anderen Felder aus. Danach schickt der Client dem Manager
|
||
folgende Message:
|
||
|
||
|
||
OLGA_EMBED
|
||
(Client->Manager)
|
||
msg[0] $124b (4683)
|
||
msg[1] clientID
|
||
msg[2] 0
|
||
msg[3] Client-Flag
|
||
msg[4]
|
||
+ Pointer auf OLGAObjectInfo des Objekts
|
||
msg[5]
|
||
msg[6]
|
||
+ Extension
|
||
msg[7]
|
||
|
||
|
||
Das Client-Flag kann vom Client beliebig gesetzt werden und wird auch
|
||
sp„ter wieder an den Client zur<75>ckgegeben. Die Extension beschreibt
|
||
den Dateityp des Filenames aus OLGAObjectInfo (z.B. ".GEM"). Anhand
|
||
dieser Extension wird der ID4-Server angesprochen, der bereits laufen
|
||
muž (siehe OLGA_ACTIVATE).
|
||
|
||
Das eigentliche Einbetten darf der Client erst vornehmen, wenn er
|
||
folgende Message (direkt vom Server) erh„lt:
|
||
|
||
|
||
OLGA_EMBEDDED
|
||
(Server->Client)
|
||
msg[0] $124c (4684)
|
||
msg[1] serverID
|
||
msg[2] 0
|
||
msg[3] Client-Flag
|
||
msg[4]
|
||
+ Pointer auf OLGAObjectInfo
|
||
msg[5]
|
||
msg[6] Breite des Objekts in 1/100mm (vorzeichenlos), 0 bei Fehler
|
||
msg[7] H”he des Objekts in 1/100mm (vorzeichenlos), 0 bei Fehler
|
||
|
||
|
||
Client-Flag und der OLGAObjectInfo-Pointer sind unver„ndert zu
|
||
OLGA_EMBED. ServerData kann vom Server ver„ndert worden sein (wie der
|
||
Name schon sagt, geh”rt dieses Feld dem Server und darf vom Client
|
||
nicht ver„ndert werden), und in CBDraw sollte der Server einen Pointer
|
||
auf seine Zeichenroutine eingetragen haben.
|
||
|
||
Mit msg[6]/msg[7] teilt der Server dem Client die optimale Objektgr”že
|
||
mit. Der Client muž sich nicht an diese Gr”že halten, kennt durch das
|
||
Breite/H”he-Verh„ltnis aber auf jeden Fall die Proportionen des
|
||
Objekts.
|
||
|
||
Wichtig: Wenn msg[6]/msg[7] ausgenullt sind, ist ein Fehler
|
||
aufgetreten (OLGA_EMBEDDED kann in diesem Fall auch schon vom Manager
|
||
verschickt worden sein). Der Client darf das Objekt dann nicht
|
||
einbetten!
|
||
|
||
|
||
5.1.4 OLGA_ID4UPDATE
|
||
---------------------
|
||
|
||
Nachdem ein Client CBUnembed() aufgerufen hat, sollte er dem Server
|
||
auch folgende Nachricht schicken, damit dieser auch auf AES-Ebene
|
||
Aktualisierungen von z.B. Client-Listen durchf<68>hren kann (was
|
||
innerhalb des Callbacks schlecht bzw. nur umst„ndlich m”glich ist).
|
||
|
||
|
||
OLGA_ID4UPDATE
|
||
(Client->Server)
|
||
msg[0] $1257 (4695)
|
||
msg[1] clientID
|
||
msg[2] 0
|
||
msg[3] 0
|
||
msg[4] 0
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
|
||
5.1.5 cbColorTable
|
||
-------------------
|
||
|
||
Wenn der ID4-Client eine eigene Farbpalette zum Zeichnen seines
|
||
Dokuments verwendet, kann er diese Palette an den ID4-Server
|
||
<EFBFBD>bergeben, indem er in cbColorTable einen Zeiger auf folgende Struktur
|
||
eintr„gt:
|
||
|
||
|
||
typedef struct
|
||
{
|
||
int Count;
|
||
RGB Colors[];
|
||
} OLGAColorTable;
|
||
|
||
typedef struct
|
||
{
|
||
int Red;
|
||
int Green;
|
||
int Blue;
|
||
} RGB;
|
||
|
||
|
||
Zul„ssige Werte f<>r Count sind 16 und 256.
|
||
|
||
Wenn der Server die jeweils aktuelle (d.h. beim Aufruf von CBDraw oder
|
||
CBXDraw eingestellte) Farbpalette verwenden soll, nullt der Client
|
||
cbColorTable einfach aus (Standardwert).
|
||
|
||
Wichtig: Ein ID4-Server darf cbColorTable nur auswerten, wenn
|
||
CBCount>=4 ist!
|
||
|
||
|
||
5.1.6 cbClientID
|
||
-----------------
|
||
|
||
Wird vom Client vor dem Verschicken von OLGA_EMBED auf die eigene
|
||
AES-ID gesetzt. Dadurch muž der Server diesen Wert nicht umst„ndlich
|
||
ermitteln.
|
||
|
||
|
||
5.2 ID4-Server
|
||
===============
|
||
|
||
Wichtig: Wenn ID4 mit MemoryProtection funktionieren soll, muž das
|
||
GLOBAL-Flag im Programmheader des ID4-Servers gesetzt sein!
|
||
|
||
Wenn ein Client ein Objekt einbetten m”chte, erh„lt der Server vom
|
||
Manager eine OLGA_EMBED-Message, die er mit OLGA_EMBEDDED beantworten
|
||
muž.
|
||
|
||
Zum Zeichnen wird vom Client der CBDraw()-Callback aufgerufen. W„hrend
|
||
der Abarbeitung des Callsbacks d<>rfen vom Server i.d.R. keine AES-
|
||
Aufrufe gemacht werden (das schliežt wind_update() mit ein!). Aužerdem
|
||
darf der Server die Farbpalette nicht verstellen (er kann aber seine
|
||
Ausgabe an die Farbpalette des Clients anpassen, wenn diese in
|
||
cbColorTable <20>bergeben wird). Wenn im Server Ver„nderungen an einem
|
||
Objekt vorgenommen werden, kann dem Client zum sofortigen Update die
|
||
Message OLGA_INPLACEUPDATE geschickt werden.
|
||
|
||
Damit es beim Terminieren des Servers oder Schliežen eines Dokuments
|
||
keine undefinierten Zeiger gibt, muž der Server folgendermažen
|
||
vorgehen:
|
||
|
||
F<EFBFBD>r jedes Objekt testet der Server, ob OLGAObjectInfo.CBLock<=0 ist.
|
||
Ist dies der Fall, setzt der Server erst CBLock auf -16000, dann
|
||
CBDraw auf NULL.
|
||
|
||
Das ganze muž in einer evnt_timer()-Schleife solange wiederholt
|
||
werden, bis keine Objekte mehr belegt sind. Erst dann darf der Server
|
||
terminieren oder das Dokumentfenster schliežen.
|
||
|
||
Hat der Server alle entsprechenden CBDraw()-Pointer auf NULL gesetzt
|
||
muž er dem Client OLGA_UNEMBED schicken. Der Client kann beim Empfang
|
||
dieser Message das so "ung<6E>ltig" gewordene Objekt als z.B. weižes, rot
|
||
durchgestrichenes Rechteck neu zeichnen.
|
||
|
||
Damit der Server feststellen kann, ob ein eingebettetes Objekt noch
|
||
von einem Client benutzt wird, wird von den Clients zum Aufl”sen der
|
||
Verbindung der CBUnembed()-Callback aufgerufen. In „hnlicher Weise
|
||
sollte ein ID4-Server auf den Empfang von OLGA_CLIENTTERMINATED
|
||
reagieren.
|
||
|
||
Damit es beim evtl. Absturz eines Servers keine Probleme gibt, sollte
|
||
der Server etv_critic() <20>berschreiben und beim Durchlaufen durch diese
|
||
Routine CBDraw in allen Objekten auf NULL und CBLock auf -16000
|
||
setzen.
|
||
|
||
|
||
5.2.1 OLGA_EMBEDDED
|
||
--------------------
|
||
|
||
Wenn ein Client ein Objekt einbetten m”chte, erh„lt der Server vom
|
||
Manager folgende Message:
|
||
|
||
|
||
OLGA_EMBED
|
||
(Manager->Server)
|
||
msg[0] $124b
|
||
msg[1] manID
|
||
msg[2] 0
|
||
msg[3] Client-Flag
|
||
msg[4]
|
||
+ Pointer auf OLGAObjectInfo
|
||
msg[5]
|
||
msg[6] 0
|
||
msg[7] clientID
|
||
|
||
|
||
msg[3..5] d<>rfen vom Server nicht ver„ndert werden und m<>ssen bei
|
||
OLGA_EMBEDDED zur<75>ckgegeben werden. Das Feld ServerData in
|
||
OLGAObjectInfo kann vom Server beliebig verwendet werden.
|
||
|
||
Der Server kann nun die in OLGAObjectInfo angegebene Datei laden (wenn
|
||
diese Datei nicht existiert, sollte ein neues Dokument mit diesem
|
||
Namen ge”ffnet werden), setzt CBLock auf Null und tr„gt in CBDraw den
|
||
Pointer auf seine Zeichenroutine ein (nach M”glichkeit auch in
|
||
CBXDraw, falls CBCount>=3). In CBUnembed kann der Server eine Routine
|
||
eintragen, die vom Client beim Aufl”sen der ID4-Verkn<6B>pfung aufgerufen
|
||
wird. Falls CBCount>=5 ist, sollte der Server schliežlich auch noch
|
||
cbServerID auf seine AES-ID setzen.
|
||
|
||
Dann muž der Server dem Client direkt (!) folgende Antwort schicken
|
||
(die Client-ID bekommt der Server in msg[7] mitgeteilt):
|
||
|
||
|
||
OLGA_EMBEDDED
|
||
(Server->Client)
|
||
msg[0] $124c
|
||
msg[1] serverID
|
||
msg[2] 0
|
||
msg[3] Client-Flag
|
||
msg[4]
|
||
+ Pointer auf OLGAObjectInfo
|
||
msg[5]
|
||
msg[6] Breite des Objekts in 1/100mm (vorzeichenlos), 0 bei Fehler
|
||
msg[7] H”he des Objekts in 1/100mm (vorzeichenlos), 0 bei Fehler
|
||
|
||
|
||
Wenn der Server in msg[6..7] einen Fehler signalisiert, wird der
|
||
Client das Objekt nicht einbetten.
|
||
|
||
Wichtig: Falls der Server vom Manager nachgestartet wird, k”nnen
|
||
OLGA_EMBED-Messages eintreffen, noch bevor der Server seine OLGA-
|
||
Anmeldung beendet hat! Es ist dann Sache des Servers, ob er die
|
||
OLGA_EMBEDDED-Antworten sofort bearbeitet oder erst nach Abschluž
|
||
seiner Initialisierung.
|
||
|
||
|
||
5.2.2 OLGA_UNEMBED
|
||
-------------------
|
||
|
||
Damit es beim Terminieren des Servers oder Schliežen eines Dokuments
|
||
keine undefinierten Zeiger gibt, muž der Server folgendermažen
|
||
vorgehen:
|
||
|
||
F<EFBFBD>r jedes Objekt testet der Server, ob CBLock<=0 ist. Ist dies der
|
||
Fall, setzt der Server erst CBLock auf -16000, dann CBDraw auf NULL.
|
||
|
||
Das ganze muž in einer evnt_timer()-Schleife solange wiederholt
|
||
werden, bis keine Objekte mehr belegt sind. Erst dann darf der Server
|
||
terminieren oder das Dokumentfenster schliežen.
|
||
|
||
Hat der Server alle entsprechenden CBDraw's auf NULL gesetzt etc. muž
|
||
er dem Client direkt (!) f<>r jedes Objekt folgende Message schicken
|
||
(bzw. stattdessen eine einzige Message mit msg[3..4]=NULL beim
|
||
Terminieren):
|
||
|
||
|
||
OLGA_UNEMBED
|
||
(Server->Client)
|
||
msg[0] $124d
|
||
msg[1] serverID
|
||
msg[2] 0
|
||
msg[3] 0
|
||
msg[4]
|
||
+ Pointer auf OLGAObjectInfo oder NULL (s.o.)
|
||
msg[5]
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
Der Client kann beim Empfang dieser Message das so "ung<6E>ltig"
|
||
gewordene Objekt als z.B. weižes, rot durchgestrichenes Rechteck neu
|
||
zeichnen.
|
||
|
||
|
||
5.2.3 OLGA_INPLACEUPDATE
|
||
-------------------------
|
||
|
||
Wenn an einem Dokument Žnderungen vorgenommen werden, kann der Server
|
||
dem Client folgende Message schicken, damit letzterer eingebettete
|
||
Objekt sofort neu zeichnen l„žt (ohne daž vorher ein Speichern n”tig
|
||
ist). Der Server darf diese Message erst dann verschicken, nachdem er
|
||
OLGA_EMBEDDED an den Client geschickt hat!
|
||
|
||
|
||
OLGA_INPLACEUPDATE
|
||
(Server->Client)
|
||
msg[0] $1256
|
||
msg[1] serverID
|
||
msg[2] 0
|
||
msg[3] 0
|
||
msg[4]
|
||
+ Pointer auf OLGAObjectInfo
|
||
msg[5]
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
|
||
5.2.4 CBDraw
|
||
-------------
|
||
|
||
C-Notation:
|
||
|
||
void cdecl (*CBDraw) (ObjectInfo *objectinfo,
|
||
int outScreen,
|
||
int outHandle,
|
||
int outDevID,
|
||
GRECT *Size,
|
||
GRECT *Clip);
|
||
|
||
PurePascal-Notation:
|
||
(d1..d5 sind Dummy-Werte, hier sollte nil bzw. 0 <20>bergeben werden.)
|
||
|
||
CBDraw: procedure(d1,d2: pointer; d3,d4,d5: longint;
|
||
objectinfo: POLGAObjectInfo;
|
||
outScreen,
|
||
outHandle,
|
||
outDevID : integer;
|
||
Size,
|
||
Clip : GRECTPtr);
|
||
|
||
|
||
Wenn CBDraw() vom Client aufgerufen wird, sollte der Server
|
||
<EFBFBD>berpr<EFBFBD>fen, ob er die Datei OLGAObjectInfo.Filename (der
|
||
OLGAObjectInfo-Pointer wird bei CBDraw() <20>bergeben) schon geladen hat
|
||
- wenn nicht, sollte dies nun erfolgen. Da das Laden aber eigentlich
|
||
durch OLGA_EMBED sichergestellt sein sollte, kann in einem solchen
|
||
Fall alternativ auch ein Fehler angezeigt werden, beispielsweise durch
|
||
einfaches Durchstreichen des Objektbereichs mit zwei roten Linien
|
||
(evtl. kann der eigentliche Fehler auch noch im Klartext in den
|
||
Objektbereich ausgegeben werden).
|
||
|
||
Dann kann der Server die Grafik anhand der <20>bergebenen Werte (s.u.)
|
||
zeichnen. Der Server darf innerhalb dieses Zeichnens keinerlei
|
||
wind_update()-Aufrufe machen! Die Parameter von CBDraw() haben
|
||
folgende Bedeutung:
|
||
|
||
ù outScreen gibt an, ob die Ausgabe auf den Bildschirm erfolgt
|
||
(<>0) oder nicht (=0). Auch eine Preview ist eine
|
||
Bildschirmausgabe!
|
||
|
||
ù outHandle ist das Handle der ge”ffneten Workstation (Bildschirm,
|
||
Drucker etc.), auf die der Server direkt ausgeben kann. Wenn
|
||
outScreen<>0 ist, kann der Server alternativ auch auf seine
|
||
eigene Screen-Workstation ausgeben.
|
||
|
||
ù outDevID gibt die Ger„tenummer (aus ASSIGN.SYS) des Treibers an,
|
||
auf den ausgegeben wird. Wenn es sich um eine reine
|
||
Bildschirmausgabe handelt, steht in diesem Feld eine Null. Bei
|
||
einer Preview wird zwar auf den Bildschirm ausgegeben, outDevID
|
||
gibt dann z.B. aber den Treiber an, auf den sp„ter beim
|
||
eigentlichen Druck ausgegeben wird. Der Server kann in diesem
|
||
Fall versuchen, den Treiber zu ”ffnen, um die Bildschirmausgabe
|
||
besser an die sp„tere Druckausgabe anzupassen.
|
||
|
||
ù Size ist das Rechteck, in das die Grafik exakt eingepažt werden
|
||
muž, auch wenn es dabei zu Verzerrungen kommt. Clip ist das (vor
|
||
dem Aufruf gesetzte) Clipping-Rechteck.
|
||
|
||
Wichtig: Ein Server darf w„hrend CBDraw() keine AES-Aufrufe machen!
|
||
(Es sei denn, das AESPB-Zeigerfeld wurde mittels ClientGEMPB angepažt;
|
||
wind_update() bleibt f<>r ID4-Server aber trotzdem tabu.) Aužerdem darf
|
||
die Farbpalette im Callback nicht verstellt werden.
|
||
|
||
|
||
5.2.5 CBUnembed
|
||
----------------
|
||
|
||
C-Notation:
|
||
|
||
void cdecl (*CBUnembed) (ObjectInfo *objectinfo);
|
||
|
||
PurePascal-Notation:
|
||
(d1..d5 sind Dummy-Werte, hier sollte nil bzw. 0 <20>bergeben werden.)
|
||
|
||
CBUnembed: procedure(d1,d2: pointer; d3,d4,d5: longint;
|
||
objectinfo: POLGAObjectInfo);
|
||
|
||
|
||
Beim L”schen eines Objekts (oder Schliežen eines Dokuments bzw.
|
||
Terminieren) ruft ein Client f<>r jedes Objekt CBUnembed() auf. Der
|
||
ID4-Server kann auf diese Weise feststellen, daž f<>r das angegebene
|
||
Objekt keine ID4-Verkn<6B>pfung mehr besteht (bzw. eine weniger).
|
||
|
||
|
||
5.2.6 CBXDraw
|
||
--------------
|
||
|
||
C-Notation:
|
||
|
||
void cdecl (*CBXDraw) (ObjectInfo *objectinfo,
|
||
int outScreen,
|
||
int outHandle,
|
||
int outDevID,
|
||
GRECT *Size,
|
||
GRECT *Clip,
|
||
long Width_mm1000,
|
||
long Height_mm1000,
|
||
long Scale);
|
||
|
||
PurePascal-Notation:
|
||
(d1..d5 sind Dummy-Werte, hier sollte nil bzw. 0 <20>bergeben werden.)
|
||
|
||
CBXDraw: procedure(d1,d2: pointer; d3,d4,d5: longint;
|
||
objectinfo : POLGAObjectInfo;
|
||
outScreen,
|
||
outHandle,
|
||
outDevID : integer;
|
||
Size,
|
||
Clip : GRECTPtr;
|
||
Width_mm1000,
|
||
Height_mm1000,
|
||
Scale : longint);
|
||
|
||
|
||
CBXDraw entspricht im wesentlichen CBDraw, allerdings ist mit den
|
||
folgenden Parametern eine genauere Ausgabe m”glich:
|
||
|
||
ù Width_mm1000 enth„lt die in 1/1000 mm umgerechnete Breite des
|
||
Objekts aus Size.w
|
||
|
||
ù Height_mm1000 enth„lt die in 1/1000 mm umgerechnete H”he des
|
||
Objekts aus Size.h
|
||
|
||
ù Scale gibt an, welchen Skalierungsfaktor der Client bei der
|
||
Ausgabe verwendet (10000L=100%). Dies kann der Server z.B. zur
|
||
korrekten Fontgr”ženberechnung verwenden.
|
||
|
||
Ein ID4-Server darf seinen CBXDraw()-callback nur dann in ObjectInfo
|
||
eintragen, wenn CBCount>=3 ist. Ein ID4-Client darf CBXDraw()
|
||
nat<EFBFBD>rlich nur dann aufrufen, wenn dort kein NULL-Pointer eingetragen
|
||
ist.
|
||
|
||
Wichtig: Ein ID4-Server, der CBXDraw() unterst<73>tzt, muž auch CBDraw()
|
||
unterst<EFBFBD>tzen!
|
||
|
||
|
||
5.2.7 cbServerID
|
||
-----------------
|
||
|
||
Wird vom Client vor dem Verschicken von OLGA_EMBED auf -1 gesetzt. Der
|
||
Server tr„gt hier vor dem Verschicken von OLGA_EMBEDDED seine AES-ID
|
||
ein.
|
||
|
||
|
||
|
||
6 Notification
|
||
***************
|
||
|
||
Es kann Applikationen geben, denen das bisher vorgestellte
|
||
ObjectLinking nicht ausreicht, weil damit nur bekannte (oder vom
|
||
Anwender ausgew„hlte) Dateien <20>berwacht werden k”nnen. Mit der
|
||
Notification-Erweiterung kann sich eine Applikation nun vom Manager
|
||
<EFBFBD>ber alle Updates bzw. solche eines bestimmten Dateityps informieren
|
||
lassen.
|
||
|
||
Wie immer m<>ssen bei den folgenden Messages die Extensions immer grož
|
||
geschrieben werden. Sie sind (mit Punkt) exakt vier Zeichen lang, zur
|
||
Not muž man die Extension k<>rzen bzw. mit Nullbytes (!) auff<66>llen.
|
||
|
||
|
||
6.1 OLGA_REQUESTNOTIFICATION
|
||
=============================
|
||
|
||
Wenn eine Applikation vom Manager bei Žnderungen aller Dateien eines
|
||
bestimmten Typs benachrichtigt werden m”chte, schickt sie ihm folgende
|
||
Message. Werden vier Nullbytes <20>bergeben, wird die Applikation bei
|
||
jedem Update jeder Datei benachrichtig.
|
||
|
||
|
||
OLGA_REQUESTNOTIFICATION
|
||
(App -> Manager)
|
||
msg[0] $1250 (4688)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ Extension (z.B. ".TIF") oder NULL (="*.*")
|
||
msg[4]
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
|
||
6.2 OLGA_RELEASENOTIFICATION
|
||
=============================
|
||
|
||
Eine Applikation kann die Benachrichtigung bei bestimmten (vorher per
|
||
OLGA_REQUESTNOTIFICATION angeforderten) Dateitypen (bzw. bei allen,
|
||
falls vier Nullbytes <20>bergeben werden) mit folgender Message wieder
|
||
ausschalten.
|
||
|
||
|
||
OLGA_RELEASENOTIFICATION
|
||
(App -> Manager)
|
||
msg[0] $1251 (4689)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ Extension (z.B. ".TIF") oder NULL (="*.*")
|
||
msg[4]
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
|
||
6.3 OLGA_NOTIFY
|
||
================
|
||
|
||
|
||
OLGA_NOTIFY
|
||
(Manager -> App)
|
||
msg[0] $1252 (4690)
|
||
msg[1] manID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ Pointer auf Dateinamen mit absolutem Pfad
|
||
msg[4]
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
Mit dieser Message teilt der Manager der Applikation mit, daž eine
|
||
Datei ver„ndert wurde. Falls die Applikation einen Link auf diese
|
||
Datei gesetzt hat, erh„lt sie vorher auch noch eine OLGA_UPDATED-
|
||
Message!
|
||
|
||
Nach dem Empfang dieser Message muž die Applikation dem Manager
|
||
folgende Nachricht schicken:
|
||
|
||
|
||
OLGA_NOTIFIED
|
||
(App -> Manager)
|
||
msg[0] $1253 (4691)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3] gleicher Wert wie in empfangener OLGA_NOTIFY-Message
|
||
msg[4] gleicher Wert wie in empfangener OLGA_NOTIFY-Message
|
||
msg[5] gleicher Wert wie in empfangener OLGA_NOTIFY-Message
|
||
msg[6] gleicher Wert wie in empfangener OLGA_NOTIFY-Message
|
||
msg[7] gleicher Wert wie in empfangener OLGA_NOTIFY-Message
|
||
|
||
|
||
|
||
|
||
7 Idle-Test
|
||
************
|
||
|
||
Mit dem Idle-Test k”nnen Server bzw. Clients und der Manager
|
||
gegenseitig feststellen, ob alle vorhergehenden OLGA-Messages
|
||
abgearbeitet wurden. Dazu wird folgende Message verschickt:
|
||
|
||
|
||
OLGA_IDLE
|
||
(Manager -> App, App -> Manager)
|
||
msg[0] $1249 (4681)
|
||
msg[1] manID
|
||
msg[2] 0
|
||
msg[3] 1
|
||
msg[4] reserviert
|
||
msg[5] reserviert
|
||
msg[6] reserviert
|
||
msg[7] reserviert
|
||
|
||
|
||
Als Antwort bekommt man (bzw. muž vom Client/Server an den Manager
|
||
geschickt werden) folgende Message:
|
||
|
||
|
||
OLGA_IDLE
|
||
(App -> Manager, Manager -> App)
|
||
msg[0] $1249 (4681)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3] 0
|
||
msg[4] gleicher Wert wie in empfangener OLGA_IDLE-Message
|
||
msg[5] gleicher Wert wie in empfangener OLGA_IDLE-Message
|
||
msg[6] gleicher Wert wie in empfangener OLGA_IDLE-Message
|
||
msg[7] gleicher Wert wie in empfangener OLGA_IDLE-Message
|
||
|
||
|
||
Wenn eine Applikation den Idle-Test unterst<73>tzt, muž sie bei OLE_INIT
|
||
das passende Bit (OL_IDLE) setzen. Umgekehrt zeigt der OLGA-Manager
|
||
diese F„higkeit bei OLGA_INIT und OLE_NEW an.
|
||
|
||
|
||
|
||
8 Konfigurationsabfrage
|
||
************************
|
||
|
||
|
||
8.1 OLGA_GETSETTINGS
|
||
=====================
|
||
|
||
Wenn eine Applikation globale Werte des OLGA-Managers abfragen m”chte,
|
||
schickt sie ihm folgende Message:
|
||
|
||
|
||
OLGA_GETSETTINGS
|
||
(App -> Manager)
|
||
msg[0] $124e (4686)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3] 0
|
||
msg[4] 0
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
Als Antwort bekommt man folgende Message. Die Felder msg[4..7] darf
|
||
man nur auswerten, wenn in msg[3] eine 1 eingetragen ist!
|
||
|
||
|
||
OLGA_SETTINGS
|
||
(Manager -> App)
|
||
msg[0] $124f (4687)
|
||
msg[1] manID
|
||
msg[2] 0
|
||
msg[3] 1=OK, 0=Fehler
|
||
msg[4] reserviert (z.Z. 0)
|
||
msg[5] reserviert (z.Z. 0)
|
||
msg[6] reserviert (z.Z. 0)
|
||
msg[7] reserviert (z.Z. 0)
|
||
|
||
|
||
Derzeit werden noch keine Manager-internen Daten zur<75>ckgeliefert!
|
||
|
||
|
||
8.2 OLGA_GETSERVERPATH
|
||
=======================
|
||
|
||
Falls man doch einmal eine OLGA-Server-Applikation direkt ansprechen
|
||
m”chte (aus welchem Grund auch immer...), kann man mit dieser
|
||
Nachricht den Server f<>r eine gegebene Extension erfragen:
|
||
|
||
|
||
OLGA_GETSERVERPATH
|
||
(Client -> Manager)
|
||
msg[0] $125a (4698)
|
||
msg[1] clientID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ Extension (z.B. ".TIF")
|
||
msg[4]
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
Als Antwort erh„lt der Client die Nachricht OLGA_SERVERPATH. Falls zu
|
||
der gew<65>nschten Extension ein Server definiert ist, wird dessen
|
||
Pfad+Dateiname in msg[5/6] zur<75>ckgeliefert, ansonsten sind diese
|
||
beiden Eintr„ge ausgenullt. Wenn ein Server existiert, wird durch Bit
|
||
0 von msg[7] angezeigt, ob der Server gleichzeitig auch ID4-Server
|
||
ist.
|
||
|
||
|
||
OLGA_SERVERPATH
|
||
(Manager -> Client)
|
||
msg[0] $125b (4699)
|
||
msg[1] manID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ gleiche Extension wie in OLGA_GETSERVERPATH
|
||
msg[4]
|
||
msg[5]
|
||
+ Pointer auf den Dateinamen des Servers (incl. Pfad) oder NULL
|
||
msg[6]
|
||
msg[7] Bitmap aus OL_SRV_xxx-Konstanten
|
||
|
||
OL_SRV_ID4 = $0001 Server ist auch ID4-Server
|
||
|
||
|
||
Wenn in msg[5/6] ein Serverpfad geliefert wurde, muž der Client dem
|
||
Manager abschliežend noch folgende Message schicken, damit der Manager
|
||
den reservierten Speicher wieder freigeben kann.
|
||
|
||
|
||
OLGA_ACK
|
||
(Client -> Manager)
|
||
msg[0] $1239 (4665)
|
||
msg[1] clientID
|
||
msg[2] 0
|
||
msg[3] 0
|
||
msg[4] 0
|
||
msg[5]
|
||
+ exakt dieselben Werte aus OLGA_SERVERPATH
|
||
msg[6]
|
||
msg[7] OLGA_SERVERPATH
|
||
|
||
|
||
|
||
8.3 OLGA_GETEXTENSION
|
||
======================
|
||
|
||
OLGA bietet die M”glichkeit, aus einem gegebenen Dateinamen eine
|
||
korrekte Extension im Format ".???" (d.h. maximal drei Zeichen und in
|
||
Grožbuchstaben) zu extrahieren. Dazu schickt man dem Manager folgende
|
||
Nachricht:
|
||
|
||
|
||
OLGA_GETEXTENSION
|
||
(App -> Manager)
|
||
msg[0] $1258 (4696)
|
||
msg[1] apID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ Pointer auf den Dateinamen (optional incl. Pfadangabe)
|
||
msg[4]
|
||
msg[5] 0
|
||
msg[6] 0
|
||
msg[7] 0
|
||
|
||
|
||
Als Antwort erh„lt die Applikation folgende Nachricht:
|
||
|
||
|
||
OLGA_EXTENSION
|
||
(Manager -> App)
|
||
msg[0] $1259 (4697)
|
||
msg[1] manID
|
||
msg[2] 0
|
||
msg[3]
|
||
+ gleiche Werte wie in OLGA_GETEXTENSION
|
||
msg[4]
|
||
msg[5]
|
||
+ Extension (z.B. ".JPG"), evtl. mit Nullbytes aufgef<65>llt
|
||
msg[6]
|
||
msg[7] 1: a) Datei hat keine Extension (msg[5/6] sind dann
|
||
ausgenullt)
|
||
b) Extension ist zu lang, und es gibt keine bekannte
|
||
Kurzform; in msg[5/6] sind dann die ersten vier
|
||
Zeichen (incl. Punkt) der Extension eingetragen
|
||
0: Extension konnte korrekt gek<65>rzt werden (falls n”tig)
|
||
|
||
|
||
Derzeit werden die Extensions ".jpeg", ".mpeg", ".aiff", ".html",
|
||
".class" und ".tiff" korrekt gek<65>rzt.
|
||
|
||
|
||
|
||
9 Das OLGA-Info-Dateiformat
|
||
****************************
|
||
|
||
Info-Dateien erlauben den Austausch von spezielleren Informationen
|
||
zwischen Client und Server. Solche Dateien bestehen aus zwei Arten von
|
||
Datenstrukturen:
|
||
|
||
|
||
OLGAInfHeader = record
|
||
magic : longint; { 'OLGA' }
|
||
version, { z.Z. $0100 }
|
||
skip : word { Anzahl der folgenden Headerbytes, die
|
||
<20>berlesen werden m<>ssen; z.Z. 0 }
|
||
end;
|
||
|
||
OLGABlockHeader = record
|
||
id, { Block-ID }
|
||
length: longint { Anzahl der folgenden Datenbytes }
|
||
end;
|
||
|
||
|
||
Die Dateien sind folgendermažen aufgebaut:
|
||
|
||
|
||
InfHeader
|
||
BlockHeader 1
|
||
Daten 1
|
||
BlockHeader 2
|
||
Daten 2
|
||
...
|
||
BlockHeader n-1
|
||
Daten n-1
|
||
BlockHeader n (id=0)
|
||
|
||
|
||
Das Dateiende (und damit Block n) wird durch die ID 0 gekennzeichnet.
|
||
Folgende Block-IDs sind bereits definiert (es ist damit allerdings
|
||
nicht festgelegt, welche Bl”cke <20>berhaupt bzw. in welcher Reihenfolge
|
||
gespeichert werden):
|
||
|
||
$00000000 Dateiende (length sollte n.M. auch 0 sein)
|
||
|
||
'REM ' Kommentar; die einzelnen Zeilen sind 0-terminiert, das Ende
|
||
wird <20>ber die L„nge erkannt (damit man auch Leerzeilen
|
||
verschicken kann)
|
||
|
||
'AUTH' Autor; Codierung siehe 'REM ', allerdings sollte man sich auf
|
||
eine (0-terminierte) Zeile beschr„nken
|
||
|
||
'KEYW' Stichworte; Codierung s. 'REM '; innerhalb der Zeilen liegen
|
||
die Stichworte durch Komma getrennt vor
|
||
|
||
'DATE' Datum der letzten Žnderung als DOSTIME-Struktur
|
||
|
||
'ICON' Ein mit der Datei bzw. derem Inhalt verkn<6B>pftes Icon vom Typ
|
||
G_ICON (nicht G_CICON!). Die L„nge des Blocks berechnet sich aus
|
||
sizeof(ICONBLK) + 2*((ib_wicon+7) >> 3)*ib_hicon + (L„nge des
|
||
Icontextes ohne Nullbyte) + 1. Der Block ist folgendermažen
|
||
aufgebaut:
|
||
|
||
1. ein kompletter ICONBLK; die Felder ib_pmask, ib_pdata und
|
||
ib_ptext sollten vom Server auf NULL gesetzt werden und
|
||
m<>ssen vom Client ignoriert werden
|
||
|
||
2. Maskendaten
|
||
|
||
3. Bilddaten
|
||
|
||
4. ein Byte, das die L„nge des Icontextes angibt (kann auch
|
||
Null sein)
|
||
|
||
5. der Icontext (falls L„ngenbyte>0)
|
||
|
||
Unbekannte Bl”cke m<>ssen ignoriert (d.h. <20>berlesen) werden. D.h.
|
||
nat<EFBFBD>rlich auch, daž neue Block-IDs ohne Probleme angelegt werden
|
||
k”nnen - damit es nicht zu Kollisionen kommt, w„re es nett, wenn ich
|
||
(Adresse s. "Kontakt") verst„ndigt w<>rde, dann kann ich die Block-ID
|
||
in obige Liste aufnehmen.
|
||
|
||
|
||
|
||
10 Abschliežende Hinweise
|
||
**************************
|
||
|
||
Alle Zeichenketten sind nullterminiert. Wenn Mxalloc() vorhanden ist
|
||
und die MemoryProtection-Bits gesetzt werden k”nnen, m<>ssen die
|
||
Pointer auf global gesetzt werden! Ich weiž, daž die šbergabe von
|
||
Pointern in AES-Messages nicht das absolut Beste ist, es ist aber
|
||
sicher sehr einfach zu implementieren und funktioniert bei anderen
|
||
Protokollen in der Praxis auch ohne Probleme. Wer ganz sicher gehen
|
||
will, kann sp„ter mit OL_PIPES auf MTOS- D&D-Pipes umschalten (pro
|
||
Applikation, der Manager k<>mmert sich dann um die korrekte
|
||
Kommunikation).
|
||
|
||
Wichtig: Dieser Mechanismus ersetzt nicht die AV_PATH_UPDATE-,
|
||
SH_WDRAW- oder SC_CHANGED-Message!
|
||
|
||
In den Maus-Mailboxen KA (0721-358887) und FR (0761-507394) liegt das
|
||
Archiv OLGAxy.ZIP (xy gibt dabei die Versionsnummer an) mit einem
|
||
OLGA-Manager, dem Manager-Quelltext und dieser Dokumentation.
|
||
|
||
Die OLGA-Distribution ist (auch f<>r kommerzielle Software) Freeware!
|
||
|
||
Diese Dokumentation wurde mit UDO6 geschrieben.
|
||
|
||
Alle Angaben ohne Gew„hr, Žnderungen vorbehalten.
|
||
|
||
|
||
|
||
|
||
A FAQ
|
||
******
|
||
|
||
1. Wo bekomme ich die aktuellsten Informationen <20>ber OLGA?
|
||
|
||
Im WorldWideWeb. Adresse siehe "Kontakt".
|
||
|
||
2. Ich besitze kein Multitaskingbetriebssystem wie MultiTOS, MagiC
|
||
oder N.AES. Wie kann ich OLGA einsetzen?
|
||
|
||
Leider gar nicht. Ohne Multitasking macht OLGA aber auch keinen
|
||
Sinn, da nicht mehrere Hauptapplikationen gleichzeitig laufen
|
||
k”nnen.
|
||
|
||
3. Was muž ich tun, damit OLGA auf meinem 1MB Atari l„uft?
|
||
|
||
Eine Speichererweiterung kaufen.
|
||
|
||
4. Mein Programm kommt mit langen Dateinamen zurecht, die auch
|
||
Kleinschreibung enthalten d<>rfen. D<>rfen die Extensions in
|
||
OLGA.INF ebenfalls klein geschrieben werden?
|
||
|
||
Nein, alle Extensions (egal ob in OLGA.INF oder bei einer
|
||
Message) m<>ssen immer in Grožbuchstaben angegeben werden.
|
||
|
||
5. Wenn ich OLGA unter MiNT einsetze, bekomme ich eine
|
||
Speicherschutzverletzung.
|
||
|
||
Wie auch z.B. beim AV- und SE-Protokoll m<>ssen in Pointern
|
||
<20>bergebene Speicherbereiche global lesbar sein, also mit
|
||
Mxalloc() angefordert werden.
|
||
|
||
...wird bei Gelegenheit fortgesetzt.
|
||
|
||
|
||
|
||
B Glossar
|
||
**********
|
||
|
||
ActiveX
|
||
|
||
Microsofts Objekt-Modell mit Internet-Technologien. Hiež mal
|
||
OLE/COM.
|
||
|
||
Client
|
||
|
||
Dienstenehmer
|
||
|
||
ID4
|
||
|
||
ID4-OLGA, "InplaceDrawing for OLGA"
|
||
|
||
NULL
|
||
|
||
Null-Pointer
|
||
|
||
OLE
|
||
|
||
Microsofts "Object Linking & Embedding"
|
||
|
||
OLE/COM
|
||
|
||
Microsofts "Component Object Model" samt einiger darauf
|
||
aufbauender Technologien. Heižt jetzt ActiveX.
|
||
|
||
OLGA
|
||
|
||
"Object Linking for GEM Applications"
|
||
|
||
Server
|
||
|
||
Dienstegeber
|
||
|
||
...wird ausgebaut.
|
||
|
||
|
||
|
||
C Liste der OLGA-Applikationen
|
||
*******************************
|
||
|
||
Stand: 15. Januar 1998
|
||
|
||
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Programm | ab | Autor | Cl. | Srv. | ID4-Cl. | ID4-Srv. |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Alert Help | 1.2 | Matthias Jaap | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Alta Lista | 1.3 | Matthias Jaap | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| ArtWorx | 1.0 | Christian Witt | * | * | 1.4 | 1.14 |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Bellini | 01/97 | Ingo Dehne | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| CAB | 1.2 | A. Clauss | * | 2.5 | 2.0 | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| E.C.I. | 1.2 | Matthias Jaap | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Everest | 12/96 | Oliver Schmidt | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Focus 3D | 1.50 | Ralf Trinler | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| freeBase | 1.0 | Holger Weets | * | | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| GEMJing | 1.03 | G”tz Hoffart | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| GEM-Look | 12/95 | Rolf Kotzian | * | | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Gleichungen | 1.2 | Matthias Jaap | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| HP-Pinguin | 1.65 | Matthias Jaap | 2.0 | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| IdeaList | 3.71 | Chr. Bartholme | * | | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| JAnE | 1.50 | Harald Becker | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| JingleFALCON | 1.41 | Erik Hall | * | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Kandinsky | 2.0 | U. Rožgoderer | * | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Papillon | 2.3 | Dirk Sabiwalsky | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Papyrus | 5.5 | R.O.M. | * | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Phoenix | 5.0 | D.+J. Geiž | * | | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| PixArt | 3.32 | Mario Meižner | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| qed | 3.90 | Chr. Felsch | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Roman | 1.2 | Matthias Jaap | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| STELLA | 2.0 | Thomas K<>nneth | * | * | | 2.61 |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Tabi! | 1.5 | Matthias Jaap | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| Texel | 1.0 | Thomas Much | 1.5 | * | 1.5 | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
| XURL | 2.40 | Gary Priest | | * | | |
|
||
+--------------+-------+-----------------+-----+------+---------+----------+
|
||
|
||
Tabelle 2: Diese Programme unterst<73>tzen OLGA
|
||
|
||
|
||
|
||
+------------+------------+------------------+
|
||
| Library | ab Version | Autor |
|
||
+------------+------------+------------------+
|
||
| OLGA-C-Lib | | Alexander Barton |
|
||
+------------+------------+------------------+
|
||
| OLGA-C-Lib | | Thomas K<>nneth |
|
||
+------------+------------+------------------+
|
||
| ObjectGEM | 1.21-beta | Thomas Much |
|
||
+------------+------------+------------------+
|
||
|
||
Tabelle 3: Diese Libraries unterst<73>tzen OLGA
|
||
|
||
|
||
|
||
|
||
D Extensions
|
||
*************
|
||
|
||
|
||
+----------+----------+-------------------------+------------------+
|
||
| Kurzform | Langform | Beschreibung | Server/Client |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .AI | | Adobe Illustrator | ArtWorx |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .AIF | .aiff | | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .ASC | | ASCII-Text | Everest, qed |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .AU | | | GEMJing |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .CLA | .class | Java-Klasse | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .CSV | | | Texel |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .CVG | | Calamus-Vektorgrafik | ArtWorx |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .CWG | | ArtWorx-Dokument | ArtWorx |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .DIF | | | Texel |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .GEM | | GEM-Metafile | ArtWorx |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .GIF | | | Papillon |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .HDU | | Hard Disk Utility | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .HTM | .html | | CAB |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .IMG | | GEM-(X)IMG-Rastergrafik | STELLA |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .INC | | Pascal-Include | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .JPG | .jpeg | | Papillon, STELLA |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .MOV | | | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .MPG | .mpeg | | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .PAS | | Pascal-Source | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .PS | | PostScript-Dokument | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .SDB | | STELLA-Datenbank | STELLA |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .TAD | | Diagrammdatei | ArtWorx, Texel |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .TIF | .tiff | | Papillon, STELLA |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .TXL | | Texel-Rechenblatt | Texel |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .TXT | | ASCII-Text | Everest, qed |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .WAV | | | GEMJing |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .WRL | | VRML | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .XBM | | X-Bitmap-Grafik | |
|
||
+----------+----------+-------------------------+------------------+
|
||
| .XLS | | Excel-Rechenblatt | Texel |
|
||
+----------+----------+-------------------------+------------------+
|
||
|
||
|
||
|
||
E Dateien
|
||
**********
|
||
|
||
|
||
E.1 OLGA.H
|
||
===========
|
||
|
||
|
||
/* OLGA Rev 1.5 (98-06-08) */
|
||
/* Thomas_Much@ka2.maus.de */
|
||
/* http://www.uni-karlsruhe.de/~Thomas.Much/OLGA */
|
||
|
||
#ifndef OLGA_H
|
||
#define OLGA_H
|
||
|
||
|
||
#define OLE_INIT 0x4950
|
||
#define OLE_EXIT 0x4951
|
||
#define OLE_NEW 0x4952
|
||
|
||
#define OLGA_INIT 0x1236
|
||
#define OLGA_UPDATE 0x1238
|
||
#define OLGA_ACK 0x1239
|
||
#define OLGA_RENAME 0x123a
|
||
#define OLGA_OPENDOC 0x123b
|
||
#define OLGA_CLOSEDOC 0x123c
|
||
#define OLGA_LINK 0x123d
|
||
#define OLGA_UNLINK 0x123e
|
||
#define OLGA_UPDATED 0x123f
|
||
#define OLGA_RENAMELINK 0x1240
|
||
#define OLGA_LINKRENAMED 0x1241
|
||
#define OLGA_GETOBJECTS 0x1242
|
||
#define OLGA_OBJECTS 0x1243
|
||
#define OLGA_BREAKLINK 0x1244
|
||
#define OLGA_LINKBROKEN 0x1245
|
||
#define OLGA_START 0x1246
|
||
#define OLGA_GETINFO 0x1247
|
||
#define OLGA_INFO 0x1248
|
||
#define OLGA_IDLE 0x1249
|
||
#define OLGA_ACTIVATE 0x124a
|
||
#define OLGA_EMBED 0x124b
|
||
#define OLGA_EMBEDDED 0x124c
|
||
#define OLGA_UNEMBED 0x124d
|
||
#define OLGA_GETSETTINGS 0x124e
|
||
#define OLGA_SETTINGS 0x124f
|
||
#define OLGA_REQUESTNOTIFICATION 0x1250
|
||
#define OLGA_RELEASENOTIFICATION 0x1251
|
||
#define OLGA_NOTIFY 0x1252
|
||
#define OLGA_NOTIFIED 0x1253
|
||
#define OLGA_SERVERTERMINATED 0x1254
|
||
#define OLGA_CLIENTTERMINATED 0x1255
|
||
#define OLGA_INPLACEUPDATE 0x1256
|
||
#define OLGA_ID4UPDATE 0x1257
|
||
#define OLGA_GETEXTENSION 0x1258
|
||
#define OLGA_EXTENSION 0x1259
|
||
#define OLGA_GETSERVERPATH 0x125a
|
||
#define OLGA_SERVERPATH 0x125b
|
||
|
||
|
||
#define OL_SERVER 0x0001
|
||
#define OL_CLIENT 0x0002
|
||
#define OL_PEER (OL_SERVER | OL_CLIENT)
|
||
#define OL_CONF 0x0400
|
||
#define OL_IDLE 0x0800
|
||
#define OL_PIPES 0x1000
|
||
#define OL_START 0x2000
|
||
#define OL_MANAGER 0x4000
|
||
#define OL_OEP 0x0001
|
||
|
||
#define OLS_TYPE 1
|
||
#define OLS_EXTENSION 2
|
||
#define OLS_NAME 3
|
||
|
||
#define OL_SRV_ID4 0x0001
|
||
|
||
|
||
typedef struct
|
||
{
|
||
int x,y,w,h;
|
||
int x1,y1,x2,y2;
|
||
} OLGARect;
|
||
|
||
|
||
typedef struct
|
||
{
|
||
long magic;
|
||
unsigned int version;
|
||
unsigned int skip;
|
||
} OLGAInfHeader;
|
||
|
||
|
||
typedef struct
|
||
{
|
||
long id;
|
||
long length;
|
||
} OLGABlockHeader;
|
||
|
||
|
||
typedef struct
|
||
{
|
||
int Red;
|
||
int Green;
|
||
int Blue;
|
||
} OLGARGB;
|
||
|
||
|
||
typedef struct
|
||
{
|
||
int Count;
|
||
OLGARGB Colors[];
|
||
} OLGAColorTable;
|
||
|
||
|
||
typedef struct _OLGAObjectInfo
|
||
{
|
||
char *Filename;
|
||
AESPB *ClientGEMPB;
|
||
long ClientData;
|
||
long ServerData;
|
||
int CBLock;
|
||
int CBCount;
|
||
void cdecl (*CBDraw)
|
||
(struct _OLGAObjectInfo *objectinfo,
|
||
int outScreen,
|
||
int outHandle,
|
||
int outDevID,
|
||
OLGARect *Size,
|
||
OLGARect *Clip);
|
||
void cdecl (*CBUnembed)
|
||
(struct _OLGAObjectInfo *objectinfo);
|
||
void cdecl (*CBXDraw)
|
||
(struct _OLGAObjectInfo *objectinfo,
|
||
int outScreen,
|
||
int outHandle,
|
||
int outDevID,
|
||
OLGARect *Size,
|
||
OLGARect *Clip,
|
||
long Width_mm1000,
|
||
long Height_mm1000,
|
||
long Scale);
|
||
OLGAColorTable *cbColorTable;
|
||
int cbClientID;
|
||
int cbServerID;
|
||
} OLGAObjectInfo;
|
||
|
||
|
||
#endif
|
||
|
||
|
||
|
||
E.2 OLGA.INC
|
||
=============
|
||
|
||
|
||
{* OLGA Rev 1.5 (98-06-08) *
|
||
* Thomas_Much@ka2.maus.de *
|
||
* http://www.uni-karlsruhe.de/~Thomas.Much/OLGA *}
|
||
|
||
const
|
||
|
||
OLE_INIT = $4950;
|
||
OLE_EXIT = $4951;
|
||
OLE_NEW = $4952;
|
||
|
||
OLGA_INIT = $1236;
|
||
OLGA_UPDATE = $1238;
|
||
OLGA_ACK = $1239;
|
||
OLGA_RENAME = $123a;
|
||
OLGA_OPENDOC = $123b;
|
||
OLGA_CLOSEDOC = $123c;
|
||
OLGA_LINK = $123d;
|
||
OLGA_UNLINK = $123e;
|
||
OLGA_UPDATED = $123f;
|
||
OLGA_RENAMELINK = $1240;
|
||
OLGA_LINKRENAMED = $1241;
|
||
OLGA_GETOBJECTS = $1242;
|
||
OLGA_OBJECTS = $1243;
|
||
OLGA_BREAKLINK = $1244;
|
||
OLGA_LINKBROKEN = $1245;
|
||
OLGA_START = $1246;
|
||
OLGA_GETINFO = $1247;
|
||
OLGA_INFO = $1248;
|
||
OLGA_IDLE = $1249;
|
||
OLGA_ACTIVATE = $124a;
|
||
OLGA_EMBED = $124b;
|
||
OLGA_EMBEDDED = $124c;
|
||
OLGA_UNEMBED = $124d;
|
||
OLGA_GETSETTINGS = $124e;
|
||
OLGA_SETTINGS = $124f;
|
||
OLGA_REQUESTNOTIFICATION = $1250;
|
||
OLGA_RELEASENOTIFICATION = $1251;
|
||
OLGA_NOTIFY = $1252;
|
||
OLGA_NOTIFIED = $1253;
|
||
OLGA_SERVERTERMINATED = $1254;
|
||
OLGA_CLIENTTERMINATED = $1255;
|
||
OLGA_INPLACEUPDATE = $1256;
|
||
OLGA_ID4UPDATE = $1257;
|
||
OLGA_GETEXTENSION = $1258;
|
||
OLGA_EXTENSION = $1259;
|
||
OLGA_GETSERVERPATH = $125a;
|
||
OLGA_SERVERPATH = $125b;
|
||
|
||
OL_SERVER = $0001;
|
||
OL_CLIENT = $0002;
|
||
OL_PEER = OL_SERVER or OL_CLIENT;
|
||
OL_CONF = $0400;
|
||
OL_IDLE = $0800;
|
||
OL_PIPES = $1000;
|
||
OL_START = $2000;
|
||
OL_MANAGER = $4000;
|
||
OL_OEP = $0001;
|
||
|
||
OLS_TYPE = 1;
|
||
OLS_EXTENSION = 2;
|
||
OLS_NAME = 3;
|
||
|
||
OL_SRV_ID4 = $0001;
|
||
|
||
|
||
type
|
||
|
||
GRECTPtr = ^GRECT;
|
||
GRECT = record
|
||
X,Y,W,H,
|
||
X1,Y1,X2,Y2: integer
|
||
end;
|
||
|
||
POLGAInfHeader = ^TOLGAInfHeader;
|
||
TOLGAInfHeader = record
|
||
Magic : array [0..3] of char;
|
||
Version,
|
||
Skip : word
|
||
end;
|
||
|
||
POLGABlockHeader = ^TOLGABlockHeader;
|
||
TOLGABlockHeader = record
|
||
ID : array [0..3] of char;
|
||
Length: longint
|
||
end;
|
||
|
||
PRGB = ^TRGB;
|
||
TRGB = record
|
||
Red,
|
||
Green,
|
||
Blue : integer
|
||
end;
|
||
|
||
POLGAColorTable = ^TOLGAColorTable;
|
||
TOLGAColorTable = record
|
||
Count : integer;
|
||
Colors: array [0..255] of TRGB
|
||
end;
|
||
|
||
POLGAObjectInfo = ^TOLGAObjectInfo;
|
||
TOLGAObjectInfo = record
|
||
Filename : PChar;
|
||
ClientGEMPB : AESPBPtr;
|
||
ClientData,
|
||
ServerData : longint;
|
||
CBLock,
|
||
CBCount : integer;
|
||
CBDraw : procedure(d1,d2: pointer; d3,d4,d5: longint;
|
||
objectinfo: POLGAObjectInfo;
|
||
outScreen,
|
||
outHandle,
|
||
outDevID : integer;
|
||
Size,
|
||
Clip : GRECTPtr);
|
||
CBUnembed : procedure(d1,d2: pointer; d3,d4,d5: longint;
|
||
objectinfo: POLGAObjectInfo);
|
||
CBXDraw : procedure(d1,d2: pointer; d3,d4,d5: longint;
|
||
objectinfo: POLGAObjectInfo;
|
||
outScreen,
|
||
outHandle,
|
||
outDevID : integer;
|
||
Size,
|
||
Clip : GRECTPtr;
|
||
Width_mm1000,
|
||
Height_mm1000,
|
||
Scale : longint);
|
||
cbColorTable: POLGAColorTable;
|
||
cbClientID,
|
||
cbServerID : integer
|
||
end;
|
||
|
||
|
||
|
||
E.3 OLGA.INF
|
||
=============
|
||
|
||
|
||
;Dies ist die OLGA-Manager-Konfigurationsdatei.
|
||
;Sie muá im Wurzelverzeichnis des Bootlaufwerks,
|
||
;in $HOME/defaults oder in $HOME stehen.
|
||
|
||
;ACHTUNG: Der Minimalmanager reagiert allergisch auf einen
|
||
;falschen Aufbau dieser Datei! Kommentare beginnen mit
|
||
;einem Semikolon am Zeilenanfang, Leerzeilen d<>rfen nur
|
||
;aus CR/LF bestehen. Alle Eintr„ge m<>ssen am Zeilenanfang
|
||
;stehen, zus„tzliche Leerzeichen o.„. sind _nicht_ erlaubt.
|
||
;Programmnamen sind immer absolut, d.h. mit Pfad und Lauf-
|
||
;werk.
|
||
|
||
[Extensions]
|
||
;Wildcards sind nicht erlaubt!
|
||
;Extensions sind (mit Punkt) maximal vier Zeichen lang
|
||
.TAD=$ARTWORX
|
||
.CWG=$ARTWORX
|
||
.GEM=$ARTWORX
|
||
.CVG=$ARTWORX
|
||
.AI=$ARTWORX
|
||
.SDB=$STELLA
|
||
.TXL=$TEXEL
|
||
.DIF=$TEXEL
|
||
.CSV=$TEXEL
|
||
.XLS=$TEXEL
|
||
.HTM=$CAB
|
||
.TXT=$QED
|
||
.ASC=$QED
|
||
.IMG=$PAPILLON
|
||
.TIF=$PAPILLON
|
||
.JPG=$PAPILLON
|
||
.GIF=$PAPILLON
|
||
|
||
[Objects]
|
||
;zu den folgenden Extensions existieren ID4-Server
|
||
;die Extensions m<>ssen auch im vorigen Abschnitt definiert sein!
|
||
.CWG=ArtWorx-Dokument
|
||
.CVG=Calamus-Dokument
|
||
.GEM=GEM Metafile
|
||
.AI=Adobe Illustrator-Dokument
|
||
.TAD=Texel-Diagramm
|
||
|
||
[Types]
|
||
;XAcc-Typen, siehe OLGAPROT.TXT; sie sind _exakt_ zwei
|
||
;Zeichen lang (Groá-/Kleinschreibung beachten!)
|
||
SS=$TEXEL
|
||
VG=$ARTWORX
|
||
RG=$PAPILLON
|
||
GG=$STELLA
|
||
ED=$QED
|
||
|
||
[Applications]
|
||
;hier werden Aliase festgelegt, die als Abk<62>rzungen (mit einem
|
||
;f<>hrenden $, s.o.) verwendet werden /k”nnen/ (nicht m<>ssen).
|
||
;Verschachtelungen sind erlaubt, aber man muá selbst darauf
|
||
;achten, keine Endlosschleifen zu erzeugen.
|
||
;Groá-/Kleinschreibung wird beachtet!
|
||
TEXEL=C:\Programm\PP\PRGS\texel.app
|
||
STELLA=C:\Programm\STELLA\STELLA.APP
|
||
ARTWORX=C:\Programm\ArtWorx\ARTWORX.PRG
|
||
IDEALIST=C:\Tools\IdeaList\IDEALIST.PRG
|
||
CAB=C:\Programm\WWW\CAB\CAB.APP
|
||
QED=C:\Diverses\qed\qed.app
|
||
PAPILLON=C:\Programm\PAPILLON\PAPILLON.PRG
|
||
|
||
[Manager]
|
||
;wenn die letzte Zeile dieses Abschnitts nicht auskommentiert ist,
|
||
;testet der Manager *nicht* auf abgest<73>rzte Applikationen; aus
|
||
;Sicherheitsgr<67>nden sollte diese Option daher immer an sein, die
|
||
;folgende Zeile also auskommentiert bleiben!
|
||
;NoCrashChecking
|
||
|
||
|
||
|
||
|
||
F History
|
||
**********
|
||
|
||
Rev 1.5 (08.06.98)
|
||
|
||
ù der Manager ist nun komplett in PureC geschrieben, braucht
|
||
deutlich weniger RAM und sollte zudem noch stabiler geworden
|
||
sein
|
||
|
||
ù der Manager testet, ob eine angemeldete OLGA-Applikation
|
||
abgest<73>rzt ist, und entfernt diese gegebenenfalls aus seiner
|
||
Liste
|
||
|
||
ù neuer Abschnitt "[Manager]" in der Datei olga.inf;
|
||
Konfigurationsschalter "NoCrashChecking" innerhalb dieses
|
||
Abschnitts
|
||
|
||
ù OL_CONF
|
||
|
||
Rev 1.3 (30.11.97)
|
||
|
||
ù OLGA_CLIENTTERMINATED erweitert (msg[7])
|
||
|
||
ù OLGA_GETSERVERPATH, OLGA_SERVERPATH
|
||
|
||
ù OLGA_GETEXTENSION, OLGA_EXTENSION
|
||
|
||
ù OLGA_ID4UPDATE
|
||
|
||
ù CBXDraw, cbColorTable, cbClientID, cbServerID
|
||
|
||
ù dokumentiert, daž Dateien bei OLGA_EMBED nicht existieren
|
||
m<>ssen
|
||
|
||
ù Manager: Erkennung von MultiTOS, N.AES und MagiC verbessert
|
||
|
||
ù Manager: fehlertoleranter beim Einlesen von OLGA.INF
|
||
|
||
Rev 1.2 (20.11.96)
|
||
|
||
ù OLGA_CLIENTTERMINATED, OLGA_SERVERTERMINATED
|
||
|
||
ù Idle-Test (OLGA_IDLE)
|
||
|
||
ù Notification-Erweiterung (OLGA_REQUESTNOTIFICATION,
|
||
OLGA_RELEASENOTIFICATION, OLGA_NOTIFY, OLGA_NOTIFIED)
|
||
|
||
ù InplaceDrawing: "ID4-OLGA" (OLGA_GETOBJECTS, OLGA_OBJECTS,
|
||
OLGA_ACTIVATE, OLGA_EMBED, OLGA_EMBEDDED, OLGA_UNEMBED,
|
||
OLGA_INPLACEUPDATE, OLGAObjectInfo, CBDraw, CBUnembed)
|
||
|
||
ù Konfigurationsabfrage (OLGA_GETSETTINGS, OLGA_SETTINGS)
|
||
|
||
Rev 1.1 (24.07.96)
|
||
|
||
ù neuer Block 'ICON' bei OLGA-Info-Dateien
|
||
|
||
ù nach OLGA_OPENDOC wird OLGA_ACK verschickt
|
||
|
||
ù OL_PEER
|
||
|
||
Rev 1.0 (24.01.96)
|
||
|
||
ù msg[6] des Kommandozeilen-OLGA_ACK nach OLGA_START angepažt
|
||
|
||
ù ab sofort wird Multitasking vorausgesetzt, die Messages
|
||
OLGA_BLOCK und OLGA_UNBLOCK entfallen damit
|
||
|
||
Rev 0.9 (10.11.95)
|
||
|
||
ù die OLE-Messages haben neue Nummern bekommen
|
||
|
||
Rev 0.8 (05.11.95)
|
||
|
||
ù Konzept f<>r Info-Dateien, Dateiformat s.o.
|
||
|
||
ù daf<61>r Erweiterung von OLGA_UPDATE und OLGA_UPDATED
|
||
|
||
ù neue Messages OLGA_GETINFO und OLGA_INFO
|
||
|
||
Rev 0.7 (09.04.95)
|
||
|
||
ù OLE-Initialisierung (OEP/OLGA)
|
||
|
||
ù die OLGA_INIT-Message von der Applikation an den Manager
|
||
wird durch OLE_INIT ersetzt
|
||
|
||
ù der Manager <20>bergibt in OLGA_INIT nicht mehr seinen Namen
|
||
|
||
ù OLGA_EXIT heižt nun OLE_EXIT, OLGA_NEW heižt OLE_NEW
|
||
|
||
ù bei OLGA_OPENDOC wird kein Dokumentname mehr <20>bergeben
|
||
|
||
Rev 0.6 (nicht ”ffentlich)
|
||
|
||
ù Nachstarten des Managers (siehe OLGA_INIT) mit shel_write
|
||
|
||
ù automatisches Terminieren
|
||
|
||
ù OLGA_EXIT beim Manager-Shutdown
|
||
|
||
ù OLGA_NEW
|
||
|
||
Rev 0.5 (01.03.95)
|
||
|
||
ù OL_START, OLGA_START
|
||
|
||
ù OL_PIPES
|
||
|
||
ù beim Programmende d<>rfen OLGA_CLOSEDOC, OLGA_UNLINK nicht
|
||
verwendet werden, OLGA_EXIT k<>mmert sich um alles
|
||
|
||
ù OLGA_ACK wird nach OLGA_CLOSEDOC verschickt
|
||
|
||
ù Applikationen sollten bei OLGA_INIT einen XAcc-Programmtyp
|
||
angeben
|
||
|
||
Rev 0.4 (07.01.95)
|
||
|
||
ù OLGA_BREAKLINK, OLGA_LINKBROKEN sind neu
|
||
|
||
Rev 0.3 (04.01.95)
|
||
|
||
ù OLGA_RENAMED heižt nun OLGA_RENAMELINK
|
||
|
||
ù OLGA_LINKRENAMED ist dazugekommen, dadurch haben sich die
|
||
Nummern von OLGA_BLOCK/OLGA_UNBLOCK verschoben
|
||
|
||
Rev 0.2
|
||
|
||
ù komplette šberarbeitung gegen<65>ber dem GOLEM-Vorschlag
|
||
|
||
Davor...
|
||
|
||
...stand ein Erlebnis auf der ProTOS '94 in Hennef. Ulrich
|
||
Rožgoderer, Thomas K<>nneth und ich zeigten auf dem Stand von
|
||
Delta Labs unsere Shareware, die zu dieser Zeit in der
|
||
Whiteline-Serie verkauft wurde. Uli und Tommi hatten zwischen
|
||
Kandinsky und STELLA einen Update- Mechanismus eingerichtet, der
|
||
dasselbe Ergebnis wie OLGA_UPDATE erzielte. Dieser Mechanismus
|
||
hatte allerdings den Nachteil, daž der Server irgendwie bekannt
|
||
sein mužte und nicht automatisch von einem Manager gesucht wurde.
|
||
|
||
Da ich damals gerade einen ObjectLinking-Mechanismus f<>r
|
||
ObjectGEM plante (GOLEM), um ihn als Grundlage f<>r Texel (das
|
||
damals in einer ganz fr<66>hen Alpha-Version vorlag) verwenden zu
|
||
k”nnen, bot es sich an, beide Ideen zu kombinieren. So entstand
|
||
OLGA.
|
||
|
||
|
||
|
||
G K<>nftige Weiterentwicklungen
|
||
*******************************
|
||
|
||
Zwei grože Aufgaben sind 1998 zu l”sen. Zum einen sollte das
|
||
InplaceDrawing zum InplaceEditing ausgebaut werden, d.h. der Benutzer
|
||
sollte fremde Dokumente in einer Applikation nicht nur angezeigt
|
||
bekommen, sondern sie auch dort direkt bearbeiten k”nnen - mit den
|
||
Routinen des ID4-Servers.
|
||
|
||
Zum anderen ist es <20>berlegenswert, GEM ein Objekt-Modell zur Verf<72>gung
|
||
zu stellen, um solche Aktionen wie ID4 und InplaceActivation zu
|
||
verallgemeinern. Denkbar w„re so ein "GEM Component Object Model"
|
||
(GCOM) beispielsweise auf der Grundlage von OLE/COM bzw. ActiveX.
|
||
Weitere Informationen dazu liegen im Web auf http://www.activex.org.
|
||
|
||
Im Zusammenhang mit GEMScript d<>rfte auch die Entwicklung von GDBC
|
||
("GEM Database Connectivity") wichtig und n<>tzlich sein.
|
||
|
||
F<EFBFBD>r Programmierer gibt es eine OLGA-Mailingliste, um diese
|
||
Erweiterungen diskutieren (und allgemeine Fragen zu OLGA beantworten)
|
||
zu k”nnen. Wer daran teilnehmen m”chte, meldet sich bitte bei mir
|
||
(siehe "Kontakt").
|
||
|
||
|
||
|
||
H Kontakt
|
||
**********
|
||
|
||
|
||
Thomas Much, Gerwigstraáe 46, D-76131 Karlsruhe, Germany
|
||
|
||
Fax: +49 / (0)721 / 62 28 21
|
||
|
||
EMail: Thomas Much @ KA2 (MausNet)
|
||
Thomas_Much@ka2.maus.de
|
||
Thomas.Much@stud.uni-karlsruhe.de (Internet)
|
||
|
||
WWW: http://www.uni-karlsruhe.de/~Thomas.Much/OLGA
|
||
http://thmuch.home.pages.de
|
||
|
||
Newsgroup: OLGA @ ASH (+49 / (0)6221 / 30 36 71)
|
||
|
||
|
||
|
||
I Rechtliches
|
||
**************
|
||
|
||
Der OLGA-Manager ist mit allen zugeh”rigen Dateien Freeware - dies
|
||
wird auch in Zukunft so bleiben. Er darf auch einzeln und auch mit
|
||
kommerziellen Programmen ohne Zahlung von Lizenzgeb<65>hren weitergegeben
|
||
werden! Gegen einen Hinweis in der Distribution auf den Autor und die
|
||
OLGA-Homepage bzw. eine Benachrichtigung an mich (s. "Kontakt") im
|
||
Falle einer solchen Nutzung h„tte ich allerdings nichts einzuwenden.
|
||
|
||
Da OLGA ein Standard sein soll, w„re es sch”n, wenn niemand das
|
||
Protokoll eigenm„chtig ver„ndert, sondern alle Erweiterungsw<73>nsche mit
|
||
mir abspricht.
|
||
|
||
Die Haftung f<>r Sch„den, die sich mittelbar oder unmittelbar aus der
|
||
Nutzung dieser Dokumentation und des OLGA-Paketes ergeben, ist
|
||
ausgeschlossen.
|
||
|
||
Alle Angaben ohne Gew„hr, Žnderungen vorbehalten.
|
||
|
||
|
||
|
||
J Dank
|
||
*******
|
||
|
||
Ein besonderer Dank geht an
|
||
|
||
ù Ulrich "Kandinsky" Rožgoderer f<>r die Unterst<73>tzung bei der
|
||
Definition von OLGA
|
||
|
||
ù Thomas "STELLA" K<>nneth f<>r die Unterst<73>tzung bei der Definition
|
||
von OLGA, f<>r seinen "OLGAnisator", seine OLGA-C-Library sowie
|
||
f<>r sein Dr„ngeln bei der Notification-Erweiterung
|
||
|
||
ù Wilfried Behne, Manfred Lippert, Daniel H”pfl und Didier
|
||
Mequignon f<>r die Mithilfe beim Debuggen des Managers
|
||
|
||
ù Christian "ArtWorx" Witt f<>r die Mitarbeit bei InplaceDrawing
|
||
(ID4-OLGA)
|
||
|
||
ù Alexander Lorenz f<>r die Zusammenarbeit beim OLE-Protokoll
|
||
|
||
ù Mickael Cousin f<>r die franz”sische šbersetzung der OLGA-Homepage
|
||
|
||
ù Mille Babic f<>r die schwedische OLGA-Seite im Web
|
||
|
||
ù Joe Connor (InterActive) und TransAction f<>r die englische
|
||
šbersetzung des OLGA-Protokolls
|
||
|
||
ù G”tz Hoffart f<>r die OLGA-Mailingliste
|
||
|
||
ù Dirk "U." Hagedorn f<>r UDO6.
|
||
|
||
|
||
|
||
|