I have the following code (generated by the designer):
this.panelTabs.Font = new System.Drawing.Font("Verdana", 11.25F, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, ((byte)(0)));
A user running our app gets the exception:
ArgumentException: Font 'Verdana' does not support style 'Regular'.
because the user's computer has all verdana font files but the "Regular" one. So he has bold, italics, etc files but does NOT have the "regular" font style.
If all the verdana fonts are missing, Windows smartly does a font substitution. However, when certain style is missing, it does not seem to do it.
How can I avoid this exceptioon without having to go through hundreds of lines of code to change the designer code? Is there any explicit font substitution that can be done?
I find this problem quite likely to happen to all apps out there because the code above is generated by the designer, and users can remove fonts/font styles at any time.
Thanks! Your question helps me, even if my answer doesn't help you. ;)
I also had a user report an exception in my app due to missing Verdana, but I didn't have as much info from the user as you so I didn't know how he got the exception.
How about catching the exception and falling back on GenericFontFamilies? That's what I think I'll do.
The problem with that approach is that the code I show above is generated by the designer. So if anyone opens your control/form, the designer will overwrite the code. You could also catch the exception by wrapping the InitializeComponent() call, but then what do you do if it fails?
You probably shouldn't try to handle an exception like this. Errors like these fall in the "Windows not configured correctly" category. Just make sure you give the user a good diagnostic, the exception message is certainly informative enough. The solution for the user is simple: reinstall the Verdana font.
UI Freak, my own solution is that I don't use the designer, and I avoid code generators in general, because of this type of inherent limitation. A compromise solution is to use the designer until it causes a problem like this, then move that code out of the designer's control and "take control of it yourself".
That's a remark that's on the left side of silly. This is nothing to do with a limitation in the Windows Forms designer. You are in control of the code it generates, it would be a poor design for a designer if you weren't. It doesn't do anything special, it just creates controls, sets its properties and wires up the event handlers. Doing it yourself would involve writing code that creates controls, sets its properties and wires up the event handlers. Without being able to see up front what it might look like at run-time.
If you don't like relying on having a font present at run-time, write console mode programs. Then again, they too rely on having the right components (and fonts) present at run-time.
nobugz, sorry you're defensive about my criticism of "designers".
I admit I haven't used the designer, because I'm not using Visual C#, because the Visual tools tend to place too many restrictions on my program. E.g. VC# 2005 can only target .NET 2.0, IIRC, even though many user machines have only .NET 1.1.
But I used the UI code generators in VC++ 6. If the Designer lets you specify your own font creation code instead of its own default code, and it doesn't overwrite your own modifications to its generated code (I can't tell which of these you mean by "you're in control of the code it generates"), then it's come a long way since VC 6.
Also sorry you think that programmers who want to mitigate the fragility of the Windows font system by writing a few lines of code to handle real-world user scenarios shouldn't be writing UI programs.
Just had the same problem.
I found another Windows machine and went to its Fonts folder (C:\Windows\Fonts) and copied all the fonts from there to my broken machine.
How did these fonts disappear and why isn't Windows (or .NET) substituting is a mystery.
- Proposed as answer by Raidah Friday, May 22, 2009 3:48 PM