Hi all,
I've witnessed this big red cross appearing in place of an UltraGrid when calls wern't marshalled correctly to the main/UI thread when making use of the control.
I have an application that I've ensured only accesses controls from the main/UI thread.
Recently, we've been stress-testing our application and have witnessed this red cross again. This time it appears in place of a ribbon/toolbar control. It's only ever appeared when we're using excessive amounts of memory - causing some components of the application to become sluggish. One example is when the user creates a scatter UltraChart component that has about 40,000 points of data.
So I have a couple of questions concerning this issue:
I'd appreciate any more information regarding this red cross. From what I've read so far:
Any information what so ever (even simply to clarify my current understanding is correct) would be greatly appreciated.
Cheers,
Richard
I have the same issue with UltraToolbarManager and UltraTree.
My application sometimes must load large projects, which contains more than 500 nodes in tree. Each node has some images in nodeappearance, and the interactive actions are provided in toolbarmanager. If I use tree.nodes.clear and then rebuild the tree with nodes several times. I have the same exception with a big "X" in ultratree component. I have to say that, this problem is very very hard to reproduce.
After several days work, my solution is that for the ultratree and toolbarmananger, if assign an image, use
node.Override.NodeAppearance.Image = DrawUtility.CopyImage(My.ResourceManager.Icons.MyIcon,nothing)
instead of directly use
node.Override.NodeAppearance.Image = My.ResourceManager.Icons.MyIcon
I have tested with the same scenario and until now it works fine.
Another idea is that, before call tree.nodes.clear, do node.Override.NodeAppearance.ResetImage for every nodes in the tree. But I have not tested this solution.
I hope it helps.
Hello Johnie,
Thank you for your response.
What you're seeing there is not actually a leak. What you're seeing is some objects being retained after they are created for optimization purposes. I've modified your sample to remove all of the Infragistics controls and added a second MDI child form that is opened by "button1". If you run it, you'll see the same kind of behavior in regards to the GDI and USER objects.
It is still very possible that your application has a GDI/USER object leak, but the sample you provided doesn't reproduce that.
Hi Dave,
The reason we can't duplicate the issue with your sample, is because you are dynamically creating and then disposing that created object. This doesn't represent a real-world application however. I've modified the sample for you, and in the process, I have come to a better understanding of the leak behavior.
The sample contains an MDI parent with a button. When the button is clicked, a child window is opened up. When the child window is closed, the counts do not drop to the original value. It should be noted that the object counts will not go up past this new number on subsequent window open/closes. I don't know how to make that statement clear, so I'm sorry it doesn't make any sense. I've used our real application and took step-by-step screenshots (the word document), which will demonstrate what I mean. Using the new sample project, here is what happens.
Obviously, this issue wouldn't occur for a small application (like our sample). However; our application contains many, many windows, so as windows are opened and closed over time, this number grows higher and higher.
Thanks,Johnie
Thank you for your response. I should have been more clear with my previous response. When I run my sample, I don't see the number of GDI objects or USER objects going up and up without stop.
I've attached my sample so you can see if it reproduces the issue on your end. If it doesn't, let me know how I can modify it so it does reproduce the issue.
Dave,We can verify the problem with Windows XP, 7, and 8.
Here is what you will need to do for an easy test.
By default, Windows allows 10,000 user objects and 10,000 GDI objects per application instance. What you are testing for is a slow leak, and obviously 10,000 objects is a lot to work your way up to.
Luckily for us, this "quota" is a setting in the Registry, so we can first modify the registry to a more manageable number, say 1,000 user objects and 500 GDI objects.
GDI Object Limit:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuotaUser Object Limit:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota
I only changed one of these at a time, and I used a computer that didn't have any other programs running. To monitor, open Task Manager and add columns User Objects and GDI Objects.
Now that you have your settings to a easily manageable number, open a project that has lots of Infragistics controls and many child windows that also have Infragistics controls. As you continue to open and close windows, you will see that the GDI Objects and User Objects will slowly creep up, and once they hit their limit, you will get the red box.
The decompiled code I provided in my earlier post is only one place where we found this slow leak in the library, we only looked in this one place though, so it's likely in more places.
Thanks,Johnie Karr