One of the exceptions I see with a reasonable frequency (usually in Gif Animator) is Only TrueType fonts are supported. This is not a TrueType font.
This exception is thrown when using the
System.Windows.Forms.FontDialog component and you select an
invalid font. And you can't do a thing about it*, as
this exception is buried in a private method of the
that isn't handled.
As the bug has been there for years without being fixed, and given that fact that Windows Forms isn't exactly high on the list of priorities for Microsoft, I suspect it will never be fixed. This is one wheel I'd prefer not to reinvent, but... here it is anyway.
Cyotek.Windows.Forms.FontDialog component is a drop in
replacement for the original
but without the crash that occurs when selecting a non-True Type
This version uses the native Win32 dialog via
ChooseFont - the
hook procedure to handle the
Apply event and hiding the colour
combobox has been taken directly from the original component. As
I'm inheriting from the same base component and have replicated
the API completely, you should simply be able to replace
Cyotek.Windows.Forms.FontDialog and it will work.
There's also a fully managed solution buried in one of the
branches of the repository. It is incomplete, mainly because I
wasn't able to determine which fonts are hidden by settings, and
how to combine families with non standard styles such as
Light. It's still interesting in its own right, showing how to
EnumFontFamiliesEx and other interop calls, but for now it
is on hold as a work in progress.
I haven't actually managed to find a font that causes this type of crash, although I have quite a few automated error reports from users who experience it. If you know of such a font that is (legally!) available for download, please let me know so that I can test this myself. I assume my version fixes the problem but at this point I don't actually know for sure.
The source is available from GitHub.
A NuGet package is available.
FontDialog component is licensed under the MIT License.
LICENSE.txt for the full text.
* You might be able to catch it in
AppDomain.CurrentDomain.UnhandledException (or even by just
wrapping the call to
ShowDialog in a
but as I haven't been able to reproduce this crash I have no way
of knowing for sure. Plus I have no idea if it will leave the
Win32 dialog open or destabilize it in some way
- 2015-08-15 - First published
- 2020-11-21 - Updated formatting