Protocol for the Negotiation Message

When the receiver application receives the initial drag message from the sender application, it examines the data message in that message, to ascertain what actions the sender application can carry out, and how it can provide the desired data in the final drag message. Using this information, the receiver application formulates the negotiation message, which it sends back as a reply to the original drag message using the BMessage::SendReply() function.

A Negotiation Message is Characterized by its 'what' Member

: Recall that the drag message constructed by the sender application contained (among other things) a "be:actions" message field, which indicated the actions the sender was willing to perform upon the dragged data. The allowable actions (at the time of this writing--further actions may be added in the future) are given by the following constants:

B_COPY_TARGET
B_MOVE_TARGET
B_LINK_TARGET
B_LINK_TARGET
B_MOVE_SELECTION_TO (for Tracker drags only.)
B_COPY_SELECTION_TO (for Tracker drags only.)

: When constructing the negotiation message, the receiver application will choose one of the actions listed in the data message's "be:types" message field (remember, not all allowable actions will necessarily be listed in this message field), and use that action as the value of the what member in the negotiation message. This will inform the sender application of which of the possible actions is desired by the receiver.

Message Fields in the Negotiation Message

: In addition to the action contained in the what member, the negotiation message may also contain a number of message fields; exactly which message fields are defined depends somewhat on the requested action. The allowable message fields are:

"be:types": One or more strings denoting the data formats the receiver is willing to accept the dragged data in, as part of the data message. These should be chosen from the "be:types" field of the drag message. If the "be:types" field of the negotiation message contains more than one value, then the first value is the format the receiver would prefer to get data in, but the sender may choose any of the formats, at its discretion. Of course, if the sender has indicated in the drag message that it will only pass data through a file, values in the negotiation message's "be:types" message field will be ignored when the negotiation message gets back to the sender.

"be:filetypes": One or more strings denoting the data formats the receiver is willing to accept file data in, assuming of course that the sender indicated in its drag message that it was willing to provide the dragged data via a file. The values in the negotiation message's "be:filetypes" field should be chosen from those provided in the drag message's "be:filetypes" field. It the negotiation message contains more than one value in "be:filetypes", then it would prefer to be given a file in the first listed format, but the sender is free to use any of the listed formats.

"directory": If the sender decides to (or is forced to) pass data to the receiver via a file, the entry_ref stored in the "directory" field of the negotiation message indicates the directory that the file should be created in.

"name": If the sender decides to (or is forced to) pass data to the receiver via a file, the string in this field should be used as the name of the file. Note: the receiver should create the file before deciding on a file name, to ensure that file name is in fact available, and will remain available.

: Of course, you can leave out fields that don't apply to a particular action. For example, if the receiver chooses B_TRASH_TARGET as the action (by putting a value of B_TRASH_TARGET into the what member of the negotiation message), no message fields are required; in fact, the sender doesn't even need to respond to a request of B_TRASH_TARGET with a data message, it simply has to delete the dragged data.