Protocol for the Data Message

The data message is the third and final message sent as part of a negotiated drag'n'drop. It is sent in response to a negotiation message, using the BMessage::SendReply() function, and is sent only if the sender application has elected to pass the dragged data directly in a message. If the sender application passes data to the receiver via a file, no data message is sent. [xxx just want to check, is this correct? It would seem you'd want to at least send confirmation that the write was successful. Or should the receiver just do a node monitor kind of thing?]

When Data Is Sent in the Data Message

: If the sender elects to send the dragged data directly in the data message, then the data message will be constructed with the following structure:

A what member set to the value of the B_MIME_DATA constant.

A single message field, whose name indicates the type of mime data being sent, and whose contents consist of the data itself. For example, if you drag some text from one text processing window to another, the final data message (after the drop and negotiation messages have been sent) might contain a message field named "text/plain", which contains the text being dragged. Alternatively, if you dragged text from an HTML viewer, the data message might (depending on the negotiations) have a single field called "text/html", which would contain the text including the html formatting statements.

: Note that when the data messages arrives at the receiver, it may contain more than the single message field described above; other message fields might be added automatically, by parts of the system. However, the message field above is the only one you add.

Handling Drops from 'Old' Applications

: Negotiated drag'n'drop was defined relatively recently; older applications may still use the "old-style" drag'n'drop. It's simple for your application to take into the account that it might be a receiver for such a drop.

: Under the old style drag'n'drop, a single message was sent from the sender to the receiver, with a what member of B_MIME_DATA, and the value of the dragged data in the "be:data" message field. [xxx how is the type of the enclosed data determined?] Since your receiver application will need to monitor for BMessages with a what field of B_MIME_DATA (i.e. your application will need to look for the data messages that might occur as part of a negotiated drag'n'drop), it's simple to add in a bit more code that handles the fact that such a message may occur without being part of a negotiation, and may contain a "be:data" field.