Yes they do have pointers back to their nodes.
The tree nodes are not responsible for creating, or destroying, the objects
associated with them though (this is the most recent iteration). In fact
the intelligence for building the next level of nodes down lives in the
objects, and the whole tree is built incrementally as nodes are opened. The
effect is that the structure is maintained ion the objects, not the tree,
and the objects decide whether to persist after the node is destroyed. So
if the tree goes away, or in our case if the user chooses a new UI, outlook
style, the rebuild is nice and fast.
I wouldn't recommend it for small stuff - but the project it was designed
for benefited a lot.
[Carl Said]
Max,
Do your "Helper" NodeObjects have pointers to their respective TTreeView
nodes? Because I had that sort of arrangement, but then I found that if
RecreateWnd was called on my form for any reason then all the TTreeNodes
in the TTreeView were also recreated, and my NodeObject references to
them were invalidated. How do you get around this?
Specifically, an ancestor form which dealt with form size and
positioning was setting MyForm.Position := poScreenCenter in some
circumstances, which calls RecreateWnd indirectly, so it was somewhat
hard to avoid.
Cheers,
Carl Reynolds Ph: +64-9-4154790
CJN Technologies Ltd. Fax: +64-9-4154791
[EMAIL PROTECTED] DDI: +64-9-4154795
PO Box 302-278, North Harbour, Auckland, New Zealand
12 Piermark Drive, North Harbour Estate, Auckland, NZ
Visit our website at http://www.cjntech.co.nz/
> -----Original Message-----
> From: Max Renshaw-Fox [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, August 24, 1999 8:57 AM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: descending from TTreeView - take 3
>
> 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
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
