Question

So I have a TreeView that starts off empty. Sequence of events is as follows:

1. Add a new root node. Code makes the label edit box pop up immediately, and I give it a name.
2. Add a new subnode to that root node.
3. Add a new root node, after the first one. The label edit box pops up, and I give it a name.

The second root node takes on its new name, but so does the subnode added in step #2. Now, it’s not really the subnode’s text; if I examine that TreeNode in the debugger, it has the proper text for a subnode. But that text that was entered into the root node sticks around through expanding and collapsing its parent node, until something else happens and I need to rebuild the tree.

I’m building the tree in kind of an odd way—removing all root nodes from the parent, all child nodes from the root, updating all the tags and text, creating new nodes, then re-adding the nodes to their parents—but I’ve checked, and the proper text is being associated with the proper node. The TreeNode that is showing the wrong text has only ever modeled the one object, never had anything else in its Text property, and has its text set back to the right value (“untitled action”) right before being re-added to its parent node.

All I can think of for a culprit is the code for the label editing box, which is based on an MSDN sample:

Private Sub EditSelectedCategoryName()
    If Not ActionList.SelectedNode.IsEditing Then
        ActionList.LabelEdit = True
        ActionList.SelectedNode.BeginEdit()
    End If
End Sub

Private Sub ActionList_AfterLabelEdit(ByVal sender As Object, ByVal e As NodeLabelEditEventArgs) Handles ActionList.AfterLabelEdit
    If e.Label IsNot Nothing Then
        e.Node.EndEdit(False)
        CType(e.Node.Tag, ImportActionCategory).DisplayName = e.Label
    Else
        e.Node.EndEdit(True)
    End If
    ActionList.LabelEdit = False
End Sub

EditSelectedCategoryName is called by a context menu item’s Click event, right after the new root node is added and made the selected node. The DisplayName setter in the AfterLabelEdit event handler is what triggers another chain of events that rebuilds the tree. So am I screwing up some internal structure of the TreeView by altering its contents in the AfterLabelEdit event?

Answer 1

I added

e.CancelEdit = True

right at the end of the AfterLabelEdit handler, and the problem went away. Apparently I was futzing with some assumed invariant of the TreeView…