Sure, Chip.
They fooled both you and me on that one - it seems. Smile.

I thought the same as you, and tried things like that. It just did not work. That is why, I asked if anyone could give me the instructions. And, honestly, it was that late in the night, that my brain had stopped clarifying anything much, that did not hold the instruction "BED" in it. Smile.

Anyway, why I said they seem to fool both of us, is because the "Parent" property, is not the one you would hook on to. Let me, for those who happen to follow this thread and do not know too much about the treeview object, illustrate things, similar to the test I was performing.

Imagine you have a treeview, where you have three entries in the root: America, Africa and Europe. You expand America, and the first sublevel holds all the different countries in the Americas. You arrow down to USA, and expand it, and end up on a new tree branch, holding all the 50 states of USA. You could of course, have expanded this treeview into local regions, cities and parts of the city - even down to individual streets and houses. But I never did that much of expanding just for my test. Anyway, you now are in the list of the 50 states, and you arrow down to - well, let's say California, just to have the sunny side of it all.

My question was, how to reverse my way through the different branches, that had taken me this far. And, I did just like you Chip, figure the Parent object would have done so. But no. Focusing California, and then calling Parent, did only return "America" - that is, the Root branch. This was steadily repeating itself, all the time, and frustrated me, even to the point of me asking for assistance.

What we really needed to hook on to, showed up to be the property called ParentItem. This property, gives you the node, immediately above the level you are. So, in my above example, selecting California, calling ParentItem, would give me "USA". Selecting USA, calling ParentItem, would in turn give me America, which would be the Parent.

So to all new ones that would happen to read this, Parent - gives you the Root node for the tree-lim. ParentItem, gives you the node that is the exact parent, or immediate parent, of your current selection. Quite frustrating first hand, and I could have thought of a couple of better names to have assigned to the properties, that would have lead to less confusion.

But anyway, once I got this one straightened out, it was easy enough to follow my way back to the Root node of any selected item. And, that is what I really need to do, right at this point in my project.

From here, you are totally correct Chip, and I was pretty much aware of
that. We need a loop, that keeps taking us backward one step at a time. Below, I will paste the function for the job, in case that will bring anyone else a step or two further in understanding the secrets of a treeview, and how you can play around with the stuff. Smile. Please note, that this function was put together as part of a testing routine, so the way it stands, it will simply just return the text string, holding each node.name - separating them with a comma. This can of course be changed, and you could perform different actions, on each step. For instance, if you Check the checkbox for California, and you then want to force all the branches that lead to California, to be checked - you could do that, as part of the process. In my function, this is done by the line that is marked with a Comment of X. Remove the apostrophe and the X, and the function will check the boxes all the way back to the root-node. All of this, just for illustrative purposes, but hopefully will serve as idea-trigging teaching for someone.

Function GetFullTreeLim( TreeLim)
' Make a local work-copy of the incoming TreeLim object:
Dim TLItem: Set TLItem = TreeLim
' Start out, by retrieving the Text of the currently selected item:
Dim TLTxt: TLTxt = TLItem.Text

' We now will work our way up the tree, until there is no more branches.
' That is, until we have reached the root-node:
Do Until TLItem Is Nothing
' Here, we hook on to the immediate parent of the current node:
 Set TLItem = TLItem.ParentItem
' We only want things to happen, long as we got hold of an immediate parent:
 If Not TLItem Is Nothing Then
' Grab the Text of the retrieved Parent, and insert it at the beginning of our Full-TreeLim-string:
  TLTxt = TLItem.Text &"," &TLTxt
'X   TLItem.Checked = TVCChecked
 End If 'Not TLItem Is Nothing.
' The loop will keep on, till there is no more parent to be retrieved. That is when, we have reached the root-node:
Loop 'Until TLItem Is Nothing.

' Finally, let's return the Full-TreeLim-string:
GetFullTreeLim = TLTxt
End Function 'GetFullTreeLim.

In your program, you now could do something like this:

If CurrentItem.Checked = TVCChecked Then Speak GetFullTreeLim( CurrentItem) &" has been selected."

Where CurrentItem, would be an object, pointing to the item of the treeview, that currently is focused (or selected, as they like to name it).

Thanks again, for all assistance. Just thought to share my experience, and rectify the confusion around the Parent property.


----- Original Message ----- From: "Chip Orange" <[email protected]>
To: <[email protected]>
Sent: Friday, April 12, 2013 3:12 PM
Subject: RE: Treeview Questions - Still attempting to learn :)


Hi David,

Well, you'd have to be sure you weren't on the top level, so you would test to make sure the paren is not nothing, and if not, then the parent points to another treeviewItem object; so to see the text of the parent you would use:
myItem.parent.text

