Filling a treeview by list

[Edwin Knoppert]

Sigh, today i continued it and stupid me, it was very simple.
The resource i use makes use of an index per item.
So the child item just get's an entry to that ParentID.. simple.

[Michael Mattias]

>Shall we find a way to populate a treeview by text?

"We" have already found ways (plural) to populate treeview controls.

Curiously enough, the exact mechanism is, "application-dependent."

Simplist way I can think of:

FUNCTION main

  REDIM  node(number) AS STRING 
  Node (0) =  "-1|root_text"      ' -1= no parent 
  Node (1) =  "0| text"             ' node (0) is parent
  Node(2)  = "1|child1 "        ' first child of node(1)
  Node(3)  = "1|child2 "        ' next child of node(1), sibling of node(2) 
  Node(4) = "0|Next level one item" 
  Node (5) = "4|First child of node (4) 
 ...
  Node(n)  = "-1|Second root item" 
....
  CALL  InsertArrayOfStringsIntoTreeViewControl (hTv, Node())

Not terribily imaginative, I know, but darned if if would't work

MCM

[Edwin Knoppert]

Sorry boss, overlooked that one

Shall we find a way to populate a treeview by text?
(And skip the objects discussion?)

[Michael Mattias]

> meant storing items in an item.

See post #4 this thread!

[Edwin Knoppert]

Hmm, you mean the parent relationship..?
Not the same.

I meant storing items in an item.
May appear the same, it isn't.

[Edwin Knoppert]

?

I did..

Wazzup?

[Michael Mattias]

I thought it over and come to a simple solution, an item should have an items collection as well.

WHO thought it over?

[Edwin Knoppert]

I thought it over and come to a simple solution, an item should have an items collection as well.

Then.. we could equally discuss how to populate a treeview by text and not discussing the objects anyway, it only makes it more difficult.

The text above is not suitable but i somewhat the idea though.

[Edwin Knoppert]

>Remember: There is no elevator to success, there is only the stairs.

[Michael Mattias]

>You may be right that i need a hierarchy between item, item and items

I am and you do.

The item object itself needs to support either a parent property, its own Items collection, or a level property.

Your kludge ("1, one up, 0 same parent, 1 new parent or so. I don't like it but maybe usable") may in fact be usable in this particular application ... at least until the next time you change your mind about the data structure.

Why don't you just 'bite the bullet' and do it right?

Remember: There is no elevator to success, there is only the stairs.

MCM

[Edwin Knoppert]

Oh, item is just a value As String property
Items is an object with an array holding Item[]
You may be right that i need a hierarchy between item, item and items.
I want to avoid that at all costs, so if i can't i will go a different route.

FYI, the items collection holds several item objects.
It would be acceptable to set some level indicator.

-1, one up, 0 same parent, 1 new parent or so.
I don't like it but maybe usable.

(From my experiance with com you must have at little references as possible, objects must 'flow' independently having a reference from parent to item, not vice versa)

[Michael Mattias]

Show definition of 'item'

If you have an item property of 'parent' it's obviously do-able.

What's not quite so obvious is that it's also do-able by defining an 'items' collection to 'item' itself. This would permit a recursive treatment.

The bottom line is here, "item" is obviously not currently defined in such a fashion to represent multi-level hierarchial data; and the treeview control was designed to support just that.

FWIW, the Data Shaping OLE provider (via ADO) might help; it is what you can use to logically represent recordsets consisting of other recordsets, consisting of other recordsets, consisting of other recordsets, etc. I never tried this, but it sure looks cool in the O'Reilly Book on ADO I bought.

[Edwin Knoppert]

>However, a collection by definition maintains but one hierarchical level of parent-child relationship.
Yes that is the issue however there may be a way to avoid that part.

Thinking...

[Michael Mattias]

Interface definition of 'item' not shown.

However, a collection by definition maintains but one hierarchical level of parent-child relationship.

I would think each 'item' would require a 'parent' property to support the multiple hierarchical relationships you wish to support.

[Edwin Knoppert]

I am populating an items collection (com) and pass that to a procedure to fill the treeview.
Now by ordinary treeview population you are on a level to know which parent item handle to take and so on.
Since this is a collection i have to prepare a substitute.

The items collection (and it's items) is not aware of the treeview.

For example my text list could look like:

"Root"
     "Item1"
     "parent1"
            "Item1"
            "Item2"
            "Item3"
            "Item4"
     "parent2"
            "Item1"
            "Item2"
     "Item2"

And a 2nd root is also allowed.
To prevent odd texts like:

"Root.Parent1.Item1" 
"Root.Parent1.Item2"

i was looking for something more handy.