Topic       : Documentation for Thing
Author      : Arno Welzel/Thomas Binder/TransAction
Version     : thing.hyp 1.27E (23/8/1998)
Subject     : Documentation/Shells
Nodes       : 269
Index Size  : 6336
HCP-Version : 4
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : %I
@help       : %Hilfe
@options    : +g -i -s +y +zz -t4 -d10
@width      : 75
@hostname   : THING   
View Ref-FileDrag&Drop Protocol                                                    Thing

This protocol was introduced by Atari for MultiTOS and has since been 
supported by MagiC!3 amongst others.

Thing as sender

Thing automatically operates this protocol if one or more objects in a 
window are Drag&Dropped onto a window belonging to another application 
which doesn't belong to an AV client and hasn't registered its windows 
with AV_ACCWINDOPEN.

Thing can even 'convert' AV Drag&Drop messages (AV_DRAG_ON_WINDOW) to 
Drag&Drop Protocol messages! This makes it possible to, say, search for 
files using ParaFin and send the result to CoNnect via Drag&Drop...

If the receiver does not understand the Dra&Drop Protocol or the system 
(e.g. MagiC! v2/Single-TOS) does not support it, then Thing tries sending 
a VA_START message with the names of the Drag&Dropped objects as the 
command line, which usually works so long as the system supports querying 
of ownership of desktop windows (tip for Single-TOS users: Use WINX).

Thing as a receiver

If a '.xxx' block is Drag&Dropped on the desktop, Thing requests a path to 
save the file to. If a drive etc. is selected as the destination the 
corresponding path is displayed as a guideline. If the block is 
Drag&Dropped onto the clipboard, Thing automatically saves the data as 
'SCRAP.xxx' in the GEM clipboard.

Drag&Dropping a block to the trashcan or the printer is answered by Thing 
with DD_TRASH or DD_PRINTER respectively -- it's then up to the sender to 
react to this in a sensible way.

If an application's dialog window is chosen as the destination, then the 
block, if it is a '.TXT' block, will be inserted into the current editable 
field (if this is sensible -- that's why it won't work with all dialogs).

'ARGS' blocks are handled as VA_START messages, i.e. they are passed 
via the command line and simply executed.

'PATH' blocks are still currently not supported and rejected with DD_NAK.