hth,

Chip


-----Original Message-----
From: David [mailto:[email protected]]
Sent: Thursday, April 11, 2013 9:22 PM
To: [email protected]
Subject: Re: Treeview Questions - Still attempting to learn :)

Thanks, Chip.
The Checked property, was the one I was looking for. I might just have
overlooked it. Was really reading that much back and forth in the Reference,

and then it is easy to overlook something, or not grasp the full meaning of
each detail. Thanks again. And, as I have shown in another message, I did
solve the Iteration problem. So, we are getting there, slowly but steadily.
:)

Now, if someone could just give me one tiny bit of help extra, I would be
set for some more experimenting.

Imagine, that I find an item that is checked. It happens to be the 5th item
on level 3, found under the 2nd item of level 2, and the 7th item on level
1. But, when I find it, I might not know all of that.

I guess, I somehow could follow the Parent properties, and reverse my way up

the tree, from the found item. But, what would be the exact instruction to
use, if I have the item (called MyItem), and I want to get the Text field of

its parent? Hope that one made sense. It is late in the day, and my brain
doesn't work smoothly any longer. HAHA.

Thanks again,


----- Original Message ----- From: "Chip Orange" <[email protected]>
To: <[email protected]>
Sent: Friday, April 12, 2013 2:19 AM
Subject: RE: Treeview Questions - Still attempting to learn :)


Hi David,



I'm sorry I didn't go into the advanced treeview issues when I was doing
the
scripting tutorials; looks like I only covered the basics.  I'll try to
put
together another tutorial to cover all the advanced treeview issues, and
answer your questions as best as I can for now:





1. What is the exact benefit of the Text, as compared to the Data, field
in a treeview item.



As you suspect, the data property is only there for your convenience.
Sometimes, when creating the text, there is some record in a dictionary
associated with the text, and sometimes you could store the key to it in
the
data property, thus saving you the trouble of having to look up the text
to
figure that out.  If some of your items are one type of thing, and some
the
other, then the data property is also quick and easy to use for enabling
or
disabling other controls as various treeview items are highlighted (it's a
lot quicker to just examine the data item when a treeview item is
highlighted than it is to look up the text somewhere to figure that out).



2. The treeview I am building, has checkboxes, which the user can check
for each item on the tree. I have searched the Reference manual, but not
sure if I have overlooked anything. From what I can see, there is no way
in
>determining whether a treeview Item has been checked or not. I see the
Selected feature, but from what my testing leads me to understand, this
simply let's me know when an item has focus (that is, when the cursor is
[>]
placed on the item, the Selected feature will be set).

Actually, the  treeview control object itself does have a selected
property
which does what you say: it returns the treeviewItem object which is
currently highlighted.  The treeviewItem object however however has a
checked property (if you're using checkboxes), or a selected property if
not, and they return an indication as to whether that particular item is
either checked or selected.





>Is it correct, that there is no build-in feature, that would "fire",
>when
a treeview item has been checked or unchecked?

I'm sure some event happens; it looks to me like it is the treeviewClicked
event which would happen, but there's also a  treeviewSelectionChange
event
which could be it (it's not always clear when they speak of selection
whether they mean a multi-selection control is having one of its items
selected or unselected, or if they mean the focused/highlighted item is
changing).





[>] >3. Does anyone have a simple quick iteration routine, for "rushing"
through a whole treeview, including all its branches and leaves. My
treeview, might hold as much as 9 sublevels, in addition to the root. And
it
might hold [>] >different amounts of entries on each branch or sublevel. I guess the best would be to use some For...Next loops, and somehow retrieve
the Count property for each branch. But I have run my head into the wall,
as
to how to get [>] >through absolutely all the possible items on the tree.
I
guess, that is the one way to go, when iterating the different items, or
am
I totally lost in such an approach? Say for instance, the user would have
been given the chance [>] >of searching for a given text, which would be
the
Text property of an item on the tree. I then guess, I will have to iterate
all the current items on the tree, looking out for that particular text.
And, that is why, I wondered if there [>] >was a simple routine, that
would
perform such a "run-through", with relatively few lines of coding.



I don't have one handy, and you're right that you will have to do this for

a
search.  It is possible to go to app central (the web version), go to the
appGet app, and get an older version (there's a link to let you see
earlier
versions of an app).  Before they began encrypting it, appGet was
available
in the clear, and it uses a treeview control, and it has a "find" feature,
so it must work through the treeview as you are wanting to do.

[>]

When you download it, to save you from having to install it to get to the
source code, you can change the file extension from .wepm to .cab, then
you
can use some unpack utility (such as winRar), which will unpack it into a
directory.











Reply via email to