I have a TreeView that displays a very big amount of complex
hierarchical data where the elements in the tree represent all sorts of
different datatypes. These datatyps again store one or more typed lists
of other datatypes wich will appear as childitems in the treeview. E.g.
the datatype "Building" has childcollections such as "Flats" or
"Inhabitants", the datatype "Flat" again has child collections such as
"Rooms" ... you get the idea. Each element has a unique name and each
datatype has a unique icon.

What is the best practise to implement such thing so that adding,
(re)moving, finding, changing elements (both by using the UI or some
internal logic that operates on the data) is fast and the code is easy
to maintain. Should I introduce speacial treelistviewitem derived types
for each "datatype" or should I use treelistviewitem directly and just
attach the datatype instance as the treelistviewitem.tag ? Should each
treelistviewitem contain the logic to update its childitems in the
treeview or should an extrernal method read the whole data and build
the treeview out of that? How can I identify a item in a fast way (i.e.
without having to iterate through the whole tree)? Should I use
Databinding ? If I introduce new datatypes at a later time I would want
to have to touch/adjust too much code.

I would be thankful for a simple example that shows off best practices
in this regard. Or maybe there is a book on Windows Forms that has this?

On 18/12/2006 in message
<(E-Mail Removed)> Robert Ludig wrote:

>I would be thankful for a simple example that shows off best practices
>in this regard. Or maybe there is a book on Windows Forms that has this?

I am not suggesting this is best practice but I have just done something
similar where a TreeNode could be showing different types of data. I wrote
a small class as follows:

class cHelpTagData
{
private RecordTypes m_RecordType = RecordTypes.None;
private string m_Identifier = "";

public enum RecordTypes
{
None,
RootNode,
CategoryNode,
RecordNode
}

etc...

I did this because:

1) I was concerned about the memory implications of loading each Tag with
an instance of another class (some quite big).
2) Each Tag has only 1 type of data attached to it, otherwise I found I
was trying first to identify the TreeNode so I could work out what the Tag
contained and then casting the Tag to that type.

When adding each TreeNode I create an instance of cHelpTagData, set its
variables up and point the Tag to it.

Now when a Tree Node is selected I know the Tag will contain an instance
of a cHelpTagData so I can cast to that. I then check what type of record
it is from RecordTypes and then look the record up based on the Identifier
- sometimes as a string and sometimes cast to an int.

I does work, but if there are better ways of doing it I would be
interested too :-)

--
Jeff Gaines
Damerham Hampshire UK

If you are working on a commercial project then you might want to take
a look at Infralution's Virtual Tree control. It has a very flexible
databinding mechanism that solves many of the issues you discuss. It
implements virtual (on-demand) loading of data from the ground up which
means that it loads extremely quickly even with huge data sets and
doesn't consume large amounts of memory. Implementing this sort of
stuff is quite complex and very time consuming. You'll save the
purchase cost in a couple of hours. You can get more information and
download an evaluation from www.infralution.com/virtualtree.html

Regards
Grant Frisken
Infralution


Robert Ludig wrote:
> I have a TreeView that displays a very big amount of complex
> hierarchical data where the elements in the tree represent all sorts of
> different datatypes. These datatyps again store one or more typed lists
> of other datatypes wich will appear as childitems in the treeview. E.g.
> the datatype "Building" has childcollections such as "Flats" or
> "Inhabitants", the datatype "Flat" again has child collections such as
> "Rooms" ... you get the idea. Each element has a unique name and each
> datatype has a unique icon.
>
> What is the best practise to implement such thing so that adding,
> (re)moving, finding, changing elements (both by using the UI or some
> internal logic that operates on the data) is fast and the code is easy
> to maintain. Should I introduce speacial treelistviewitem derived types
> for each "datatype" or should I use treelistviewitem directly and just
> attach the datatype instance as the treelistviewitem.tag ? Should each
> treelistviewitem contain the logic to update its childitems in the
> treeview or should an extrernal method read the whole data and build
> the treeview out of that? How can I identify a item in a fast way (i.e.
> without having to iterate through the whole tree)? Should I use
> Databinding ? If I introduce new datatypes at a later time I would want
> to have to touch/adjust too much code.
>
> I would be thankful for a simple example that shows off best practices
> in this regard. Or maybe there is a book on Windows Forms that has this?

Your approach seem to have one major disatvantage, I think: it is
rather expensive to find a certain element with a certaint identifier
in the tree (for example to update the treeviewitem because the icon or
the text changed). AFAIK you have to iterate throught he whole tree to
find it.

On 18 Dez., 17:07, "Jeff Gaines" <whitedra...@newsgroups.nospam> wrote:
> On 18/12/2006 in message
>
> <1166449962.297334.244...@73g2000cwn.googlegroups.com> Robert Ludig wrote:
> >I would be thankful for a simple example that shows off best practices
> >in this regard. Or maybe there is a book on Windows Forms that has this?I am not suggesting this is best practice but I have just done something
> similar where a TreeNode could be showing different types of data. I wrote
> a small class as follows:
>
> class cHelpTagData
> {
> private RecordTypes m_RecordType = RecordTypes.None;
> private string m_Identifier = "";
>
> public enum RecordTypes
> {
> None,
> RootNode,
> CategoryNode,
> RecordNode
> }
>
> etc...
>
> I did this because:
>
> 1) I was concerned about the memory implications of loading each Tag with
> an instance of another class (some quite big).
> 2) Each Tag has only 1 type of data attached to it, otherwise I found I
> was trying first to identify the TreeNode so I could work out what the Tag
> contained and then casting the Tag to that type.
>
> When adding each TreeNode I create an instance of cHelpTagData, set its
> variables up and point the Tag to it.
>
> Now when a Tree Node is selected I know the Tag will contain an instance
> of a cHelpTagData so I can cast to that. I then check what type of record
> it is from RecordTypes and then look the record up based on the Identifier
> - sometimes as a string and sometimes cast to an int.
>
> I does work, but if there are better ways of doing it I would be
> interested too :-)
>
> --
> Jeff Gaines
> Damerham Hampshire UK

On 20/12/2006 in message
<(E-Mail Removed)> Robert Ludig wrote:

>Your approach seem to have one major disatvantage, I think: it is
>rather expensive to find a certain element with a certaint identifier
>in the tree (for example to update the treeviewitem because the icon or
>the text changed). AFAIK you have to iterate throught he whole tree to
>find it.

Yes I agree entirely - it works well if you click a node but finding a
node from its text or fullpath is a pain.
I have seen some apps where a HashTable is kept linking nodes to some form
of identifier. It works reasonably well for a tree that is fully populated
at the outset - but I only populate nodes when they are expanded.
I have a technique for getting to a node from a string, but you're right
it can involve iterating through lots of nodes to find the one you want.
I'm not sure there is a real answer for this that will work in all cases,
but I wouldn't mind being proved wrong - a solution would make a good
Christmas present :-)

--
Jeff Gaines
Damerham Hampshire UK