With a databound tree, the creation of node objects is deferred until its parent becomes visible. This makes sense to be the default behavior, but can the lazy instantiation be disabled?
I would like to walk the tree up and down to apply checked state logic but find I cannot follow the Nodes collection down to the leaf nodes unless the tree is expanded. Further, as soon as a new item is added to the datasource I need InitializeDataNode to fire in order to apply an initial checked state.
Is there a property I have overlooked to turn off deferred node creation?
I'm on the latest and greatest of 11.2.
Thanks!
Hello,
I have tried to reproduce your issue on my end, so I have created UltraTree and also have applied a logic, which iterate UltraTree's nodes in order to determine check state of child/parent nodes, and I am able to access child nodes without expanding its parent. Please see attached video,
when I click onto ultraButton1, it sets ultraTree1.Nodes[0].Nodes[0].Nodes[0].CheckedState = CheckState.Checked;, which mean that the very first node should changes its state. Change the checked state of 3-th node of first level and after I expand this node, its child nodes are correctly checked. Also I am attaching the sample which I have created for my tests.
Please let me know if you have any further questions or if I am missing something
Thank you for the prompt reply. It looks like the issue is unique to the custom IBindingListView I'm using, which more than likely means the issue lies within the datasource itself or the usage thereof.
Correction, it was my method of checking for child nodes. I was using the HasNodes property of the node rather than accessing the Nodes collection (which I presume forces the creation) and checking the count.
You can see my confusion by adding two lines to the top of your ultraButton1_Click handler:
private void ultraButton1_Click(object sender, EventArgs e){ bool a = ultraTree1.Nodes[0].HasNodes; bool b = ultraTree1.Nodes[0].Nodes[0].HasNodes; ultraTree1.Nodes[0].Nodes[0].Nodes[0].CheckedState = CheckState.Checked;}
In this example 'a' and 'b' will both be false, yet you are able to index into the collections. The description of HasNodes does not indicate anything about the possible discrepency.
Hello,
I am just checking about the progress of this issue. Let me know If you need my further assistance on this issue?
Thank you for using Infragistics Components.
In order to clarify this scenario the documentation about this property will be updated as soon as it is possible. If you have any further questions regarding Infragistics Components, please do not hesitate to contact with us.
Hi,
The HasNodes property is behaving correctly, but if this is not documented, then you are correct, it certainly should be. I have forwarded this thread over to our documentation folks so they can get it corrected.
As pointed out in my last reply, I am able to just walk the Nodes collections to force the Node creation, so I no longer have an issue.
My remaining point was that the HasNodes property is wrong and/or misleading because its value is dependent on if the Nodes collection has been accessed to force the Node creation.
Either HasNodes should explicitly document this caveat or the accessing of HasNodes should force the Node generation itself.