Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ItemsControlExtensions.GetItemContainer finds wrong UIElement if dragging something into an empty ItemsControl that is placed INSIDE another ItemsControl #168

Closed
haukepribnow opened this issue Mar 1, 2016 · 1 comment
Milestone

Comments

@haukepribnow
Copy link

I have a situation where I have to nest ListBoxes on multiple levels and allow the user to drag and drop items between those nested boxes.

I found out that if a ListBox is empty, it seemed impossible to drag something into it. After a bit of debugging, I realized the following: When dropping my item onto a "child" ListBox (i.e. a ListBox that is nested within at least one other ListBox), the method GetItemContainer tries to find a ListBoxItem which I dropped the item on. However, since that ListBox is empty (and will therefore not contain any ListBoxItems), the method should not find any ListBoxItem. Unfortunately, because during the search it traverses the visual tree up (using GetVisualAncestor) - way beyond the empty box - it finally finds the ListBoxItem of the parent ListBox in which the child ListBox actually is placed in.

The result of this is that dropped items will be placed in the wrong (in this case: always the "root") ListBox, relative to the ItemsControl. (With "root" ListBox I mean a ListBox that is not nested within another ListBox.)

A potential fix would be to try to detect if GetVisualAncestor went "too far", i.e. if the found item is actually a parent of the original itemsControl. But I'm not completely sure if that would cause anything else to break. That's why I submit this as an issue instead of adding such a fix myself and submitting a pull request. (Another pull request will follow though that should provide a first step towards fixing this.)

@punker76
Copy link
Owner

punker76 commented Aug 1, 2016

@haukepribnow This should be fixed now with f877268

@punker76 punker76 closed this as completed Aug 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants