Question

Using the ‘standard’ VCL drag and drop events OnDragOver and OnDragDrop, how can I distinguish between “Copy” and “Move” operations?

I don’t seem to have a TDragType available, and the keyboard Shift state isn’t passed to these events.

Answer 1

This is not something you can determine from the events because the events make no assumptions about your application needs or capabilities.

Interpreting a particular drag/drop as having any particular semantics is the responsibility of the application itself – the OS cannot know how the application will react to the dropping of a file so can make no assumptions about what the dragging operation may imply for the user.

For many applications there will be no distinction between copy/move, there will be just drag-and-drop.

The copy/move distinction is something that Windows Explorer applies to file operations. For “vanilla” drag/drops it applies rules based on original and destination drive volumes – dragging/dropping files around on a volume is a move operation, by default. Dragging/dropping across volumes is a copy, by default.

But these are only default rules determined by the application (Windows Explorer). The user can override these default using keyboard shortcuts during dragging and (most importantly) when dropping. But these are defined and interpreted by the particular application – i.e. Windows Explorer – not the OS.

So, if you’re application is a drop target for files that may be dragged from Windows Explorer, and if it makes sense for your application to discriminate between copy and move, then you may need to support the same keyboard modifiers that Windows Explorer supports. I don’t believe these are modifiable (although I’d advise this be confirmed), so you could simply test the state of the Ctrl or Shift keys in your drag events:

Ctrl         = COPY
Shift        = MOVE
Ctrl + Shift = MAKE SHORTCUT  (if this is applicable to your application)

GetKeyState() can be used to directly interrogate the state of a specific key at any given moment in time.

If a varying “default” behaviour is desired then you would have to apply your own tests to the source information to determine which default makes most sense (i.e. to mimic the Windows Explorer “volume boundary” default rules), or simply choose the most appropriate or intuitive default action for your application.