Replies: 1 comment
-
|
I think we are working on similar logic. My solution is to just set e.handled = true; in OnPointerPressed and handle selection manually in OnPointerReleased: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I’m implementing a custom drag & drop handler for a custom data view based on
TreeView/TreeViewItem, relying directly on pointer events (PointerPressed,PointerMoved,PointerReleased) rather than the built-in drag/drop APIs.While this mostly works, I’m running into a conflict between
TreeViewselection logic and drag initiation, and I’m looking for guidance on the intended pattern here or whether this is an area that could benefit from a small behavior change.Problem Summary :
Currently,
TreeViewItemselection happens onPointerPressed. This causes several issues when implementing drag & drop:Selection clears before drag intent is known : On
PointerPressed, TreeView selection logic runs immediately.If the user intends to drag, selection is already modified/cleared before I can decide whether this is a click or a drag.
I can cache the selected items before selection changes, so the drop logic works, but Visual state becomes incorrect
Selection visuals change immediately on press.
When a drag starts, the UI appears to “lose” selection briefly, which looks like a bug to users.
Range / multi-selection becomes sluggish
Because selection and drag logic are effectively “fighting” each other on pointer events, range selection feels slow.
In
PointerPressed, I Detect the pressed item ,Cache the selected items before selection is cleared .Start drag once the pointer movement exceeds a threshold
This keeps drag/drop behavior functionally correct, but the selection visuals and UX suffer, which feels fundamentally wrong.
Suspected Better Model
Ideally, selection would:
Be committed on PointerReleased
This would allow:
Clean separation between click and drag
without having to rewrite the selection behaviors
I found this PR which seems very relevant: #20356
However, I’m not fully sure: Whether this PR already solves this scenario
Whether it introduces a recommended pattern I should adopt
thank you .
Beta Was this translation helpful? Give feedback.
All reactions