I just realized that if I’m doing a Drag within a window, and I set the DragItem.folderItem… then if the user drags out of my window to a Finder window, then the finder does a file move which is really not what I wanted and seems a dangerous default behavior.
I like havinging the folderItem set, because many other apps do a useful or sensible behavior (for example, drag a folderItem of a PNG to Safari, safari will load and display the PNG).
But the Finder’s default behavior of moving the file is not what I want.
Is there some way to control this? (I’d be OK if the Finder defaulted to copying the item, for example)
So on the Mac we have the horrible “Promised” files; which would partially solve your problem. In the sense that your app would get notified when the drop occurred and given the location of where to copy the files too. However… This is a potentially a big however, the destination application needs all the plumbing to handle promised file drops (Finder okay, but others probably not).
What if you simply check the path of the folderitem after the drop? Does it get updated with the new location? If so; now you know where the file was moved to (if at all)…
Some events such as https://documentation.xojo.com/api/deprecated/rectcontrol.html#rectcontrol-dragexit have an ‘action’ parameter (copy, move, link…) but it seems to be read-only. I wonder how the OS decides which action to use - I think what I want is to have a normal drag out of my app, but for it to behave as if the Option key was being held down so it does a copy rather than a move.
I had a quicklook at the underlying API (for the macOS) and I couldn’t see a way to enforce which action to take. Which is why I made the suggestions that I did.