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
