Thanks for looking at this Sahaja. The label and text box controls do not display the same behavior. All of the controls, including the ultra grid, have the font name set to Microsoft Sans Serif. But only the grid is displaying a different font at run time. I narrowed down that the font being displayed in the grid is Bahnscrift. Then, when a cell is selected, the highlighted text is wingdings. I would note that we do not use any custom fonts in our application, we just use the fonts that are included with Windows.

I did notice that the grid control also contains a "Display Layout" property that contains nodes for 'Appearance', each of which contains their own font settings. These font settings were not set by default, so I updated them to use Microsoft Sans Serif in 8 pt, but it still displayed the wayward Bahnscrift and wingdings at run time. 

I found I am able to work around the issue by clearing the Bahnscrift font value in the registry and creating a font substitute that maps Bahnscrift to Microsoft Sans Serif. But I don't feel this is the correct approach to resolving the issue, I would rather fix the software issue instead of hacking the registry.

I will look at getting a code sample to you, it will take me a bit to get a small sample that reproduces the same issue.

Hi David, 

You seem to be saying some contradictory things here. You repeatedly say that you are not using any custom fonts and that everything in your application is using MS Sans Serif, but then you say that that grid is displaying using Bahnscrift.

Are you saying that Bahnscrift is being used to display the grid even though you have not set it to do so anywhere in your application? 

If you don't set a font on anything, then the DotNet framework falls back to the ambient font, which on American English machines is MS Sans Serif. There's nothing in the grid that would change that for any reason. So if your grid is using Bahnscrift then something in your application has to be assigning that font somewhere. 

If you search your code for "Bahnscrift" and don't find it, then there are several other places it could be coming from. If you are loading a layout into the grid, the layout might be setting a font on any one of the grid's Appearance properties. In this case, since the font is only appearing in the active cell, then the obvious guess would be the EditCellAppearance on the Override of either the DisplayLayout or the band. It could also be applied to the ActiveCellAppearance, so I would recommend putting a button on your form as a test and then at run-time, check the font name on all of these appearances: 

            Debug.WriteLine(this.ultraGrid1.DisplayLayout.Override.EditCellAppearance.FontData.Name);
            Debug.WriteLine(this.ultraGrid1.DisplayLayout.Bands[0].Override.EditCellAppearance.FontData.Name);
            Debug.WriteLine(this.ultraGrid1.DisplayLayout.Override.ActiveCellAppearance.FontData.Name);
            Debug.WriteLine(this.ultraGrid1.DisplayLayout.Bands[0].Override.ActiveCellAppearance.FontData.Name);

If that doesn't turn up anything useful, then another possibility is that one of these settings is being affected by AppStylist. Check your code for a call to the "StyleManager.Load" method to see if you are loading a style library. If so, then this could be affecting the font without actually setting any of the properties on the grid. 

BTW... How did you determine that the grid is display using Bahnscrift? Do you mean the WHOLE grid? Or just the active cell in edit mode? 

Hi Mike,

I don't mean to sound contradictory, but that is absolutely correct. We do not set any fonts in the controls other than Microsoft San Serif. In the design view, MS Sans Serif is displayed, but at run time, the ultragrid, (And yes, the WHOLE grid, and nothing but the grid) displays using Bahnscrift as illustrated in the images in my initial post.

For clarity of the initial post, I only included the image of the grid, but if I were to display the entire form, you would see that all the other labels, text fields, buttons etc would be using MS Sans Serif as expected. This behavior is limited to the grid. In addition to Bahnscrift, when a grid cell is activated in edit mode, the text is rendered as Wingding (which is what first alerted us to an issue).

I am certain that the Bahnscrift font is not being applied by our code. We actually wrap the Infragistics controls and make use of abstracted base forms to provide consistent behavior across the UI. (Yes, this affects all the grids in our UI, approximately 1800 of them)  I have actually tested the DisplayLayout in debug to see if we are setting the FontData Name name at runtime, and we are not setting any value there. I also looked for references to StyleManager.Load, and there are no references found in the solution. We set the font name at the control level, and never apply any layout configuration beyond that. 

How did I determine the grid is using Bahnscrift? I'm glad you asked. It was actually quite painful. I tried some online font programs where i submitted an image, but wasn't having any luck. So then I painstakingly tested each font (I have 186 on my local workstation) using the same string as the affected grid title "Records Matching Filter Criteria" until I visually found a match. I actually found about a half dozen that were close, but continued to narrow that down until we were certain it was bahnscrift. Then, I updated my registry to point the bahnscrift font to use Arial, and when I restarted and relaunched the form, I found that the grid no longer displayed the wonky font.

Now this is where it gets interesting... I did a little additional digging on Bahnscrift. It turns out that it is a brand new font from Windows that became installed as a system font with update 1803. The only users that are reporting this issue are the ones on Windows 10 Update 1803. My laptop has Windows 10 update 1703, and it is unaffected. It was only with this latest update that we began to have issues. Here is my guess as to what is happening. Because we don't define the font in the grid's display layout, Windows is now applying Bahnscrift as a default font. I know you mentioned that .Net defaults to the ambient font of MS Sans Serif, and I think that is true for Windows 7, but I believe (and I may be wrong) that Windows 10 now uses Segoe UI as the default font, and I am suspecting that as of update 1803, that maybe Bahnscrift is now being applied as a default font in some cases. I attempted to uninstall Bahnscrift, but it is a protected font. Best I could do was create a registry entry for Font Substitute to route to Microsoft Sans Serif anytime Bahnscrift is used. 

Hello David,

I will try to reproduce this issue using Windows 10 1803 update.  Once I create a sample and observe this behavior, we will test it further to investigate what’s causing this. If you already have a sample, please send it to us. It will help us in investigating this issue faster.

I will post an update by end of day Thursday.

Please let me know if you have any questions.

The TextRenderingMode was set to Default, I tried both GDI and GDIPlus, but with the same errant results. 

Hm, that is really surprising. I was really expecting the other controls on the form to have the same issue once you were not setting the font on them. 

The only other thing I can think of that makes the grid different in any way is the TextRenderingMode. That might be worth a try, just as a matter of curiosity.

When I step over the configuration block, it doesn't affect how other controls are configured. The other controls do not have the same problem as the grid. That is very curious to me because I would have expected them to display the wrong font like the grid did. I even looked at the lower level properties of the Font and saw that the System Font Name was configured in the same way the grid's font was before I overwrote it with the specification properties in the configuration code. So I am baffled by the whole thing.

¯\_(ツ)_/¯

If you have a morbid curiosity about it, I can possibly see about setting up a web meeting to demonstrate it, but I'm sure you are as busy as we are and I am good with just modifying the base class behavior with the workaround to make it all go away.

Thanks again for everything.