The reason I asked was because I wondered whether you were using some
attribute of the custom node to sort on (vs the text associated with the
node).
The way we achieve node types is to associate a NodeObject with each tree
node (using AddObject/AddChildObject inside our own node management
stuff) - which gives the node a type and holds other information we
require. Each NodeObject also holds a reference to its "OwnerNode" so they
can find each other.
It follows the "Helper Objects" rather than "Class Hierarchies" philosophy,
which imho Delphi is based on - and brought to Java. This seems to simplify
this sort of thing. We then descend from the NodeObject if we want to do
fancy stuff (which incidentally allows the objects to do their own stuff
independently too), or just store information in it if it's a simple tree.
It also allows us to associate images, menu items, as well as behaviours
etc, with each Node Type, stored in the object and doesn't stop the default
tree behaviour, unless we don't surface it.
Max
[phillip Said]
I'm creating an enhanced custom treeview component that allows you to store
descendants from TTreeNode in it. This allows you to set the default node
type, if you wish, to some descendant of TTreeNode and then to either add
nodes normally or specify a node class. For example,
MyNewTreeView.DefaultNodeType := TFancyNode;
MyNewTreeView.Add(AParentNode);
TFancyNode is a descendant from TTreeNode and the DefaultNodeType property
is a metaclass property (ie. class of TTreeNode).
Alternatively, you could call
MyNewTreeView.Add(AParentNode,TFancyNode);
The whole point being that each node knows what it is and can behave
differently if it needs to, rather that the main application code having to
store information in the TTreeNode.Data property and managing the behaviour
itself.
I have it all working fine, but I'm just a bit worried about the sorting
routine for the reason I have already given.
From: "Max Renshaw-Fox" <[EMAIL PROTECTED]> AT tawa on 23/08/99 14:40 ZE12
To: Multiple recipients of list delphi <[EMAIL PROTECTED]> AT
tawa@kauripo@CCMAIL
cc: (bcc: Phillip Middlemiss/NZ Forest Research Institute/NZ)
Subject: RE: [DUG]: descending from TTreeView - take 3
I don't have an immediate answer - but...
What are you trying to achieve? I have a custom tree view, derived from
TCustomTreeView, which is a much-enhanced version of a borrowed base with
it's own node-types etc. It may use a different approach to the same
problem.
Max
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of [EMAIL PROTECTED]
Sent: Monday, 23 August 1999 13:34
To: Multiple recipients of list delphi
Subject: [DUG]: descending from TTreeView - take 3
I'm creating a descendant class from TTreeView that allows you to have
custom node types (ie. descendants form TTreeNode) contained in the Items
of the tree view.
I'm doing this by descending from the TTreeNodes and TTreeView in a similar
way that Cory Osborne described in the Jan/Feb 1999 edition of Visual
Developer.
For those of you who don't get the mag (it's ok but not brilliant), in the
constructor, after calling the inherited create, I clear the Items property
and create my own private TTreeNodes descendant instead. By overriding the
items property I can make it refer to my TTreeNodes descendant instead of
the original. This works quite well because there are only a couple of
places where the TTreeView refers to the private FTreeNodes field and I can
reimplement most of these to refer to Items instead.
The problem I have is with the sorting routine for TTreeView. What Cory
failed to mention in his article (or conveniently ignored) is that it needs
to be re-implemented because it refers to the private FTreeNodes which I
have cleared in the constructor. I don't know why it refers to FTreeNodes
rather than Items when it wants to grab the first node. This wouldn't be a
problem (because I could just reimplement it - hiding the base class
CustomSort) except - and here is my problem - that the CustomSort code
calls Items.ClearCache and ClearCache is a private function of TTreeNodes.
I'm not clear on when the cache needs to be cleared or not for the
TTreeNodes - if it is not too important then I can just happily ignore that
call in my new version of CustomSort. But if it is quite important then I
need to somehow clear the cache.
Does anyone know what the ramifications are of not calling Items.ClearCache
after the treenodes are sorted?
Thanks,
Phil.
[EMAIL PROTECTED]
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
