Drag-Drop improvements

Is your feature request related to a problem? Please describe.

A couple issues I’ve come across with drag-drop (in-app, not to/from external process):

1 - IMO, the drag-drop events really need to sit in one of the base classes to all controls like it is in WPF/UWP (in UIElement). There are some cases where being able to do some logic before or after one of the drag events is raised is super helpful (thus needing a protected virtual method) as you can’t rely on AddHandler() to do, particularly in the latter case.

2 - If a control that acts as a drag source contains a ToolTip, the ToolTip needs to be hidden as part of drag drop activating, which follows WPF. Otherwise, the ToolTip will hide, but the drag/drop icon flickers as the pointer moves.

3 - DragLeave event should have DragEventArgs instead of just RoutedEventArgs - so pointer information can be retrieved

4 - One of the things I also was trying to implement, similar to UWP dragging, is a popup with a preview of the item being dragged - except it seems the popup doesn’t respond to the changes in position during drag drop. popup.Host.ConfigurePosition() is called but the popup remains in one place. It also seems that all of the InputManager methods (process, preprocess, postprocess) don’t do anything during drag drop and return (-1,-1) only once upon querying RawPointerEventArgs.Position, which makes this task impossible to achieve in any way that I can see. I’ve tested with WPF and this is possible

5 Current implementation preprocess events in global static IInputManager to simulate dnd

Describe the solution you’d like A clear and concise description of what you want to happen.

Describe alternatives you’ve considered A clear and concise description of any alternative solutions or features you’ve considered.

Additional context Add any other context or screenshots about the feature request here.

[amwx]

I’ve done some more investigating into this, particularly (4). The InputManager returning (-1,-1) is only occuring because the wrong RawEvent is being queried. If you use RawDragEvent instead of RawPointerEventArgs you can still get input messages during drag drop. The (-1,-1) is from a random WM_MOUSELEAVE event that occurs shortly after starting DragDrop However, this will only work while dragging inside the HWND. In WPF you can get this to work by handling the GiveFeedback event, originating from IOleDropSource.OleGiveFeedback but to get the mouse position outside the window you need GetCursorPos() which obviously doesn’t work for touch/pen. Though I have no idea if the other platforms have something similar to OleGiveFeedback/is a way to mock it for parity. So (4) may not be entirely possible in a cross-platform, modern framework like Avalonia. Not to mention, I still cannot figure out why the popup refuses to move when in drag-drop (even if force-repositioned after RawDragEvent)

UWP does have CoreDragOperation.SetDragUIContentFromSoftwareBitmap, so there might be an option to pass in a bitmap to be set as the mouse cursor that gives the drag preview. Still requires the GiveFeedback event, has the downside of removing the default drag feedback cursors, and probably isn’t cross-platform.

Also an aside, RawDragEvent probably should be renamed to RawDragEventArgs to be consistent with the other raw event args.

[Hanprogramer]

I think Avalonia needs a way to allow/not allow drag and drop from code. This would be better explained in a scenario: You’re trying to implement drag and drop, then there’s a target to drop files, but it only accepts certain file formats, for example just PNGs, we need a way to handle this properly.