Does anyone have a solution to this old problem? It still exists in release 2024.4.1
IIRC, destination is only set if you’re dragging to Finder.
See https://tracker.xojo.com/xojoinc/xojo/-/issues/71193 . The destination is nil when dragging to Finder. This stupid bug is now over 10 years old.
Good grief. This is extra embarrassing because the documentation for DragItem.Destination is so comprehensive.
I did some research into the current macOS drag API and the Carbon Drag Manager. The Carbon Drag Manager explicitly provides a clear way to get the destination of a drag if the destination is the Finder; the newer macOS drag API could provide this but it seems to require a bunch of callbacks instead of a direct procedural access method. All of the Carbon API stuff is long deprecated, of course, so there’s no going back.
So it looks to me like DragItem.Destination probably dates back to the old Carbon days and when the rest of DragItem was moved to AppKit, Destination didn’t make the cut even though it was left in the documentation.
On a hunch, I checked to see if DragItem.Handle is valid for outgoing drags - just in case there is some way to get at the drag’s data via Declares. It is always zero for outgoing drags, although incoming drags do show a value for Handle. So no hope there, and really not much of a surprise. I would hazard to guess that when you call DragItem.Drag, Xojo does all the work of creating the AppKit drag objects, handles the drag, and then destroys all those objects before you have a chance to inspect them after the drag is completed. An incoming drag is inherently unfinished when the DropObject event is called and so DragItem.Handle has a valid value.
I suppose one could re-implement the macOS drag stuff via Declares. MacOSLib already has a good chunk of it in place and it could possibly be made to work for some Xojo controls.
1 Like
From what I read it stopped working more than 10 years ago.
Is not (never) available for Windows and Linux.
Weird that they just didn’t mark it as deprecated and removed.
Will it ever work again?
I guess if someone really need it, either found a plug-in solution (if any) or other alternative (not shared here yet).
I have lost count of the time in my life when I had this conversation:
“Can I use/buy this thing?”
No - we stopped doing it because nobody ever asks for it.
“What did I just do, then?”
If you read Apple’s docs, they are very specific about the drag items being short-lived and that they shouldn’t be inspected outside of certain functions. That makes me think that Xojo isn’t doing the destroying, but Apple.
Well, dragging emails from - say - Mail or Outlook to the desktop works fine. Or dragging something from the browser to the desktop. So me thinks that the bug is a Xojo one.
2 Likes
Right, but those apps are written on objective-c. The trick is that Xojo sometimes can’t just directly expose the objective-c delegate call directly to Xojo users, especially if they tried to match the exact same experience as the way it was done in Carbon. IIRC, that’s what we had done for backward compatibility but as Apple has gradually deprecated and created new APIs they don’t guarantee that the old stuff will keep working. I suspect that Mail (Apple) and Outlook (Microsoft) are just keeping up with the API changes as they come.
1 Like
Well, that’s what I’m saying: perhaps internally the DragItem.Drag does all the setup and teardown so that nothing is left of the various AppKit objects by the time it returns control to your code. Given that .Drag is synchronous in Xojo and the more involved AppKit stuff involves promises and callbacks, this probably means that Xojo’s drag support would have to be reengineered to support the more advanced functionality.
In the old days, you would call a Carbon function to get the destination of the drag, which would return an Apple Event descriptor in the form of an alias record if the destination was the Finder (this appears to have been a special case just for the Finder). This would allow the result of the drag to be easily recorded in the Destination property and would persist after the drag concluded.
It’s definitely a bug that DragItem.Destination compiles and is still described in the documentation. The underlying issue is that it was mapped to functionality that is so radically different in the modern system that it will require significant rethinking of how dragging works in Xojo to make it work again.
1 Like
@Geoff_Perlman : what can you say on this topic? Is the bug fixable?
Perhaps. William looked into it a year ago. I’m going to ask him to look into it again.
2 Likes
@Geoff_Perlman Not to pile on, and please absolutely take a look at Beatrix’s case as she’s definitely longest in the queue, but I’d appreciate if you could take a look at this thorn in my side as well:
Will do.
2 Likes