- changed status to open
Subtree red highlight can differ from red bold leaf highlight
USE CASE: WHAT DO YOU WANT TO DO?
Accurately select a subtree that is highlighted in red.
STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)
- Open small_133x133.cdt
- Hover over a 2-node subtree whose left or right neighboring leaf is a part of a subtree that is larger than the 3 leaves combined (see red (2-node subtree) & yellow (neighboring subtree) highlighted regions of column tree in attached image).
- Very slowly drag left or right until the next leaf's branch is bold red and the subtree its parent is the root of is not all red (see attached image)
- Left-Click
CURRENT BEHAVIOR
The neighboring leaf's branch from it's parent to the leaf will appear in bold red. The rest of that parent's subtree is not highlighted in red. The click will select that whole subtree. The previously hovered two-node subtree remains highlighted in red.
EXPECTED BEHAVIOR
The whole subtree defined by the parent of the bold red leaf should be highlighted in red. The resulting yellow selection should be the same subtree that is highlighted in red. If the previously red 2-node subtree is not a part of the neighboring leaf's parent's subtree, it should no longer nbe highlighted in red. The bold leaf and the redsubtree should basically always coincide.
DEVELOPERS ONLY SECTION
SUGGESTED CHANGE (Pseudocode optional)
Since this bug happens both to the left and right of a 2-node subtree, I suspect this does not have to do with the calculation of the hovered matrix position being off by +/- 1. This is demonstrated by the fact that if you move the cursor 1 pixel up or down, the red highlight will be corrected. So this is probably either a failure in logic or a delayed update of the cursor position.
FILES AFFECTED (where the changes will be implemented) - developers only
unknown
LEVEL OF EFFORT - developers only
minor
COMMENTS
Comments (5)
-
reporter -
reporter - changed status to resolved
This commit resolves issue 388. The hover index that was set inside the mouseMoved method had to be set before the hoveredNode was set because hoveredNode was using the current hoverIndex to determine the currently hoveredNode, thus it was getting out of synch.
→ <<cset e885826df4c3>>
-
reporter This commit resolves issue 388. The hover index that was set inside the mouseMoved method had to be set before the hoveredNode was set because hoveredNode was using the current hoverIndex to determine the currently hoveredNode, thus it was getting out of synch.
→ <<cset e885826df4c3>>
-
reporter - changed component to Selecting Data
-
reporter - removed milestone
Removing milestone: Selecting Data (automated comment)
- Log in to comment
Starting work.