Hi Mike,  exactly your last point,.  The total quantity of nodes in the tree could be very large so I took the decision early on that it was not worth while populating a branch until such time as the user attempted to expand it.  I am therefore handling the BeforeExpand and populating any children if there are any, updating the Expansion Indicator based on this.  There are however items being added to the tree which can never have children and as such I am setting those to 'Never' as part of the load of that node.  The SQL query to recover the data is pretty quick but I have found that it can take quite some time to populate / display the tree if you add a lot of nodes.

Is it possible to create and add a range of nodes in Outlook mode?  I can't see a way of doing this but I guess there may be a function I have not yet found to associate a column set with a new node (or range of nodes) before adding the nodes to their parent.

When you say "Change the ShowExpansionIndicator flag", do you mean you are changing it more than once? 
You should really only be setting that property once on the creation of the node or it's parent. It's not intended to be changed at run-time after the initial setting. 

Anyway, if you could whip up a sample project that demonstrates the performance hit, we could check it out. 

Good suggestion but you are probably correct in that it will cause problems later down the road.  I hadn't considered that the columnset just defaults to that of the parent node and doesn't actually 'inherit' it as such.

I still think the issue is more down to what happens when you change the status of the ShowExpansionIndicator flag.  My logic would say that setting the flag should do nothing but it must be firing an event somewhere.  I have the source code but for the life of me I can't see where the flag is being set as that would allow me to walk through the code and find out what it actually does.

Chris Drew said:

it would seem sensible to be able to create a new node and then set the columnset for it, then set the data based on that columnset, and finally add the node to its parent as a range. 

Well... you technically CAN do that. But I don't think it's a good idea. There may be ramifications that cause behaviors you don't want. 

            this.ultraTree1.ViewStyle = ViewStyle.OutlookExpress;

            var columnSet = new UltraTreeColumnSet();
            var keyColumn = columnSet.Columns.Add("Key");
            keyColumn.DataType = typeof(int);
            var nameColumn = columnSet.Columns.Add("Name");
            nameColumn.DataType = typeof(string);
            var descriptionColumn = columnSet.Columns.Add("Description");
            descriptionColumn.DataType = typeof(string);

            this.ultraTree1.ColumnSettings.RootColumnSet = columnSet;

            List<UltraTreeNode> rootNodes = new List<UltraTreeNode>();
            for (int i = 0; i < 10; i++)
            {
                var rootNode = new UltraTreeNode();
                rootNode.Override.ColumnSet = columnSet;
                rootNode.SetCellValue(keyColumn, i);
                rootNode.SetCellValue(nameColumn, string.Format("Name {0}", i.ToString()));
                rootNode.SetCellValue(descriptionColumn, string.Format("Description {0}", i.ToString()));                
                rootNodes.Add(rootNode);
            }
            
            this.ultraTree1.Nodes.AddRange(rootNodes.ToArray());

So this code creates the node and then set the ColumnSet on the individual node so that it can set the cell values. 

The problem with this is that every node now has a direct reference to the ColumnSet, rather than just picking it up from the collection. To be honest, I'm not entirely sure what the ramifications of that are. In my example, they are all pointing to the same ColumnSet instance, so that's not a big deal - it's not like I am creating more than one ColumnSet. And since they all use the same instance, Sorting and AutoSizing the columns still works. 

Something tells me there's going to be a price to pay for this approach, but I can't think of exactly what it is right off the top of my head. But I suppose you could try it out. 

I doubt it will have any effect on the performance issue you reported initially for this thread, though. 

Thanks Mike - it would seem sensible to be able to create a new node and then set the columnset for it, then set the data based on that columnset, and finally add the node to its parent as a range.  I would doubt if adding the nodes as a range and then filling in the details would be any different to adding them one at a time after setting their details assuming that the Begin / EndUpdate flags do what they are supposed to!  

So... if you are using ViewStyle.OutlookExpress, or really any style with columns, and you create a node outside of the tree, then that node has no way of knowing what it's columns will be until you add that node into a Nodes collection where it can resolve the ColumnSet. So I don't see any way to do what you are describing using AddRange. 

That is to say, you can't create the node outside the tree and give it the cell data before adding it to the tree. 

You can, of course, create an array of empty Nodes and use AddRange to add all of those nodes to the Nodes collection using AddRange, and then go back and fill in the cell data into each node once they are in the collection. 

This might be a good candidate for a feature request. It probably wouldn't be that tough for us to add some way to set the cell values on a node with no ColumnSet and then hook up the data once that node gets added to the Nodes collection. But right now, I don't see any way to do this.