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

"kevin" <(E-Mail Removed)> wrote in message
news:2C7C46C1-F86E-4785-A710-(E-Mail Removed)...
>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.

Mitchell S. Honnert wrote:
> "kevin" <(E-Mail Removed)> wrote in message
> news:2C7C46C1-F86E-4785-A710-(E-Mail Removed)...
>
>>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.
>
>
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