Drag-and-Drop Event and Visual State Issues with TreeViewItem in WinUI 3

[datskiy]

Describe the bug

There have been two issues found while using the drag-and-drop feature with TreeViewItem:

'DragOver' and 'Drop' Events Not Triggered

When dragging an element from a different component onto a TreeViewItem, the DragOver and Drop events are not triggered if the item is hovered over or dropped directly without interacting with other items first. However, if multiple items are hovered over sequentially, the events fire as expected, starting from the second item onward.

UPDATE: The proposed workaround for this issue was to use the DragEnter event instead, which does work. However, I still find it inconsistent that two similar events get triggered differently. Moreover, DragOver is the only event handler that is proposed to accept the request in this article, which seems a bit confusing: https://learn.microsoft.com/en-us/windows/apps/design/input/drag-and-drop

Stuck 'PointerOver' Visual State

Dragging an element from a different component and dropping it onto a TreeViewItem causes the item to remain stuck in the PointerOver visual state forever, unless it gets touched with another dragged item again.

The workaround for the 2nd issue by using VisualStateManager.GoToState has issues as well. Although it can force the visual state to revert to Normal, this only works if the state was set after the pointer left the item. If it was set while the pointer was on the item, the item will revert to its wrong PointerOver state again as soon as the pointer is out. To fully resolve the issue, the VisualStateManager.GoToState has to be put inside the PointerExit event handler.

Steps to reproduce the bug

1. Run the project: https://github.com/datskiy/TreeViewItemDropIssue
2. Drag the pink square and hover over or drop it directly onto any TreeViewItem, without touching any other items.
3. Observe that the DragOver and Drop events are not triggered unless you hover over multiple items first. The drop will fire the DragLeave event only.
4. Drop the element onto a TreeViewItem and observe that the chosen TreeViewItem item gets stuck in the PointerOver state.

Expected behavior

• DragOver and Drop events should consistently trigger when interacting with TreeViewItem.
• TreeViewItem should properly transition out of the PointerOver visual state after a drop operation.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.6.3: 1.6.241114003

Windows version

Windows 11 (24H2): Build 26100

Additional context

The VisualStateManager workaround mentioned above might help with the stuck PointerOver state, but only when the pointer exited the item.

Source code: https://github.com/datskiy/TreeViewItemDropIssue

[Skittles2519]

@datskiy I cloned your solution and was able to replicate your behavior, however, to get the copy to show up the way you are expecting, you need to set the accepted operation first on DragEnter as well as DragOver.

I added

private void TreeViewItem_DragEnter(object sender, DragEventArgs e) { e.AcceptedOperation = DataPackageOperation.Copy; }

along with the event in your treeviewitem datatemplate in the.xaml

Once you do that you will get the behavior you are expecting.
`

[datskiy]

@Skittles2519 Thank you for your response! It does resolve the issue, but it also got me thinking more about the matter. The thing is, in my tests the events were firing correctly on other controls like ListView or just a StackPanel, even without handling the DragEnter event. I tried re-attaching the drag-and-drop event to the TreeView itself, and it partially resolved this particular issue, but the events now come from TreeView and not TreeViewItem.

Anyway, DragEnter does help to resolve the 1st issue, but I still find it inconsistent that two similar events get triggered differently. Moreover, DragOver is the only event handler that is proposed to accept the operation request in this article, which seems a bit confusing: https://learn.microsoft.com/en-us/windows/apps/design/input/drag-and-drop

That said, the target element still gets stuck in the PointerOver state after dropping, so the 2nd issue is still relevant.