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:
We too saw the Wingdings font issue with the Infragistics UltraWin* controls after applying the Windows 10 April 2018 Update, version 1803.
We had to set a default font for all controls and re-issue new builds for our users. A big PITA.
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");
One other thing... I just did a Google search for similar behavior and it looks like you are not the only one experiencing a problem with the update.
That doesn't explain why it's only affecting your WinGrids and not the other controls on the form, but maybe there's more going on here than meets the eye.
You might want to check with Microsoft and see if they have a solution.
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.