asked on

Gurus > Efficiency Issues. TComponent vs Tpersistent

Ok... so I have this treeview... and it might have a LOT of nodes. Say 2000 or so.. and there are several trees.

Is there any appreciable reason why my Node.Data object cannot be a Tcomponent? It's already a Tpersistent, but I'd like to be able to stream the suckers and that's not so simple with a Tpersistent. I only know how to do it with a component using Write/Read component. If someone can tell me how to do it with a Tpersistent, I would be extremely grateful, but in the meantime, is there any reason why a component shouldn't be used as the Data object?

ASKER CERTIFIED SOLUTION

swift99

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Respektable

ASKER

Thanks swift. Unsure of how to proceed, I decided to go with a Tpersistent. What I built is pretty cool. It's a "Set Manager" that stores a collection of "TSetMembers" and TsetNames" Each collection can be streamed via a dummy carrier component as one big stream.... or to separate streams stored in Plasmatech's Structured Storage Library. This lets me save or read the properties of a single collection item. (I wanted to be able to save a single node's data.. without saving the entire collection).
Using a Tcompnent would have saved some steps, to be sure, but I will take comfort in knowing that each node record is not carrying the overhead of unneeded properties. Was it worth a day's coding? Probably not.. but it's done... lol. Have some points on me!

Gurus &gt; Efficiency Issues. TComponent vs Tpersistent

Gurus > Efficiency Issues. TComponent vs Tpersistent