Hi,

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

Reply via email to