I've looked more closely at my Infragistics account downloads and I've access to 2009 Vol 2, which I've upgraded my project to. This gives me version 9.2.20092.1003 of the UltraWinTree.

BUT, the same memory leak problem STILL exists in this version, despite you saying it was fixed in v8.3 and up!!!???

Can you please offer some help or a solution?

Many thanks in advance.

Hi Mike,

I think I might have mislead you about the VisibleNodesManager in 9.2.

While that was the cause of the leak in v6.1, it now appears there is a DIFFERENT memory leak in v9.2 which I thought was the visible nodes thing!

This new leak is in a Dictionary called 'entries' belonging to a variable called nodeElements within another variable called nodeClientAreaUIElement

It would seem this dictionary is holding onto references of removed nodes!

I should also point out that I have downloaded a trial version of v16.1 and this new leak is present there too!

Any suggestions for workarounds?

Any help gratefully received.

Pete.

Hi Pete,

Ah, that's different, then. I took another quick look at the code and  don't see any obvious leaks here, though. This dictionary gets cleared every time the control positions it's UIElement. So that basically means every time it paints and something has changed. So removing a node would certainly be included in the category.

If you can post a sample project that demonstrates the leak, I'd be happy to take a look, but I wonder if your testing just isn't doing garbage collection or something.

Hi Mike,

Sorry for the delay in replying - time differences!

I've now had the chance to use a different Memory profiler, which enables me to force garbage collections between snapshots of memory. This new profiler still shows the same problem, despite the collections.

Maybe I'm not expressing myself accurately, but I feel strongly there is a problem here. It's very unlikely 2 different packages pointing to the same cause of the memory leak are wrong.

Is there a way I can email you screen shots containing the chain of dependencies, as I'd rather not post everything here?

Cheers

Pete.

Hi Mike,

Could I ask you to take another look at the code base. Specifically, at the .Key property of the generic Entry<UltraTreeNode , TreeNodeUIElement> within the entries generic dictionary.

This is the thing that's holding onto a reference of the UltraTreeNode that's been removed from the Tree.

Many thanks for all your help.

Pete.

Hi Pete,

The Key property is not on an Infragistics object. That's part of the DotNet Framework and how it keeps track of items in a Dictionary<>. Once the collection is cleared (and it's cleared essentially every time something changed in the control), there nothing holding a reference to that node any more.

If you check the memory usage at that time, you might see that node in memory, because it has not been (and cannot be) explicitly disposed. But once the Garbage collector collects, it will be cleaned up, since nothing is holding a reference to it any more. Hence why I suspect you are simply not explicitly garbage collecting in your testing.

Hi Pete,

Pete said:

I am aware .KEY is a property on a .NET framework class, but it is being used within an Infragistics type. I only mentioned it as additional information as to the whereabouts of the reference within said type that was causing the issue.

Yeah, that part is pretty clear. The Dictionary is using the node as a key and storing the UIElement for that node. This is a performance optimization so we can easily find the UIElement for the node.

But since the Dictionary is cleared often, I don't see any way that this could cause a memory leak.

Anyway, I'm eager to see what happens with my sample on your machine.

Mike

Hi Mike,

Thanks for your replies.

I am aware .KEY is a property on a .NET framework class, but it is being used within an Infragistics type. I only mentioned it as additional information as to the whereabouts of the reference within said type that was causing the issue.

ANTS is the same profiler I am using so that will keep things even between our tests too.

I'll get back to you with my findings.

Cheers

Pete.

Hi Pete,

Just to be sure, I tried this out in a very simple case, and even without explicitly doing garbage collection, I don't see any problem. I am attaching my sample here so you can try it out.

All I did was I ran the sample and took a snapshot using Ants Memory Profiler. Then I click the button a few times. Then took another snapshot.

There is an increase in the instances of some classes like object and StringFormat, but nothing related to the tree.

I did my testing with v9.2 with the latest service release, so it's possible there are some fixes I have that you don't. You could correct that by getting the latest SR for 9.2, but when I looked at the code, I didn't see anything in there that would have had any effect on this behavior.

See if you get the same leak with my sample. If not, then the issue is in something your application is doing that mine is not. If you do get the same leak, then this must be a difference between the version you are using and the one I am using so getting the latest SR should fix it.

Screen shots wouldn't really help here, but if you are garbage collecting and there's still an issue, then we would need to be able reproduce the problem in order to debug it and figure out what's going on. Can you create a small sample project that demonstrates the leak? If it truly is a bug in the control, then this should simply be a matter of creating a tree with some nodes, taking a snapshot, then removing some nodes, and taking another snapshot and comparing the two.