Release v16.4.0 - Problems with high DPI desktop

Have you tried with the CJ ribbon sample? Same results?

We have a "2x" icon size option. We call SetFontHeight on the ribbon bar. And we get the command bars paint manager and set m_bAutoResizeIcons to TRUE. That gives us some big icons. We don't have big icons like you do and CJ scales them up.

We have some success with this. However I am chasing an issue with the various Office themes that shows up on buttons that have text under the button. The text position gets messed up and the text either nestles right under the button (touches it actually) or writes over the button. We only saw this after adding Office 2013 and Office 2010 support. And yes, I can duplicate it with their MDI ribbon sample if I start switching between the various themes and then change the font sizes using the options command.

The Office2013 CXTPCommandBarsOffice2013Theme::RefreshMetrics has code in it that adjusts the m_nEditHeight member based on the DPI setting. I don't see the issue I mentioned when I run at a high DPI. The code in the generic ribbon UpdateFonts is different and doesn't seem to do as good a job as what I see with Office2013.

If you find a better approach to getting large buttons I sure would like to know what it is. Oleg helped us with our initial implementation but that guru seems to have moved on. We use this not just for high dpi, but for very wide monitors too (we define as > 1600 pixels wide).


    // set the ribbon bar height to enlarge most of the UI there
    pRibbonBar->SetFontHeight(dwFontHeight);// Usually 20 or greater

    // tell CJ to scale up the icons when necessary
    // NOTE: Only allow scaling in HiRes mode.  Otherwise, the slightly larger font used in Japanese
    // will scale the icons up in that environment & look blurry.
    pCommandBars->GetPaintManager()->m_bAutoResizeIcons = bHiRes;

    // set the font on command bar controls (buttons, QAT, etc)
    if (CXTPRibbonTheme* pPaintManager = (CXTPRibbonTheme*)pRibbonBar->GetPaintManager())
    {
        if (CFont* pFont = pPaintManager->GetRibbonPaintManager()->GetTabPaintManager()->GetFont())
        {
            LOGFONT lfFont = {0};
            if (int nRC = pFont->GetLogFont(&lfFont))
            {
                lfFont.lfHeight = dwFontHeight > 0 ? 0 - dwFontHeight : dwFontHeight;

                // The Codejock calls below to change the font will alter the font structure
                // passed to them.  They monkey with it while coming up with the vertical font
                // that they hold, so making successive calls with the same structure yields
                // rotated text in the latter cases.  I consider the alteration more than a
                // little rude, especially since it took me quite a while to figure out what
                // they were doing.  Therfore, make a fresh copy of the font data for each call.
                LOGFONT lfTab = lfFont;
                LOGFONT lfGroup = lfFont;
                LOGFONT lfButtons = lfFont;
                LOGFONT lfCommandBars = lfFont;

                // tab captions (per Oleg)
                pPaintManager->GetRibbonPaintManager()->GetTabPaintManager()->SetFontIndirect(&lfTab);

                // group captions (per Oleg)
                pPaintManager->GetRibbonPaintManager()->m_fontGroupCaption.SetCustomFont(&lfGroup);

                // ribbon text (buttons, QAT, etc)
                pPaintManager->SetCommandBarsFontIndirect(&lfButtons);

                // The command bars paint manager needs to know about this, too.  It will get
                // used for context menus.
                pCommandBars->GetPaintManager()->SetCommandBarsFontIndirect(&lfCommandBars);

                // tell Codejock about the changes
                pPaintManager->GetRibbonPaintManager()->RefreshMetrics();
                pPaintManager->RefreshMetrics();
            }
        }

Nice!