Hashing

  • Thread starter Thread starter Roman
  • Start date Start date
R

Roman

I am using a hastable to associate a TreeNode with a
command object.

hashtable[treeNode] = command;

The problem is that the 'Text' property of the tree node
can change. The hash association will be lost if it does.

For example;

TreeNode treeNode = new TreeNode();
treeNode.Text = "Text1";
hashtable[treeNode] = command;
treeNode.Text = "Text2";
command = hashtable[treeNode];

The last statement returns null since the text property
changed.

What is the best way to make this association independent
of the object's state?
 
I am using a hastable to associate a TreeNode with a
command object.

hashtable[treeNode] = command;

The problem is that the 'Text' property of the tree node
can change. The hash association will be lost if it does.

For example;

TreeNode treeNode = new TreeNode();
treeNode.Text = "Text1";
hashtable[treeNode] = command;
treeNode.Text = "Text2";
command = hashtable[treeNode];

The last statement returns null since the text property
changed.

What is the best way to make this association independent
of the object's state?
Click to expand...

Why not just use the "Tag" property of the treenode to know what it
relates to...

TreeNode treeNode = new TreeNode();
treeNode.Text = "Text1";
treenode.Tag = command;
treeNode.Text = "Text2";
command = (Command)treeNode.Tag;

Note that Tag is of object type, and can hold anything you want. So when
you get the value from Tag, you have to cast it to the appropriate type.
You can find this property on many standard controls.

See the following for a better example (beware word wrap in link):

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpref/html/frlrfsystemwindowsformstreenodeclasstagtopic.asp

Michael Lang
 
I can't. The 'Tag' property is used for other purpose.
How about object references? It would make sense to hash
the reference only if the it remains the same throu out
the life of the object.
 
I can't. The 'Tag' property is used for other purpose.
How about object references? It would make sense to hash
the reference only if the it remains the same throu out
the life of the object.
Click to expand...

Maybe you can use the "Handle" property of the control as your HashTable
key? I think Handle is an immutable property? I don't see any other
immutable unique properties on the Treenode. For some reason Handle is not
always created before it is referenced for the first time? Maybe a limit
on the number of handles available? This may mean it is not a good idea to
force creation of Handles for every node if there is alot of nodes.

If you never move TreeNodes around in the tree, then you could use the
"FullPath" property of the TreeNode as your hash key. But of coarse, it
isn't guaranteed by the framework to be immutable. You would also need to
Add() it to the correct permanent location in the tree before reading the
FullPath property as your Hashtable key.

If you are the one assigning the Tag value to the node, you may want to
rethink how you use the Tag property. Maybe you can create a NodeInfo
class that holds what you currently put in the Tag property, and the
additional command information. Or maybe you can add a property to the
class type that is currently stored in Tag for the Command?

Michael Lang, MCSD
 
Thanks Michael. I did try 'Handel' and it didn't work for
me. It doesn't exist at the time I need it. You are
right, I will have to rethink my use of the 'Tag'. I was
trying to avoid it though.

Roman
 
Why not just derive a new type from TreeNode? Then you can add the Command
as a property of the node. You wouldn't have to maintain the hashTable
(unless you have some other reason for maintaining it), and it wouldn't
matter if you changed the text/position/etc. of the node.

Jon
 
Back
Top