Oliver, thanks for sending me your patch. It's up to the application to initiate a drag operation. The win32 user interface guidlines recommend that the application should initiate a drag operation when the user clicks and holds the left-button (with or without modifiers) within selected text. Most applications also initiate a drag when the right button (button3 in XEmacs) is used in the same way. On dropping text, the text should be copied if the Ctrl modifier is held down and should be moved if Ctrl isn't down. Mod and Shift are ignored. Some applications display a popup menu when text is dropped with the right button: the menu offers the user the choice of copying or moving the text. We probably don't need to bother with this and can just treat a right-button like a left-button. The button and modifier state is ignored for file drops. Because the state of the Ctrl modifier is examined at _drop_ time, but affects whether the _dragged_ text should be deleted, dragging is a two-stage operation and needs both a start-drag and a stop-drag function. I imagine that you're aiming for the lisp-level dispatch functions to be independant of the dnd system in use. Does the desired mswindows behaviour that I've described sound consistent with that goal? Actually, dnd for text uses a different and more complicated win32 API than dnd for files. I don't plan to implement dnd for _text_ for XEmacs 21.0. This means that for XEmacs 21.0, the mswindows code won't be able to initiate drags and will only have to handle file drops. Jonathan. -- Jonathan Harris | jhar(a)tardis.ed.ac.uk London, England | Jonathan-Harris(a)psion.com