That's the problem - I already do what you suggest.

I use Add(Key, Text) in most cases and the value it is complaining about is specified in the Text parameter - never the Key parameter.
(Only one item is added at a time so I dont use BeginUpdate/EndUpdate here)

In another place I use Add() and then specify the Text - but not the Key - so the key defaults to something like 'Node34'.
(This is the case that adds multiple nodes so I do use BeginUpdate/EndUpdate here)

In addition, when I use the Add(Key,Text) function it is already surrounded by a test to ensure that the key does not already exist. (as in your example)

That is why I'm asking if there is any way that it can get the 2 mixed up - or if there is some case in which it uses the Text as a Key if I do not specifically set a key.

One additional point - I only saw this problem one time on WindowsXP and that was back in the early development when I probably didn't check for the existance of the key first.
My test engineer tells me it now happens frequently on Windows7 but he has never seen the problem on XP... so the same code seems to work differently on Win7.  
I know you have a different 'look' when I set it to Windows7 so do you do anything else differently?

Thanks
Mike

Hi Mike,

mikedempsey said:

If I use the Add(key, text) function and specify the key as an empty string is that still treated as having no key? (or would that be classed as a key with the value of a zero length string?)
I'm asking because I 'cleaned up' the code and started to do it that way. It works exactly the same for me in both cases - ie. it works fine, but I have not yet sent the new version to the tester who is seeing the Red X problem.

I'm not sure off the top of my head, but this is very easy to test. Put a new tree control on a form and try to add two nodes with empty strings as keys. I tried this out with empty strings and with nulls and it works fine for me. So it appears that null or empty string are both treated as a null key and either one is fine.

mikedempsey said:

The application does use worker threads to do some things such as executing a database query, but all interaction with this Tree is done from the main thread.

Every indication here is that this is a threading issue, so I would be very suspicious of any code in your application that is using threading.The fact that I suspected a threading issue before I even knew your application was using threads and then it turned out that you actually are using threads seems to me to be a pretty strong indication that threads are the problem.

If you were adding nodes to the tree that actually had duplicate keys, then the exception would not be occurring when the tree paints, it would happen when you tried to add the node.

Using a worker thread to retrieve data from a database can easily cause problems that are very hard to detect. Threading issues are notorious difficult to track down, because the actual exception you get occurs long after the real problem happened and often appears to be completely unrelated to the actual problem.

Are you using DataBinding in your application at all? Are you binding the tree or any of it's nodes? Are you populating the tree from this data that you retrieved on the worker thread?

None of the above.

The data that is added to this tree is simply the type of the database connection. That type string is determined when the user connects to the database, which is all done in the main thread.

If the user expands this node the child data is read directly from a file - again on the main thread.

Depending on the users settings, the data loaded into the OTHER tree may be loaded asyncronously and that might be occuring at the time that this tree is loaded. (although the tester tells me not)

Just in case the async loading of the other tree is somehow interfering with the simple load (of 2 'known' nodes) into this tree I will switch the order to load this tree before calling the function to load the other tree.

I'll let you know if that helps. (May be a weekk or so)

Thanks
Mike

Hi,

I just wanted to know if you were able to solve your issue based on Mike's suggestions or you still need help? Just let me know.

Thank you.

No luck so far.

I replaced all the code where I used Nodes.Add() followed by node.Text=xxx with Nodes.Add("", xxx).

Logically it should make no difference but I thought maybe the use of the empty constrctor (which I had never used in the previous version) might somehow be causing the problem.

With that new build my tester is no longer able to replicate the problem on Windows7 but he can now replicate it on XP. Exactly the opposite of the previous build.

The real problem is that the 'Key' it is reporting as a duplicate is NEVER used as a key. It is however used as the Text of a node - and it may be used as the Text of more than one node at times.

 I have already sent a demo showing a regression in the 11.2 version of the Tree control related to disposed Tooltips and it is looking very much like this is another regression in the creation/use of the HashTable used in your Paint event. Could you check if anything has changed in reguard to this hash table between 10.3 and 11.2.

As far as removing threading from the application; that's just not possible. This has been a multi threaded application for a long time. (and we did not have these problems in earlier versions)
Although a worker thread is used to fetch data that will later be loaded into a Tree control [but not the Tree that is crashing] even that data is loaded in the main thread. The tree controls are not referenced from within any worker thread - only from the main thread - so I don't see how threading can have any impact here. 

b

Hello,

If you are able to isolate this issue in a small sample and give me the exactly steps (and other details like Operating System and etc.), which I should follow in order to reproduce this issue on my machine, I will be glad to investigate this further for you. Without  sample, we only could make guesses, what could be the reason for this issue.

I ma waiting for your feedback.

Hello ,

The state of this issue is resolved it should be included in the upcoming Service release.

Thank you for using Infragistics Components.

Hi,

Has this issue been resolved? If so, is there an upgrade available?

I am struggling with the exact same problem.

Hello ,

I have created a support ticket for you with id CAS-84102-752GMV, in order to investigate this issue further for you.

Thank you for using Infragistics Components.

That makes more sense. If it is displaying the 'ToString' value that would probably be the Text.
I do add a node with that text to the Tree - but that is also the node where I check for its existance before adding it.

I dont know how there could be 2 UIElements pointing to it since the tree is never referenced from anywhere except the main thread. (The data loaded into this tree comes from small files on the local system so it loads very fast - no need to use threading.)

Hopefully the developers will agree with your assessment as I have now had reports from my Japanese localization team that they are also sometimes hitting the problem.

Thanks  

I don't beleive there is any way to catch an exception like this. Once a control blows up during a paint operation, I don't know of any way to recover.

I took another look at the code where the exception is occurring and the caller always creates a new Hashtable before calling the method. So there's no way any nodes could exist in the table at the time the method is called.

The HashTable here is using the node itself as the key, not the Key or Text property of the node. So the message you are getting does not indicate that the problem is with the node's text, it's just showing you the ToString of the node in the error message.

What the code does is loop through the NodeUIElements in the tree and cache them so they can be re-used. So the only way I can see that you could possibly get this error is if you have two NodeUIElements in the tree that are both pointing to the same node. In theory, this should never happen, except in the case of a threading issue.

Having said that... since this is just a caching mechanism for efficiency, I don't see any real harm in us changing this code to avoid the exception. The worst-case scenario would be a slight performance hit, which is certainly preferable to an Exception. So I am going to ask Infragistics Developer Support to write this up and for developer review and we will see if we can get this corrected in the next service release.