the best way to remember all of a TreeView's node's collapsed stat

[Guest]

I would like to remember the state of the nodes after the treeview gets
disposed, but not necessarily after the app terminates so I don't need a disk
file. I was thinking about using the tag property, but I am already using it,
so then I though about making a custom treeiew using inheritance and adding
another tag type property? Any clues?
kevin

 

[Mitchell S. Honnert]

I would like to remember the state of the nodes after the treeview gets
disposed, but not necessarily after the app terminates so I don't need a
disk
file. I was thinking about using the tag property, but I am already using
it,
so then I though about making a custom treeiew using inheritance and
adding
another tag type property? Any clues?
kevin

So, what you are looking for is something that can reside in memory that can
store a treeview-like structure along with the collapsed stated of each
node? If so, why not just use the actual TreeView object itself? You
mention the TreeView getting disposed, but if you want to "remember" the
node hierarchy and the collapsed states, why not just copy the instance of
the TreeView in question to a variable that can be accessed by whatever
component which needs to do the "remembering"? You'd not only have the
entire hierarchy and the collapsed states, but *all* of the original
properties that you'd previously set, including your custom Tag values.

- Mitchell S. Honnert

PS: Here's some unsolicited advice. Personally, I avoid using the Tag
property as all costs. You mention extending the TreeView node class using
inheritence and this is exactly what I would do (and have done) when I need
to add a custom property to a node. I don't know if you have other people
which might have to maintain your code, but *you* may know that the Tag
property is (for example) used to store a single character code which
represents the type of node, but someone else wouldn't know just by looking
at the value. But if you extended the TreeView node and added your own
custom, enumerated NodeType property, there'd be no doubt about the purpose
of the property.

 

[Kevin]

So, what you are looking for is something that can reside in memory that can
store a treeview-like structure along with the collapsed stated of each
node? If so, why not just use the actual TreeView object itself? You
mention the TreeView getting disposed, but if you want to "remember" the
node hierarchy and the collapsed states, why not just copy the instance of
the TreeView in question to a variable that can be accessed by whatever
component which needs to do the "remembering"? You'd not only have the
entire hierarchy and the collapsed states, but *all* of the original
properties that you'd previously set, including your custom Tag values.

- Mitchell S. Honnert

PS: Here's some unsolicited advice. Personally, I avoid using the Tag
property as all costs. You mention extending the TreeView node class using
inheritence and this is exactly what I would do (and have done) when I need
to add a custom property to a node. I don't know if you have other people
which might have to maintain your code, but *you* may know that the Tag
property is (for example) used to store a single character code which
represents the type of node, but someone else wouldn't know just by looking
at the value. But if you extended the TreeView node and added your own
custom, enumerated NodeType property, there'd be no doubt about the purpose
of the property.

thanks Mitchell,
I would agree that using the tag property can be confusing, but if it is
used consistently throughout the code and is well documented I don't
really see a problem (it may even be easier than creating a custom
control for just a single addition property) However by iheriting the
treeview class, it become easy to add whatever custom properties are
needed, then using the tag property becomes a hassle.
thanks for your input
kevin