Topic       : The ATARI Compendium
Author      : Scott Sanders / JAY Software
Version     : 1.25 (20/6/2003)
Subject     : Documentation
Nodes       : 1117
Index Size  : 32614
HCP-Version : 6
Compiled on : Atari
@charset    : UTF-8
@lang       : en
@default    : 
@help       : %About
@options    : +g -i -t4 +y +z
@width      : 100
View Ref-File
                             The Recipient


The drag and drop protocol begins for the recipient upon receipt of the
AP_DRAGDROP message. When this message is received, the recipient should
immediately open the pipe 'U:\PIPE\DRAGDROP.xx', where 'xx' is the
two-byte ASCII identifier given in WORD 7 of the message, and write
a DD_OK (0) to the pipe.

Next, as the recipient, you should construct a 32 byte structure
consisting of eight 4 byte data names your application can receive. If
your application recognizes less than eight types of data pad the 32 bytes
with zeros. After this structure is constructed, write it to the pipe.
Now you should read a WORD from the pipe which will indicate the size of
the message header which should be read immediately after. The message
header consists of a four byte ASCII data type, a LONG indicating the size
of the data, a NULL terminated string of variable size which identifies
the data (or simply NULL if none), and a NULL terminated filename (or
NULL if none).

After decoding the message header you should respond with one of the
one-byte response codes as listed in the previous table. If the recipient
cannot process the data type sent, it should send DD_EXT and wait for
reception of another header (preceded again by a WORD headed size). If the
originator cannot supply any more data types you will receive a 0 byte
return from the Fread() call and you should Fclose() the pipe and abort.
If the data type is acceptable, respond with DD_OK, read the number of
data bytes as indicated in the header to receive the actual data, and then
close the pipe.

A special case arises if the header specifies 'PATH' as a data type. In
this case you should send a DD_OK message (if appropriate) and write the
pathname associated with the target window (you can write as many bytes as
is specified in the message header data length).