Tina Norris Fields
tinanfields at torchlake.com
Tue Sep 1 08:14:18 CDT 2009
Yes, Max, amongst newbies. I don't have that excuse. <smacks self alongside the head> T Max Wanadoo wrote: >> I still can't believe I was trying to stick a text value into an integer field, >> > > Don't fret, Tina. > > This is a common mistake amongst newbies - ducks and runs. > > max > > > On 9/1/09, Tina Norris Fields <tinanfields at torchlake.com> wrote: > >> Drew, thanks very much for your help and your full explanation. I still >> can't believe I was trying to stick a text value into an integer field, >> but I'm glad you caught that. Your additional explanations are making >> it possible for me to actually use the TreeView control. Thanks again >> and again and again and . . . . . >> T >> >> Drew Wutka wrote: >> >>> No problem. I just sent you the fix off list. Correcting this >>> particular error showed two more issues which I fixed too. >>> >>> Ironically, the issue wasn't technically a treeview issue. However it >>> did relate to how I personally use treeviews (so my example used this >>> method). The nodes of a treeview have to have a unique key. So if you >>> have ten thousand nodes, each node 'key' must have unique to the other >>> 9,999 nodes. With a table, you would use an Autonumber, however, with a >>> treeview branching out, I will use a 'natural' key of sorts, which makes >>> the node key more meaningful (and useful in later code). >>> >>> For example, let's take names: >>> >>> 1 Bob >>> 2 Dave >>> 3 Tina >>> 4 Drew >>> >>> The numbers being the ID (autonumber field) from a table. If we were to >>> make a set of 'root' or top level nodes with these names, I would use >>> the following as the key for that node(without the quotes): 'ID:1' >>> (which would be for the 'Bob' node, 'ID:3' for the Tina node, etc. >>> >>> Now if I want to include children nodes to the top level nodes, let's >>> have a table of pets: >>> >>> 1 Dog(s) >>> 2 Cat(s) >>> 3 Fish >>> 4 Birds >>> 5 Other >>> >>> This data would be recorded in a PersonID PetID table, like this: >>> >>> 1 1 >>> 1 3 >>> 4 2 >>> 4 3 >>> >>> So I would set the children nodes, to use the following Key (without the >>> quotes) 'ID:1:1' or 'ID:4:3' >>> >>> So the data above would look like this in a treeview (and I will put the >>> node keys in parenthesis) >>> >>> Bob (ID:1) >>> --Dog(s)(ID:1:1) >>> --Fish(ID:1:3:) >>> Dave (ID:2) >>> Tina (ID:3) >>> Drew (ID:4) >>> --Cat(s) (ID:4:2) >>> --Fish (ID:4:3) >>> >>> The advantage of using 'natural' keys like this in a node, is that you >>> can interact with a node in a few ways (clicking, dragging, etc.) and >>> when you do so, you will have a node object, WITH a Key. So by making >>> the key relevant to what the node actually represents (while maintaining >>> it's uniqueness) we can actually infer at least two critical pieces of >>> information by Split()ing the Key property into an Array(). One, in >>> this case, we know that if the Ubound of the split is 2, it's a top >>> level node, and thus a Person, if it's 3, then it's a 'pet' node. In >>> VB, where I typically use Treeviews, it's very easy to have dynamic >>> popup menus, so this ability of determining what type of node is being >>> 'right clicked' allows me to popup different 'defined' menus. The other >>> piece of information is the key value to retrieve data (or set data) in >>> the original tables. >>> >>> I didn't put all this in the offlist email, but I figured I'd explain it >>> a bit in case anyone is playing around with Treeviews. >>> >>> Drew >>> >>>