Infralution Support

[JuhaManninen]

Hi,

You may be little biased on this topic but how would you compare your component with the VirtualTreeView component from SoftGems (by Mike Lischke) for Borland Delphi?
Are there any fundamental differences in the data model?
How about performance? SoftGems's VirtualTreeView is extremely fast!

Does your component internally have a tree data structure separated from the view, or are they together like in SoftGems's component? It has all the visual properties in every node.
Often I need just to scan the tree's data in a program without any UI. Then it would be nice to have those 2 things separated.
"Model - View" or how is it called ...


Regards,
Juha Manninen

[Infralution]

[JuhaManninen]

Thanks for the quick answer.

And yes, I understand that the Virtual Tree doesn't know anything about the actual data of my application, that's why it is called "virtual".
When I asked about "tree data structure" I actually meant the meta-data in each node that builds the tree, namely properties like Parent, Previous Sibling, Next Sibling and so on.
Once the virtual tree component maintains the tree structure using those internal variables, then it is possible to browse the data about like this:

Node := Tree.GetFirst;
while Node <> Nil do
begin
...
... Get data from Node and process it ...
...
Node := Tree.GetNext(Node); // or GetNextSibling...
end;

At this point there are event handlers defined to fetch the application data and it is not relevant here. It comes "automatically".

However, a node in SoftGems's VirtualTreeView not only has meta-data needed for tree structure, but it also defines its visual appearence. This is how a node is defined:

TVirtualNode = packed record
Index, // index of node with regard to its parent
ChildCount: Cardinal; // number of child nodes
NodeHeight: Word; // height in pixels
States: TVirtualNodeStates; // states describing various properties of the node (expanded, initialized etc.)
Align: Byte; // line/button alignment
CheckState: TCheckState; // indicates the current check state (e.g. checked, pressed etc.)
CheckType: TCheckType; // indicates which check type shall be used for this node
Dummy: Byte; // dummy value to fill DWORD boundary
TotalCount, // sum of this node, all of its child nodes and their child nodes etc.
TotalHeight: Cardinal; // height in pixels this node covers on screen including the height of all of its
// children
Parent, // reference to the node's parent (for the root this contains the treeview)
PrevSibling, // link to the node's previous sibling or nil if it is the first node
NextSibling, // link to the node's next sibling or nil if it is the last node
FirstChild, // link to the node's first child...
LastChild: PVirtualNode; // link to the node's last child...
Data: record end; // this is a placeholder, each node gets extra data determined by NodeDataSize
end;


For example "NodeHeight" and "CheckState" are purely visual properties.

The problem comes when you try to use the component as a part in a bigger data model. For example I have made an in-memory tree DB, where the application data comes from optimized flat tables and VirtualTreeView maintains the tree structure using clever (!) indexed link-fields. That is purely data-oriented.
Then I had to make some clumsy Viewer-classes which pretend to take care of viewing the data, while it is actually done by the same tree component already embedded in my tree class.

So, I would need the VirtualTreeView to be splitted into 2 components,
TreeDATA and TreeVIEW.


Regards,
Juha Manninen

[Infralution]

Virtual Tree represents the current tree hierarchy using Row objects. These are separate to the GUI objects (RowWidgets) used to display the tree. A Row has a Parent and ChildRows and an Item property which returns the underlying application data object associated with the Row. The Row object maintains the state of the tree (is a node expanded, selected etc) but does not perform the drawing.

Virtual Tree does not create Row objects for every object in your data model. It only creates the Row objects required to display the currently displayed data. They are transient objects - they change as the tree is expanded etc. So while Row objects are useful if you want to traverse the currently displayed tree they are not good for traversing your data model. For instance unexpanded Rows don't have child rows.

Virtual Tree is really virtual - if you want to traverse your data heirarchy you need to use your data classes to do this. If your data originates in flat tables you may want to create separate hierarchical data class that represent the tree hierarchy and enable you to navigate it easily. This could be as simple as a class with an interface like:

[JuhaManninen]

Thanks for the answer.
I had one week holiday and only now got chance to read it.

Regards,
Juha Manninen