We have a legacy thick client product with windows forms initially designed using NetAdvantage 2004 Vol2 and NetAdvantage Ultimate 2011 Vol2. On later versions of Windows 10, the font in our results grid appears different from the MS Sans Serif we are accustomed to seeing, and when a cell is selected, WingDings are displayed. We do not explicitly set any specific font. The only thing we ever set font-wise is to either bold and set a font color so it has been a little difficult to step through the control intitialization and see why it is rendering differently. I do not see where the font is being applied or changed during initialization or event handling. This only seems to affect environments running version 1803 (Creator Update) of Windows 10. Older versions of Windows 10 and all versions of Windows 7 are unaffected. I've attempted to update the font in the grid in the Display Layout Appearance section, but it does not make any difference. The grid's font property is set to Microsoft Sans Serif, 8.25pt in Visual Studio properties page. This is happening across the entire thick client, 100's of forms, not just a few few forms.
Is there possibly a default native font defined in Infragistics that is not available in Windows 10 update? Looking at my Surface Tablet which is running the 1703 update of Windows 10, this issue does not appear, and it seems that the same fonts are installed on both machines.
This is what the form looks like the the design view:
This is what it looks like at run time with a cell selected:
The reason for WingDings being shown in results Grid when selecting a cell could be because of the font that’s being used. It might not be having a fallback font and when it can’t find any font, Grid might be showing WingDings. To ensure this is the case you could do a quick test. Use a Label and TextBox on the Form and see if you were able to observe the same behavior. If the WingDings weren’t showed when you do this test then please send us a sample of this issue and we will investigate it further.
I will continue to look into this issue as soon as I hear from you.
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.
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:
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?
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.
David Cannon said: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
That seems unlikely to me. I mean... 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, just like every other control in your application. Whatever is happening in your application is specific to the grid(s). Also, if that were the case, then it would be very easy to see. the grid's Font property would be returning Segoe UI or Bahnscrift, not MS Sans Serif.
What happens if you create a new application and put a grid on a form with some data? Do you get the same results? If so, then that would indicate that there is something going on with your machine that is causing that. If not, it would indicate that there some factor specific to your application. BTW... you mentioned you check for "StyleManager.Load". Did you also check for "DisplayLayout.Load"? That one is a little harder to check for, since it's possible that you could be storing the DisplayLayout in a member variable:
var layout = this.ultraGrid1.DisplayLayout;
And then calling layout.Load.
One other thing to check for would be "PresetSerializer". That's another way you could apply a group of settings to the grid without setting a property directly. Checking for FontData.Name is tough, because this could be set on a wide variety of Appearance objects. There are literally dozens of them that could be affecting cells. One other test you could try is to run this code in a button click and see what it shows in the Output window. That might tell use something about where the font is coming from.
private void DisplayFonts(UltraGrid grid)
Debug.WriteLine(grid.Font.Name, "Grid Font");
AppearanceData appData = new AppearanceData();
AppearancePropFlags flags = AppearancePropFlags.FontName;
grid.DisplayLayout.ResolveLayoutAppearance(ref appData, ref flags, true);
Debug.WriteLine(appData.FontData.Name, "DisplayLayout font");
appData = new AppearanceData();
flags = AppearancePropFlags.FontName;
grid.DisplayLayout.Rows.Cells.ResolveAppearance(ref appData, flags);
Debug.WriteLine(appData.FontData.Name, "Cell Font");
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.
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.
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.
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?
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.
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.