Hi Max,
I haven't had an excuse to revisit that old code, and I imagine there
are many things I could improve on now - certainly, following this
thread has given me ideas. But the specific problem I had is easily
reproduced:
Add a treeview and three buttons to a form. Put in the following code:
// for TForm1
private
MyNode: TTreeNode;
end;
// the buttons
procedure TForm1.Button1Click(Sender: TObject);
begin
MyNode := TreeView1.Items.Add(nil, 'blah');
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
ShowMessage(MyNode.Text);
end;
procedure TForm1.Button3Click(Sender: TObject);
begin
Form1.Position := poScreenCenter; // Calls RecreateWnd
end;
Now run it, and click button1, button2, button3 and button2 in that
order. Since after clicking button3 the form is recreated, and all the
tree nodes are recreated, MyNode becomes a dangling pointer. What
you'll get when you click button2 the second time is anyone's guess.
I never spent the time to really get around the problem, either. I just
changed the code that was setting Position := poScreenCenter to set Left
and Top instead. This was mainly because my other object structure
didn't hold information about the way the tree was put together, and I
was pressed for time (I know, any excuse will do :). But if I duplicate
the structure of the treeview myself, isn't that just wasted effort?
Still, I may have no choice if I want to do it properly, and then I also
need to pick up when the window is recreated in order to refresh all my
node pointers. Not very pleasant. I can't help but think there must be
a better solution.
Unfortunately, Phil's solution isn't a solution if he needs to access
something privately declared. I think he'll continually be fighting to
set FCachedNode correctly. Until he gives in and copies the entire
TreeView code to use as a basis for his own TreeView (yuck). Sorry
Phil, not what you wanted to hear was it.
Max, if you've avoided this problem without creating your own
grass-roots treeview, how did you do it?
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: Wednesday, August 25, 1999 3:49 PM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: descending from TTreeView - take 4
>
> On re-reading this...
>
> In the original version the tree nodes _were_ responsible for
> creating, and
> destroying, the helper objects - afaik there were(are) no problems
> with
> RecreateWnd invalidating object references even though it is currently
> in
> use in half a dozen fairly significant production systems. The new
> version
> is different, and more generic.
>
> Max
>
>
> [Max Said]
>
> 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
>
<snip>
application/ms-tnef
