[Solved]Is it possible to store non visible data to a node in TTreeView

[Knipfty]

Hi KpjComp,

I am hoping that it helps others.  And since it took some effort to work thru this, I figured others might benefit by it.

As for you latest suggestion its done.

I used   result := Node As TMyTreeNode;

Tested and works!

Many Thanks

Knipfty

[bylaardt]

and why you don't use "data"?

look this sample:

Code: [Select]

type

  TNivelRecord = record
    Empresa, Plano, Codigo: int64;
    Acesso: byte;
    Tipo: integer;
    EmNivel: boolean;
  end;
  TNivelPointer = ^TNivelRecord;

(...)

procedure Tnivel.MenuAcessDataNodeClick(Sender: TObject);
var
  Registro: TNivelPointer;
 
begin
    Registro := TreeView.Selected.Data;
   Showmessage(inttostr(Registro^.Empresa));
   Showmessage(inttostr(Registro^.plano));
   Showmessage(inttostr(Registro^.codigo));
end;

procedure Tnivel.NewNode(Node: TTreeNode);
var
  Registro: TNivelPointer;
  Node1: TTreeNode;
begin
    Reg := node.Data;
    New(Registro);
    Registro^.Empresa := 1; {or a integer number, var, const...}
    Registro^.Plano := 2;
    Registro^.Codigo := 5;
    Registro^.Acesso :=4;
    Registro^.EmNivel := true;
    Registro^.Tipo := 65;
    Node1 := TreeView.Items.AddChildObject(node,'New register caption', Registro);
    Node1.ImageIndex := 0;
    Node1.SelectedIndex := 1;
end;

procedure Tnivel.TreeViewDeletion(Sender: TObject; Node: TTreeNode);
begin
  freemem(node.Data, sizeof(TNivelRecord));
end;

Important: freemem to avoid memory leaks!

[Knipfty]

Hi bylaardt,

Great question.

1. Your solution, which to me looks fine, requires the programmer, me, to remember to free.  My application constantly, clears the Items and rebuilds the treeview.  So I would need to add a step to free the memory addresses.  Not the end of the world, but more programming.

2. MY 1st solution was creating a TStringList, which contained the data that i pointed to via Data^.  That had its share of problems, including SEGSIGV errors.

3. The solution outlined at the end has several advantages.

• TreeView manages the TreeNodes.  So beyond adding the event handler, its hands off.  Nothing to Free up
• By extending the TreeNode, I am also not working with pointers but with the actual TreeNode.  There is a little effort to make sure I type cast correctly.

I hope that answers your question.

Knipfty

[KpjComp]

There's also a possible performance/memory advantage.

Using the Data property requires 2 allocations & 2 free's for every node, extending the node type means the tree will be doing 1 alloc/free for every node.

Also I'd say it's more OOP, eg. if you wanted to some extra functions adding to the TmyTreeNode, self will be the actual TreeNode.  IOW: Data is kept in a more OOP concept.

[bylaardt]

Ok, OPP or not, i see any solution as a valid thing, but make a new property to a standard component to do the same, isn't reinventing the wheel?
and you need the freemem function only in the OnDeletion event to prevent memory leaks.
I follow the prerogative of "no create more components to avoid recompile the lazarus".

However, i like yor OPP the solution. I will think better about it ever time i use standart properties again.

[KpjComp]

I follow the prerogative of "no create more components to avoid recompile the lazarus".

Hi bylaardt.

There is no recompile of Lazarus needed.  It's just a runtime feature to add extra properties to the standard TTreeNode.  There is certainly no problem in using the Data property too, that's what it was created for.  It's really down to personal preference.

[Knipfty]

Hi bylaardt,

If you take a look at my summary of the solution on the previous page, I noted an event handler:

Code: [Select]

procedure TTreeListForm.HMLTVCreateNodeClass(Sender: TCustomTreeView;
  var NodeClass: TTreeNodeClass);
begin
  NodeClass := TMyTreeNode
end;
With this one call, it substitutes MyTreeNode in place of TreeNode.  MyTreeNode is exactly the same as TreeNode with two extra properties.  From my testing and what KpjComp tells me, there is no extra overhead in doing this.

And as you have already demonstrated, the solution based on creating a new data object to be pointed to by Data^, does add extra processing time and remembering to destroy the data items later on.

You are correct that that is what Data^ is there for.  But I see no reason not to do what KpjComp proposed and helped me out with.  And in fact there is a certain elegance to this solution.  It is after all, how OOP is supposed to work.  Take what others have done and extend it.

[bylaardt]

Ok! I appreciate this!
How i said I: "I will think better".