The big red "X" occurs any time an exception occurs inside the OnPaint method of a control. Since the controls have been around so long and are so well-used and therefore well-tested, we rarely find bugs in the painting code any more. But it can happen.

Does the exception always occur with the same call stack which includes a reference to the FormattedLinkLabel?

Is the exception always on a call to GetHdc?

Or does the exception vary each time it occurs?

If the exception always happens on the same call to GetHdc being called from MeasureTextGDIOrThemed, then this is likely a bug in the FormattedLinkLabel.

If the exception varies each time it occurs, then it's probably a memory or threading issue.

Hi Mike,

Thanks for taking a look at this.

Mike Saltzman"]Does the exception always occur with the same call stack which includes a reference to the FormattedLinkLabel?

Yes, the call-stack in the exception is always exactly the same.

After having a look at it further, we established it was occuring when a Form containing an UltraExplorerBar is shown from the Form that contains the Ribbon. The item that was selected in the UltraExplorerBar when the Form was displayed last is selected upon displaying the Form (in the construct). The error occured intermitently, only when it selected an item in the bar that was not the default selected item. It always occured soon after displaying the form, but it could take up to 10 iterations of closing the form and reopening it too see the error.

To select the item in the explorer bar in the Form, we set the SelectedGroup of the explorer bar to the group that contained the appropriate item, and then checked the appropriate item.

I modified this so that instead, the ActiveGroup of the explorer bar is set to the group that contains the appropriate item. We perform the SelectActiveGroup action on the explorer bar using the PerformAction method, and then check the item in the same way. This appears to have worked!

So I'm guessing there's an issue relating to the focus of the groups or something?

Out of interest, does this still sound like a bug, or it simply bad practice to select things in an Infragistics Control by setting the SelectedX property e.g. SelectedGroup?

Thanks for the information Mike!

Cheers,

Richard

Hi Richard,

Richard said:

Out of interest, does this still sound like a bug, or it simply bad practice to select things in an Infragistics Control by setting the SelectedX property e.g. SelectedGroup?

It's impossible to say for sure without being able to duplicate the issue. It could be a timing or threading issue, but it's certainly possible that it's a bug in the ExplorerBar. Perhaps setting the SelectedGroup is forcing it to paint too early before some part of the control has been properly initialized.

If you can reproduce the issue in a small sample project and post it here, we could look into it further.

Thanks Mike, I'll keep an eye out for it and when I get a chance I'll post a sample. Thanks for your help.

Richard

I have the same issue with 2010 Volume 2 version the same call stack. Was it identified and rectified in the other release?

As far as I know, we never got a sample, so we were never able to duplicate the issue in response to this forum post. But I wouldn't be surprised if the same issue came up from another customer and the issue was fixed a long time ago. I haven't heard any recent reports of a big red X in this control. The only way to know for sure is to try it with the latest version. You could download a trial version and try it out.

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.

1. Open program
1. Count is 18/35
2. Open child window
1. Count is 31/43
3. Close child window
1. Count is 21/40
4. Open child window
1. Count is 31/43
5. Close child window
1. Count is 21/40

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

Hello 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\GDIProcessHandleQuota

User 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

Hello Johnie,

I'm attempting to reproduce the issue you described, but I'm not able to.  Which version of Windows are you using?