Hello Michael,

As I described I created a new Forms Project dropped a FontNameEditor on the empty form and pressed run. I did not otherwise add any code or change any properties. So this it ...

        public Form1()
        {
            InitializeComponent();
        }

If you tell me how to upload the solution I could provide it but you could probably just as quickly create this yourself.

As I mentioned in my own application the exception happens immediately. In this test I have to scroll the font list for a second or two before anything happens.

Hi Michael,

I have run your test app and my own test app with both build 2009 which is what I had installed and build 2036 the latest SR of 17.2.

The behavior is the same, an OutOfMemory exception about half-way through the font list.

There is no difference between running under VS or running the executable directly.

Setting ShowFontNamesInFont False does fix the problem and that is an OK solution for me for now.

But as this has worked before, my application was first released in 2007, I assume that there is a bug somewhere ;).

Thanks for your support

/Mats

A few more pieces of info...

I can scroll through the full font list in MS Word without problem.

According to VS Performance Profiler, 51 MB of memory is used when the OutOfMemory exception occurs.

/Mats

51 MB is nothing. So my guess is that the exception is caused by some particular font on your machine. Like it's trying to draw the text of that font using that font and it's failing for some reason in GDI Plus to draw that font and it's not REALLY an OutOfMemory exception. There may be a font on your system that is corrupted or improperly installed or something like that. 

If you want to pursue it, you might be able to track it down by placing a label on the form and then responding the ValueChange of the UltraFontNameEditor (with ShowFontNamesInFont set to false) and then applying the selected font to the label. If my theory is correct then one of your fonts will cause the label to blow up and that will help us determine which font is the problem. 

Hello Mike and thanks for supporting.

A few more pieces of info, some confirming your theory and some maybe pointing in other directions.

I have run your test app on two new test VM (Win 7 and Win 10) both work OK.

I have identified the font causing the problem in the test app, it is MingLiU, entering the font name in the box and clicking the down arrow gives and immediate exception and a font list with a red X over it.

But ...

The font renders OK in MS Word both in text and in the font selector. The font also renders OK in the Control Panel font app.

The problem in my (full) program was immediately on opening the font list that would be in that case be a different font at the start of the alphabet.

The font is a protected system font so I was not able to delete it in a "normal" way. A bit of registry hacking managed to remove the font from the list and in that case both the test app and my full app works OK.

The only difference I have noted between the old development system and the new test systems is that on the development VM the font is listed as OpenType while on the test systems and MS Website it is listed as TrueType.

I guess the problem is gone for now although I do not understand how this all fits together?

/Mats

Hi Mats, 

In your original post, the call stack shows that the exception occurs when trying to draw text. So my best guess is that there is something about that font that is blowing up when trying to draw text using GDI Plus. It might be limited to a particular size, also. That would explain why it works okay in Word (since Word probably uses GDI, not GDI Plus). 

I checked on my machine and I don't have 'MingLiU." I do have "MingLiU_HKSCS-ExtB" and "MingLiU-ExtB", but they both work fine for me. 

You mentioned a test app. I assume you mean you created an app like I described that assigns the font to a label? If you were able to get that to raise the exception, then that seems like that would be pretty conclusive proof that this is a bug in the DotNet Framework since in that case, the FontNameEditor isn't even needed. Either that, or more likely, there's something corrupt about that font file. The latter seems more likely, since you say it works fine on two other machines.

If that's the case, then there's not much we can do as it must be a machine-specific issue.