I agree that the the tree building logic should be seperate from the other
information logic. That's logical :-). The tree view is really just a view
into the data. My intention is to create descendant tree nodes (from my new
generic TTreeview, TTreenodes and TTreenode classes) that know what kind of
helper-objects/data-storage that they are working with. The actual building
of the tree is a separate task. The main reason I am doing this is so that
I can free up some of events and properties that I would otherwise have to
use up (such as OnChange, and the NodeObject) when using the treeview. The
actual end-user components I am building is a suite of components that work
with a relational database. I needed to have a treeview component that
automatically knew how to fill itself from my MetaTable component but still
had all the normal events and procedures available for someone else who
will use the suite. I wanted to have the treeview to fill itself and to
know how to manage additions etc. Making the generic treeview that allowed
you to store descendents of TTreenode, and then descending from that to
create the specific treeview, seemed to be the best approach.
Phil.
[Max (also known as Mark by those with the font size set too small to read
properly) said]
What we did was to do stuff in the "OnExpanding" (from memory) node event
which went away and got info from the object hierarchy, which had all
the encapsulation inheritance and polymorphism stuff in it (I can say
them even if I can't smell them).
As you say, it didn't avoid the hierarchy (that wasn't the intention) but
it did avoid mixing the tree-building logic with the other information
logic, which we decided was a clean separation of roles - and we didn't
have to worry about breaking any of the tree code, including Sort. We
didn't need to create descendant nodes or anything, all we did was give it
the ability to build each successive level based on the helper object it
was associated with in the external hierarchy.
(BTW its Max not Mark)
Max
[Phil Said]
Using helper objects doesn't mean, though, that you need to avoid
inheritance. In your case you could create descendant nodes for no other
reason than to store a helper object (and maybe carry out a few maintenance
operations). You could create a new custom node for each kind of helper
object, or (as you hinted at in the e-mail you sent me privately) use
interfaces to work with a standard set of methods on any kind of object - a
much cleaner solution in my opinion.
The components I have made by descending from TCustomTreeView, TTreeNodes,
and TTreeNode are generic. They have simply adapted the TTreeview to allow
any kind of node(s) to be stored inside it as long as they are descendants
of TTreeNode. In your case, it would be useful for no other reason than to
allow you to store a node that new how to talk to your helper objects. This
may be trivial but infact it allows a significant code-reuse benefit the
next time you have to do a similar treeview on a different form or with
different data because all the code for adding and talking to the helper
objects is encapsulated in your TTreeNode descendant ("encapsulated" is a
good OOD word :-). And you still have the NodeObject property to play with.
Now if only someone was able to answer my first query about the
Items.clearcache call in the CustomSort routine :-(
Phil.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
