Protokolle

BubbleGEM

Document-History-Protokoll

15.3 Drag&Drop-Protokoll

Das Drag&Drop-Protokoll wurde von Atari für das Multi-TOS entwickelt. Es handelt sich dabei um ein sehr flexibles Protokoll, welches nicht selbst Bestandteil des Betriebssystems ist, und daher auch unter anderen Betriebssystemvarianten eingesetzt werden könnte, wenn diese Multitasking und Pipes unterstützen.

AES-Nachrichten werden in diesem Protokoll nur dazu benutzt, um die Kommunikationspartner zusammenzubringen; die gesamte restliche Datenübertragung erfolgt über eine Pipe, auf die man mit den gewohnten Dateifunktionen des GEMDOS zugreifen kann.

Um eine Drag&Drop-Kommunikation zu beginnen, legt man in dem Verzeichnis U:\PIPE eine Datei mit dem Namen 'DRAGDROP.xx' an, wobei ein x jeweils für die Buchstaben A bis Z stehen kann. Dadurch könnten theoretisch bis zu 676 gleichzeitige Drag&Drop-Vorgänge stattfinden, was sicherlich ausreichen sollte. Zum Anlegen der Pipe sollte man die Funktion Fcreate verwenden, da diese eine ordentliche Fehlermeldung zurückliefert wenn eine gleichnamige Pipe bereits existieren sollte. Darüberhinaus sollte beim Anlegen der Pipe das Hidden-Bit (Bit-1) gesetzt werden: dadurch enthält die lesende Seite ein End-of-File (EOF), wenn die andere Seite der Pipe geschlossen wird.

Anschließend wird die Nachricht AP_DRAGDROP an den Empfänger geschickt. Da keine Rückmeldung auf diese Mitteilung vorgesehen ist, muß sich der Sender der Funktion Fselect bedienen, um festzustellen, ob jemand auf der Gegenseite die Pipe zum Lesen geöffent hat und empfangsbereit ist. Atari empfiehlt in diesem Zusammenhang ein Time-Out von drei bis vier Sekunden.

Achtung: Der Sender ist leider nicht in der Lage im voraus festzustellen, ob die Ziel-Applikation das Drag&Drop-Protokoll überhaupt unterstützt. Daher ist es möglich, daß der Anwender erst nach Ablauf der Time-Out-Zeit eine entsprechende Mitteilung erhält. Aus diesem Grund sollten alle Applikationen, die das Protokoll nicht unterstützen, eine negative Bestätigung zurückschicken, damit die lästige Wartezeit entfällt. Falls der Empfänger hingegen zur Aufnahme der Daten bereit ist, sollte er die Kennung DD_OK (mit dem Wert 0) zurückschicken.

Als nächstes müssen sich beide Parteien über die Art der zu verschickenden Daten einigen; Kernpunkt des Drag&Drop-Protokolls sind nämlich unterschiedliche Arten von Datentypen, die als vier Zeichen lange Buchstabenfolgen dargestellt werden. Dazu schickt der Empfänger eine nach Präferenz sortierte Liste von acht für ihn brauchbaren Datentypen an den Sender. Eine Textverarbeitung könnte auf diese Art z.B. mitteilen, daß sie Dateien im Rich-Text-Format (RTF) und ASCII-Format unterstützt, und dabei ersteren den Vorzug gibt. Wichtig: Wenn weniger als acht Datentypen verstanden werden, muss der Rest der Liste mit Null-Bytes aufgefüllt werden, so daß immer genau 32 Bytes übermittelt werden.

Der Sender kann dann anhand der vom Empfänger übermittelten Liste entscheiden, welches Datenformat verwendet werden soll. Dabei dient die übermittelte Liste jedoch nur als Richtlinie; der Sender kann also durchaus eine andere Reihenfolge benutzen oder auch noch andere Formate anbieten.

Die Übermittlung der eigentlichen Daten erfolgt dann in den folgenden Schritten:

• Zuerst wird ein Header übermittelt, der alle Informationen über die Daten - ihr Format und ihre Länge - enthält. Der Empfänger kann darauf dann entsprechend reagieren. Der Header ist wie folgt aufgebaut:
   
  
  

  Position	Länge	Bedeutung
  0	2 Bytes	Länge des Headers
  2	4 Bytes	Datentyp (z.B. ARGS)
  6	4 Bytes	Länge der zu übertragenden Daten
  10	variabel(n)	Name der Daten (null-terminiert)
  10+n	variabel	Dateiname (null-terminiert)

  
  Da die Länge des Headers mit angegeben werden muss, ist dieser für zukünftige Zwecke leicht erweiterbar.
   

• Nachdem er den Header eingelesen hat, kann der Empfänger auf diesen reagieren. So kann er beispielsweise dem Sender mitteilen, daß er mit dem vorgeschlagenen Datenformat einverstanden ist, oder nicht. Dies geschieht durch Senden von verschiedenen Status-Bytes.
   

