UpdateFonts with Office2013 theme bug?
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Command Bars
Forum Description: Topics Related to Codejock Command Bars
URL: http://forum.codejock.com/forum_posts.asp?TID=22519
Printed Date: 28 November 2024 at 7:06am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: UpdateFonts with Office2013 theme bug?
Posted By: rdhd
Subject: UpdateFonts with Office2013 theme bug?
Date Posted: 21 January 2015 at 8:32am
|
I seem to have a problem with the Office 2013 (white) ribbon theme paint
code. I have support for Office 2007 and Office 2010 themes and I have
for a long time now been able to increase the font size on the ribbon by
calling SetFontHeight. I do this for high-res monitors (I also set the
command bar paint manager's m_bAutoResizeIcons to TRUE). Works pretty
well. I get a larger font and larger buttons, which works pretty well on
my 4k monitor. Now I am doing the same for Office 2013 White, which I have added to our app. The font and images scale just like with other themes. However the ribbon will display the text right over the buttons. I have tracked this down to a difference in the paint manager's m_nEditHeight variable. Basically, there is a difference in the height of the ribbon, with the white ribbon being too short. The difference appears to me to be between CXTPPaintManager::UpdateFonts() used by CXTPCommandBarsOffice2013Theme (Office2013) and CXTPThemeRibbon::UpdateFonts() used by Office 2007/2010. I should note that we set our own font by calling SetCommandBarsFontIndirect on the paint manager. And that seems to be the key. In CXTPPaintManager::UpdateFonts(), there is a "m_bUseStandardFont" variable that is tested. And the m_nEditHeight is calculated using the m_nFontHeight but only if m_bUseStandardFont is true. Since we set our own font, that flag is false. It looks like to me there should be an "else" clause in the very least that calculates the m_nEditHeight (and probably m_nTextHeight too.) However in CXTPRibbonTheme::UpdateFonts, m_nEditHeight is always calculated using the m_nFontHeight we set. The m_bUseStandardFont member is tested in this API, but the calculations needed to correctly display the ribbon by calculating m_nEditHeight are not avoided if the value is FALSE. So to me, this appears to be a bug in the White theme's paint manager. Either that, or there is something basic I need to do when using Office2013 that we don't have to do with the other themes. I have found some interesting code in CXTPCommandBarsOffice2013Theme::RefreshMetrics, which is also called (It calls UpdateFonts). If I have my system DPI set to 150% (>96 dpi), there is a call to compare DPI settings to the XTP_DEFAULT_DISPLAY_DPI value. If the system DPI is > XTP_DEFAULT_DISPLAY_DPI, the RefreshMetrics code correctly calculates the m_nEditHeight (using m_nFontHeight). That is, if I have high DPI, the previous calculation issue is compensated for and the ribbon displays just fine. I can easily switch between themes on a high-res monitor with no issue - as long as the dpi is > 96. Can someone at CJ take a look at the two sets of paint manager code and confirm if this is a problem? I'm thinking that I can subclass the 2013 PM and create that and set the PM using the command bars SetPaintManager. Then I'd have to copy the RefreshMetrics code and set the m_nEditHeight by just removing that test against the XTP_DEFAULT_DISPLAY_DPI value (just comment out the test). We are using 16.3.x. Perhaps this is fixed in 16.4? I see the release notes mention a number of other issues we see with the Office2013 theme. |
Replies:
Posted By: cpede
Date Posted: 17 February 2015 at 9:52am
|
I would also like to comment on this. When running high DPI it is easy to see in the RibbonSample that the font used on the Ribbon Bar is not scaled correctly. I understand that you compensate from this by manually calling SetFontHeight. I think that the font size should by default follow the DPI setting, setting the font and font size manually should only be if you want to deviate from the defaults. This should work for both the Ribbon Bar and for the Command Bars in general. -cpede ------------- Product: Xtreme ToolkitPro (24.0.0) Platform: Windows 10 (x64) Language: Visual Studio 2017 (C++) |
Posted By: rdhd
Date Posted: 17 February 2015 at 10:40am
Indeed, I agree. Perhaps what is needed is some default behavior that can be turned on or off. As for my changes, they mostly work but testers just let me know yesterday that they can still cause issues. The claim now is that they have managed to cause the icons and text font to return to "normal" size but the ribbon height remains as if the larger icon and text size is still set  So apparently I have more work to do. |
Posted By: astoyan
Date Posted: 21 April 2015 at 10:05pm
|
Hello, I'm glad to inform you that the upcoming version 17.0 will have full DPI support for the majority of components, including Ribbon, Command Bars, Controls, Docking Pane, Task Panel, TabManager, Shortcut Bar, Markup, which will already be available in 17.0 beta scheduled for release in a few weeks. DPI support for other components is under development now and most likely will be added with the next update. Please stay tuned to our updates and once 17.0 beta is out we appreciate a thorough testing and reporting the problems. Thank you. Regards, Alexander Stoyan
|