Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
2150
What are the Practical Limitations for Self-Referencing UltraTrees ?
posted

I'm working with the UltraTree and we have a table with self-referencing data that forms a hierarchy.

According to the following KB, one step in loading the data is that many "root-level nodes" need to be hidden (they are positioned/visible in the root of tree by default, even though they have a reference to a valid parent that lives elsewhere in the tree).

http://devcenter.infragistics.com/Support/KnowledgeBaseArticle.aspx?ArticleID=10084

"If you were to run your application at this point, you will notice that not only does the UltraTree display all of the nodes in the correct hierarchy, but it also displays all of the nodes on the root level as well. This is because the UltraTree does not intuitively know not to show the unnecessary data. To work around this problem, you need to handle the UltraTree’s InitializeDataNode event and hide the unnecessary root-level nodes."

The main problem I'm encountering when loading lots of data is the amount of CPU involved in setting UltraTreeNode.Visible to false.  This takes a long time for a large tree.  The profiler shows most of the time spent in these areas (internal UltraTree code).  This happens during the InitializeDataNode event.

- Infragistics.Win.UltraWinTree.UltraTreeNode::set_Visible

- Infragistics.Win.UltraWinTree.VisibleNodesManager::Reinitialize

Given that I'm waiting so long just to "hide the unnecessary root-level nodes" , I suspect I've reached the limit of the number of nodes that can be supported by the UltraTree.  We are loading 10's of thousands.  

Can someone verify that this is the practical limit of what the UltraTree supports?  Has anyone tried to load trees with more than 10,000 items?  Is there any way to improve the performance while changing of the visibility of these nodes?  Would it be possible to do this on background threads? (I'm assuming that would involve U/I errors or concurrency errors...).

Any help would be appreciated.