• Sobald der Empfänger mit DD_OK geantwortet hat, wird mit der Übertragung der Daten begonnen; dabei werden genau so viele Bytes geschrieben, wie im Header angegeben wurden, und anschließend die Pipe geschlossen.
   

Wichtiger Hinweis: Normalerweise wird ein Prozess vom Kernel terminiert, wenn er in eine Pipe schreibt, die von niemandem zum Lesen geöffnet ist. Dies läßt sich verhindern, indem man das Signal SIGPIPE ignoriert. Ferner sollte keiner der beiden Partner ein wind_update benutzen, da es sonst u.U. zu einem Deadlock kommen könnte, wenn eine der beiden Seiten versucht eine Bildschirmausgabe (z.B. eine Alertbox) zu machen.

Tip: Ein Beispiel-Quelltext zum Drag&Drop-Protokoll befindet sich z.B. in der Zeitschrift ST-Computer (Ausgabe 12/1993).

Querverweis:
AV-Protokoll GEM Style-Guidelines Test auf Pipes OLGA-Protokoll

15.3.1 D&D-Listing_1

/* Das folgende Programmfragment signalisiert dem Sender
   des Drag&Drop-Protokolls, daß das eigene Programm
   dieses Protokoll nicht versteht. */

#define AP_DRAGDROP   63
#define DD_NAK         1

/* wir befinden uns nun in der Event-Schleife;
   msg ist der Message-Puffer. */

case AP_DRAGDROP:
{
    static BYTE pipename[] = "U:\\PIPE\\DRAGDROP.AA";
    LONG fd;

    pipename[18] = msg[7] & 0x00ff;
    pipename[17] = (msg[7] & 0xff00) >> 8;

    fd = Fopen (pipename, 2);
    if (fd >= 0)
    {
        BYTE c = DD_NAK;

        Fwrite ((WORD) fd, 1, &c);
        Fclose ((WORD) fd);
    }
}
break;

15.3.2 Drag&Drop, Datentypen für

Datentypen werden innerhalb des Drag&Drop-Protokolls durch eine vier Zeichen lange Buchstabenfolge repräsentiert. Die folgende Liste enthält die zur Zeit definierten Datentypen:

ARGS

steht für eine Kommandozeile, also i.a. einen oder mehrere Datei- oder Verzeichnisnamen, die voneinander durch Leerzeichen getrennt sind. Für Dateinamen die selbst Leerzeichen enthalten, ist eine Sonderbehandlung notwendig. Dazu wird der Dateiname in einfache Anführungsstriche eingeschlossen, und jeder Anführungsstrich, der im Namen auftritt, durch einen doppelten ersetzt.
 
Beispiel:
Aus Eric's file würde 'Eric''s file'.
 

PATH

ist reserviert, um Informationen über das vom Benutzer gewählte Zielobjekt zu erfragen. Die Übertragung läuft in diesem Fall in die umgekehrte Richtung; d.h. der Sender liest genau so viele Bytes wie angegeben. Hierzu muß der Empfänger nach dem Senden von DD_OK direkt die Daten übermitteln. Diese sollten den vollständigen Pfadnamen bzw. Dateinamen des Zielfensters (mit '\' terminiert) enthalten.
 

.XXX

steht für eine Extension (eines Dateinamens). Beispiele:
 

.IMG	=	Grafikdaten im XIMG-Format
.GEM	=	Grafikdaten im Metafile-Format
.TXT	=	Texte im ASCII-Format
.RTF	=	Texte im Rich-Text-Format

Querverweis: Drag&Drop-Protokoll

15.3.3 Drag&Drop, Status Bytes für

Die folgende Liste enthält alle Status-Bytes, die innerhalb einer Drag&Drop-Kommunikation anfallen können:

#define DD_OK         0    /* Ok, - weitermachen                */
#define DD_NAK        1    /* Drag&Drop abbrechen               */
#define DD_EXT        2    /* Datenformat wird nicht akzeptiert */
#define DD_LEN        3    /* Wunsch nach weniger Daten         */
#define DD_TRASH      4    /* Ziel ist ein Papierkorb-Icon      */
#define DD_PRINTER    5    /* Ziel ist ein Drucker-Icon         */
#define DD_CLIPBOARD  6    /* Ziel ist ein Klemmbrett-Icon      */

Alle anderen Werte sind für zukünftige Erweiterungen reserviert.

Hinweis: Das Status-Byte DD_EXT wird verschickt, wenn der Empfänger das angebotene Datenformat nicht mag. Der Sender wird daraufhin einen neuen Header mit einem anderen Datenformat schicken, oder seinerseits die Übertragung abbrechen. Dies kann sich solange wiederholen, bis sich Sender und Empfänger auf ein Format geeinigt haben, oder bis feststeht, daß es keine Möglichkeit der Verständigung gibt.

Querverweis: Drag&Drop-Protokoll

Protokolle

BubbleGEM

Document-History-Protokoll