Search Issue Tracker
Fix In Review for 2022.2.X
Votes
12
Found in
2022.1
2022.1.0b9
2022.2
Issue ID
1408661
Regression
No
Not possible to determine which element was dragged, what's its position or which operation was performed when using TreeView
How to reproduce:
1. Open project "But.zip"
2. In the Hierarchy window select "MyComponent" GameObject
3. In the Inspector window select the "I am root" object in the "My Component" Component
4. Click the "Print Child Index" button
5. Observe the result
Expected result: Child elements return "-1" and there's a way to know its position
Actual result: Child elements return "-1" and there's no way to know its position
Reproducible with: 1.0.0 (2022.1.0b15, 2022.2.0a10)
Could not test with: 2019.4.37f1 (No UI Toolkit package), 2020.3.33f1, 2021.2.19f1, 2021.3.0f1 (unable to test due to TreeView protection errors)
Note:
- Same results if dropping an element onto another element or between two elements
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Catsoft-Works
Apr 15, 2022 15:36
I'm the reporter of this bug. Just to make the explanation a bit clear, here's an explanation of the problem which motivates the report.
Here's a sketch of the tree view (add "https://" below):
drive.google.com/file/d/1oaC32nGy98HlA02UyFuEuwt_MjzwjZbH/view?usp=sharing
This is a TreeView where each element has an identifier (A, B, C, D, ...), and each element has an index, starting from 0 and incrementing a unit each for each subsequent element, just like TreeView API does.
Let's say we drag the element X and drop it somewhere else. As soon as we do that, the "itemIndexChanged" event fires and executes with the index of the element dragged, as well as the index of the element dropped.
However, because both parameters are indices, and not the element ID, we can never know what element was dragged (X in this case), because that position is no longer valid, since the state of the Tree has changed due to the move operation.
Apart from that, if we drag and drop the element X onto B, X will be placed as a child of element B and the "itemIndexChanged" callback will have the following parameters:
As the draggedIndex, the index of element X (which is n), and as the dropped element index 1.
However, if we drag and drop element X again, but this time, right below element B, the parameters will still be n and 1.
This poses a problem, because it's impossible to determine what element was dragged, as well as what operation was performed, since the signature parameters are exactly the same when dropping an element onto another one, or between two elements.
Hope that makes sense! This could all be easily solved if the "itemIndexChanged" event filled the callback parameters with the unique ID of TreeViewData structure, instead of the indices.