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

Revised determination of a next or previous visible node (at "v7") #1279

Merged

Conversation

hermannoffen
Copy link
Contributor

@hermannoffen hermannoffen commented Nov 29, 2024

This fixes #1278. See also PR #1280.

René Hoffmann added 2 commits November 29, 2024 15:47
- added method 'TBaseVirtualTree.GetTopInvisibleParent' to retrieve the topmost node of an effectively invisible subtree
- the resulting node can be invisible by lacking the 'vsVisible'-flag on its own or having its parent lacking the 'vsExpanded' flag
- all of its sub-nodes can be considered effectively invisible
- all of its ancestor-nodes can be considered to be effectively visible
- 'nil' is returned if all nodes from 'Node' up to 'FRoot' are effectively visible
…it]' completely to ensure a node cannot be returned as its own next or previous node

- updated methods 'TBaseVirtualTree.GetNextVisible' and 'TBaseVirtualTree.GetNextVisibleNoInit' as well as 'TBaseVirtualTree.GetPreviousVisible' and 'TBaseVirtualTree.GetPreviousVisibleNoInit' to harmonize the determination of a next or previous visible node
- used method 'TBaseVirtualTree.GetTopInvisibleParent' to optimize the search by skipping effectively non-visible subtrees as a whole independent from 'ChildrenAbove' mode
- applied the condition to force searching for another node from 'TBaseVirtualTree.GetNextVisible' and 'TBaseVirtualTree.GetNextVisibleNoInit' to 'TBaseVirtualTree.GetPreviousVisible' and 'TBaseVirtualTree.GetPreviousVisibleNoInit'
- extended that condition to force searching for another node when the current node is known to be in an effectively non-visible subtree
- thus, the input node cannot be returned as its own next/previous visible node, which is ensured with an assertion at the end of each method
- note that the usage of other methods obscuring the traversal algorithm, such as 'GetVisibleParent', 'GetFirstVisible', 'GetLastVisible', 'GetPreviousSibling', etc. is avoided
@hermannoffen hermannoffen changed the title Revised determination of a next or previous visible node Revised determination of a next or previous visible node (at "v7") Nov 29, 2024
@joachimmarder joachimmarder merged commit 820b535 into JAM-Software:V7_stable Dec 5, 2024
@hermannoffen hermannoffen deleted the fix-overflow@V7_stable branch December 5, 2024 08:23
@joachimmarder joachimmarder added this to the V8.1 milestone Dec 5, 2024
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

Successfully merging this pull request may close these issues.

2 participants