K
kiwidude
All,
Microsoft appear to have changed the internal implementation of the
TreeView control and the changes appear to be not for the better as far
as my application is concerned. Has anyone else had performance issues
with it?
The issue I have is that I need to change the .Text and .ImageIndex of
the nodes AFTER the tree has been populated. This is because the tree
contains percentages etc based on the children of each node.
In .Net 1.0/1.1 I had this finely tuned to do a "load on demand". I
override OnBeforeExpand() so as you expand a node it updates the
text/imageindex of the children which works really well. The number of
node children is usually around the 10-20 mark but often only a few, so
very little processing involved this way. Performance is great under
1.1.
However running exactly the same code under .Net 2.0 gives what ranges
from "appalling" to just plain "dire" usability.
The "improved" performance is gained by adding BeginUpdate/EndUpdate
around the code which iterates through the child nodes updating the
..Text. However the performance is still completely awful compared to
..Net 1.1, and it comes down to the .EndUpdate method which is chewing
up the time in it's calls to Control.SendMessage.
The alternative without using BeginUpdate/EndUpdate?
I found that when setting the Node.Text property the TreeView goes into
meltdown with literally millions of windows messages and handle
requests initiated through TreeNode.set_Text -> TreeNode.UpdateNode ->
TreeView.ForceScrollbarUpdate.
As an experiment I set "Scrollable=false" on the TreeView. Sure enough,
I now get the equivalent of .Net 1.1 performance when expanding... but
of course now the treeview is not scrollable. You ask "why not just
turn that off and on afterwards then"? Because the TreeView appears to
completely reset and redraw itself when the Scrollable is set back to
true which is completely unusable.
So - I'm knackered if I used EndUpdate, and I'm knackered if I don't.
Does anyone have any suggestions? At the moment it is "don't use .Net
2.0" which clearly ain't gonna fly long term.
Many thanks.
Microsoft appear to have changed the internal implementation of the
TreeView control and the changes appear to be not for the better as far
as my application is concerned. Has anyone else had performance issues
with it?
The issue I have is that I need to change the .Text and .ImageIndex of
the nodes AFTER the tree has been populated. This is because the tree
contains percentages etc based on the children of each node.
In .Net 1.0/1.1 I had this finely tuned to do a "load on demand". I
override OnBeforeExpand() so as you expand a node it updates the
text/imageindex of the children which works really well. The number of
node children is usually around the 10-20 mark but often only a few, so
very little processing involved this way. Performance is great under
1.1.
However running exactly the same code under .Net 2.0 gives what ranges
from "appalling" to just plain "dire" usability.
The "improved" performance is gained by adding BeginUpdate/EndUpdate
around the code which iterates through the child nodes updating the
..Text. However the performance is still completely awful compared to
..Net 1.1, and it comes down to the .EndUpdate method which is chewing
up the time in it's calls to Control.SendMessage.
The alternative without using BeginUpdate/EndUpdate?
I found that when setting the Node.Text property the TreeView goes into
meltdown with literally millions of windows messages and handle
requests initiated through TreeNode.set_Text -> TreeNode.UpdateNode ->
TreeView.ForceScrollbarUpdate.
As an experiment I set "Scrollable=false" on the TreeView. Sure enough,
I now get the equivalent of .Net 1.1 performance when expanding... but
of course now the treeview is not scrollable. You ask "why not just
turn that off and on afterwards then"? Because the TreeView appears to
completely reset and redraw itself when the Scrollable is set back to
true which is completely unusable.
So - I'm knackered if I used EndUpdate, and I'm knackered if I don't.
Does anyone have any suggestions? At the moment it is "don't use .Net
2.0" which clearly ain't gonna fly long term.
Many thanks.