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,

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.

I am not even able to replicate the problem on my systems (XP or Win7) but my tester in India can frequently replicate the problem. (Originally only on Win7, but now only on XP)

Can you have someone check to see if something was changed in the UltraTree (or the HashTable it uses during painting) since version 10.3. We never saw this problem until we upgraded to 11.2.

If I can not fix the problem is there a way I can work around it?

I can create my own class that derives from the UltraTree and override only the OnPaint() method.
This event would simply call its base method from within a Try/Catch block.

I could call Invalidate() or Refresh() from within the Catch block to repaint the control, but if the problem is in your internal Hash Table it would probably go into a loop. Is there a way for me to blow away your hash table so that it would get rebuilt from the actual data in the Tree?

Is there another alternative - short of clearing all the tree nodes and reloading from scratch?

(I know from the tooltips that the underlying data still exists in the tree, and looks correct.)

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.