Great, Max, I hope you have a good weekend. :) BTW, I had an email
asking clarification about what I wrote the other day, so to save
confusion for anyone else listening in (FBI? :) I should point out that
I meant "window" and not "form":
>Now run it, and click button1, button2, button3 and button2 in that
>order. Since after clicking button3 the window is recreated, and all
the
The point being that when the window is recreated, the treeview is
effectively disposed of and rebuilt, so it seems you can't rely on
external pointers to its nodes.
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: Thursday, August 26, 1999 9:58 PM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: descending from TTreeView - take 4
>
> Hi Carl,
>
> Thanks for the code,
> I'll try it with a basic version of our treeview and see what happens.
> Phil
> offered to send some of his code too so I thought I might have a play
> on
> the weekend.
>
> My initial reaction is that you are referencing the node from outside
> the
> tree, whereas for us it's a field of the component - but I haven't
> thought
> that through.
>
> Max
>
> [Carl Said]
>
> 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>
>
> ----------------------------------------------------------------------
> -----
> New Zealand Delphi Users group - Delphi List -
> [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
application/ms-tnef
