Hi all. Before the update to the 2009, (latest April release), this worked fine. I have a form where our users can construct a navigation tree for viewing documents (pdfs) When they select a node with a mouse click or any other way, then press a button that fires off a Reposition of the node up or down. After the reposition takes place, I clear the selected nodes, then use the getnodebykey (each node has a guid for key) to find the node and set it as selected. In debug all looks great... the selected node is what is should be until I return focus back to the tree. The tree thinks the selected node is 2 postion down. This is constant on all repositioned nodes. I have not changed any code, as mentioned earlier... this just started with the upgrade to the latest release. Is this a know issue or has something changed I'm not aware of? or new process for repositioning nodes?
Thanks, Richard
May 20,2009
I think the problem is that my getnodebykey is getting overriden by something. I can kind of reproduce this in the samples provided for the winform wintree. "Drag n Drop". When I select a node, then drag it up or down, then drop it, it is no longer the selected node but the node that currently holds it's previous position is the selected node. I would expect the "Drag n Drop" node to be the currently selected node.
Is there anyway to override this behavior?
I will try and produce some simple code to so this action with the repostion method and then reselect a node through the getnodebykey while in the a button_click event.
This sounds like it might be a bug, especially if you are certain that the behavior is different than in previous releases. I recently fixed a bug in the control that might expain this behavior (although I am not 100% certain that I followed exactly what you were describing). The bug I am thinking of cleared itself up when the control was resized, so if the control is docked or anchored, trye resizing the form it is on right after repositioning and see if that clears it up. If it does, it could be a bug that was recently fixed and will be included in the next service release.
Regarding your assertion that, "When I select a node, then drag it up or down, then drop it, it is no longer the selected node but the node that currently holds it's previous position is the selected node"; I have no explanation for how you observed this in an unmodified version of the sample because the Reposition method explicitly deselects the node to avoid selection strategy violations.
Hi Brian. Thank you for your response. I've resolve or at least worked around my issue.
In the previous version, when setting the node.selected = true, the node was also set as the utWinTree.ActiveNode.
With the 9.1.20091.1000 setting the node.select = true, did not set the node as the utWinTree.ActiveNode.
I had to explicitly set utWinTree.ActiveNode = utWinTree.SelectedNodes[0]; then all was bac in sync.
Cool. In any case, I had to explicityly set the selected Node to the ActiveNode where I did not have to in the 8.3.20083 version. Unfortuntly I don't the the luxury to spend the time between the Infragistic release to prove what works and does not work.
The process worked on 8.3.20083 then for the 9.1.20091.1000 release, I had to when setting the Selected Node to true also set that node as the ActiveNode in order for the process to continue to function properly.
It is working now. So I've moved on. Hopefuly, this information is helpful to your QA department.
Thanks so much.
Just to clarify, setting the node's Selected property does not and never did, as far as I can tell, make that node the ActiveNode. When no ActiveNode has been explicitly set, the first visible node in the tree is returned from the ActiveNode property, so it would seem possible that you are mistaking this for something else. Any change across releases in behavior such as this would be considered a bug and should be reported as such, so if you can reproduce this behavior reliably you should report it or attach a sample that demonstrates the behavior here and we can take it from there.