Hm. Well, if you are happy with that workaround, then that's good. But I agree with you, it doesn't really explain what's happening here. I mean... basically what you are doing here is explicitly setting the grid's Font property to something other than the default - even though you are using MS Sans Serif, it appears to be some other version of MS Sans Serif, perhaps embedded in your application, rather than the system font.

So it makes sense why this would fix the issue, since you are specifying another font, but it doesn't really explain why the issue occurring in the first place. I wonder if it's related to the fact that this font you are using, whatever it is and wherever it's coming from, has the same name as an existing system font and so the DotNet Framework is somehow getting confused. 

You say that this code was basically running and being applied to every control but the grid. I'd be curious to know what happens if you exclude some other control, like the Label or TextBox control. Do those controls then have the same problem the grid was having?

Hi Mike,

First of all, I want to say thanks for all your time, input and patience. I know this has been a very weird issue. I did try to create a simple windows form with a grid and could not reproduce the issue. I did attempt to recreate some of the framework around the windows forms that we use in our UI, but I wasn't able to recreate the issue that way either. Our UI can be an over-complicated mess spanning multiple layers of abstraction through hundreds of thousands of lines of code. 

What I did find today is that we do treat the grid a little differently when initializing the control. Let me see if I can explain. First of all, we use an approach called control 'specification' which essentially is a properties wrapper. This goes back to the days when we provided a tool to the client to allow them to customize their forms. That became a maintenance nightmare, so we stopped doing that, however, the specifications live on. We design the form visually, the specification is a property we set that contains behaviors and properties such as stored procedure names, data field mappings and required behavior. We load the form at run time with a reference to the spec. When we configure the control in the initialization method, we grab information from the supplied specification to set the look and feel of the form. 

In the base ControlConfigurator class, we set some font behavior from the specification, including, bold, italic, underline, font size and font name. But there is a conditional statement right before hand that says "If the type is not UltraGrid" do this. So essentially, we skip that configuration step for grids. 

So I applied a subset of that code being skipped to my configuration function for the UltraGrid configuration.

Dim fontSize As Single = Font.Size
If mSpecification.FontSize > 0.0 Then fontSize = CType(mSpecification.FontSize, Single)
Dim fontOfControl As Font = New Font(mSpecification.FontName, fontSize)
Font = fontOfControl

When I step through that code in debug, the grid's Font property shows that the the Font is set to Microsoft Sans Serif, 8.25 as does the instantiated font from the specification. However, there are some differences in the Font's sub properties, namely system font name and original font name:

I don't understand why this behaves differently and what that really means, but I know that if I do not call this code block when I initialize the grid, the native control's Font is used and does the weird rendering thing with Bahnscrift and wingdings. When I do call this code, I initialize a new font using the supplied specification to explicitly apply it to the Grid's Font property, then it renders as expected. This was never an issue until we applied Windows 10 update 1803.

Fortunately, because we wrap everything into abstracted layers, I can just apply this code in our base grid class and it applies to all of our grids and the problem appears resolved. It is just strange to me because before the windows update, it would implicitly apply the correct font, but now we have to explicitly define the font for the grid. And for whatever reason, the other controls are not affected by this. I stepped over the block of code that applies the font from the specification to the other controls, and they rendered the same as they would with the specification.

The fact that the grid has an additional property (DisplayLayout) that allows you to set the font isn't really relevant to the issue. Or, at least, if it is, I don't see how it could be. The way the appearance resolution works is exactly what you described - if a cell (or any other object in the grid) resolves all of the applicable appearances (like CellAppearance, RowAppearance, etc.) and finds that none of them have set a font, it falls back to the grid control's Font. So in that sense, if you have set no Font name on any applicable appearance, the grid is no different than any other control - it's using the Control's font. The grid doesn't go around the Control.Font and try to get some default font from the system or anything like that. So it's very odd that the grid is the only control in your application that is affected. 

Did you try testing this in a new application? I'd be very curious to see if you can reproduce the same problem in a new application, because that would definitively eliminate the possibility that anything is being set in your app that is affecting the font. 

One other thing you could try is to set the TextRenderingMode and see if that makes any difference. Because one thing that the grid does differently than other controls by default is that it uses GDIPlus instead of GDI text rendering.

Mike Saltzman said:

... if that were the case, then it would be affecting ALL of your controls, not just the grid. There's no reason why the grid would be any different than any other control. The grid is just a class that derives from Control

But the grid is a little different from the other controls in that it contains a DisplayLayout property. All of our controls, including the grid set the default font property to Microsoft Sans Serif. But what we haven't set is the Display Layout or Appearance properties. (I did apply your DisplayFonts function to the form and verified that the appearance data is never being set.)

My thought would be that if the Display Layout Appearance does not define font data, that it should resolve to the font data on the control, but we seem to be bypassing that and looking to the system default, which is where we end up with the bahnscrift and wingding issue. 

I could not find where we call load on the DisplayLayout, however, when we initialize the grid, we do set a few properties for behavior, such as AllowAddNew and Scrollbars and so on. So here is what I did, I have now set the DisplayLayout for Caption Appearance, Cell Appearance, and HeaderAppearance in the grid initialization class to use the correct font, and now it works without needing a registry hack.