wxWidgets controls don't use the user-configured large font

[vegpuff]

Operating System : Windows XP Service Pack 3

User sets his DPI to 120dpi (125%) from 96dpi (100%) and opens  wxMSW widgets demo .

Title, Menubar show fonts of size 125%, but controls like wxTextCtrl, wxCheckBox, wxComboBox do not reflect the change in DPI and show 100%. See screenshot.

PS: This issue originally came from  NVDA

[vegpuff]

Screenshot of MSW Widget Controls Demo with 120dpi (125%)

[vadz]

Is the problem that the fonts don't change correctly when the user changes the DPI while a wx program is running or are they still incorrect even after restart?

If it's the latter, it's indeed a serious problem which needs to be fixed but I wonder what could we be doing wrong here: we just use DEFAULT_GUI_FONT which should have correct size...

[BillNotTed]

This is also an issue in 2.9.0 RC6. It appears that the DPI settings are not respected even after a restart. However MS does not recommend the use of DEFAULT_GUI_FONT any longer ( http://msdn.microsoft.com/en-us/library/dd144925%28VS.85%29.aspx).

[cmbruns]

This might be the same as issue 1981, reported five years ago. In any case, I have written a  report of possibly related undesired font size behavior when selecting "Large Fonts" on Windows XP. Please take a look at my  report for details.

[vadz]

Adding reporter of #1981 to the cc list of this one.

[vadz]

BillNotTed is correct in comment:2, we shouldn't be using DEFAULT_GUI_FONT and apparently should never had (see  http://blogs.msdn.com/oldnewthing/archive/2005/07/07/436435.aspx).

So we should be using GetNonClientMetrics() (from include/wx/msw/private/metrics.h) instead of it. The only problem is which of the fields of this structure should be used. lfMessageFont? lfCaptionFont? lfMenuFont? Different ones for different controls (e.g. lfStatusFont for wxStatusBar)? Does anybody have any ideas?

Ah, and how is all this related to the font returned by SPI_GETICONTITLELOGFONT? I hope it's always the same one as one of the above but I wouldn't bet on it...

[cmbruns]

The wx method wxGetCCDefaultFont() should probably return GetNonClientMetrics->lfMessageFont on Windows. I say this because lfMessageFont appears to be the "default" font in  Tk 8.5, which does respect the user's windows font size choice.

That said, a complete solution should also used different fonts for different controls.  For example, lfMenuFont in pull down menus, and lfStatusFont in the status bar.  Perhaps those controls already retrieve the correct fonts.  I have only tested the wxButton and wxStaticText widgets, which do not respect the font size.

[vadz]

I tested this and actually this is not the correct thing to do for the previous Windows versions (2000) which didn't use the same font there. But simply using message box font for all controls which are not list/tree seems to work fine for me under both 2000 and Vista so I will just commit this for now and let's update other controls as necessary later.

[VZ]

(In [61790]) Use correct font instead of DEFAULT_GUI_FONT.

DEFAULT_GUI_FONT is a misnomer, not only is it not a default (and never was)
but it shouldn't be used at all. Instead use lfMessageFont from the
NONCLIENTMETRICS structure as it seems to correspond to the font used by
the native controls under 2000, XP and Vista and respects Vista global DPI
setting unlike DEFAULT_GUI_FONT.

Closes #11008.

[vadz]

This could be backported to 2.8 if no problems are found (although non trivially so because wxMSWImpl::GetNonClientMetrics() doesn't exist there so it would need to be duplicated in wxSystemSettings probably).

[cmbruns]

Thanks so much vadz for fixing this problem.

I encourage you to consider backporting to 2.8.  My life will be improved the day this change arrives in a mainstream release of wxPython.  In any case, thanks again for your diligent effort.  It is much appreciated.

[vadz]

If no problems are found with it we could do it in the future but it's too early yet.

I hope wxPython release using 2.9.0 or the upcoming 2.9.1 will be ready soon though.