Is a tree control appropriate for this application?

[tdurand]

I've been playing with the idea of designing a Visio-like application in LabView.  (See my post from a year ago or so...  Playing with the idea for a long time, I guess...)

My first approach was to use a flat array to hold all the objects that would be drawn.  To draw them, I treated the flat array like a tree, adding new objects to the end, and traversing it carefully when drawing a page.  (This page has this "group" object, which contains these other objects...)

Would the tree control be appropriate for this type of application?  I don't necessarily need to show the user the tree.  I would use it primarily for behind-the-scenes bookkeeping.  Or is the tree primarily a GUI-oriented control?

Secondly, how can I relate items in the tree with the information I need to display on the canvas?  For example, If I come across an object titled "panel\group_2\square_5" -- well, how do I use that to access all the properties of "square_5" (size, color, etc.)?  When the tree is used for representing a directory structure, a tag named "c:\dir2\file5" is very convenient -- the computer knows what to do with that, and no massaging is needed.  But what good is "panel\group_2\square_5"?  Do I then perform a string "match pattern" of an array of tags, and use that index to the flat array of objects?  Ugh, that doesn't seem very efficient.

Thanks!
Tom

[nathand]

Someone who's used OOP will undoubtedly jump in here and tell you this is an ideal case for OO, because they can easily have children and you can represent your tree structure in a logical fashion.  Another approach would be to use variants.  Since variants can have named attributes, and attributes are themselves variants, you can easily construct a tree representing all your objects.  Each object might also have a "properties" attribute allowing you to access all the relevant properties of, for example, your square.