Release v16.4.0 - Problems with high DPI desktop
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=22442
Printed Date: 25 December 2024 at 12:06pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Release v16.4.0 - Problems with high DPI desktop
Posted By: Alex G.
Subject: Release v16.4.0 - Problems with high DPI desktop
Date Posted: 29 October 2014 at 4:38am
|
Hello, Thank you for this new release. I think there's still a problem related to high dpi resolution desktops. Let's say I have a set the scaling level to 125%. The Ribbon itself looks good, fonts layout etc. But it looks like that the icons are all on 32x32 pixel and scaled up which doesn't look very well. We have also 48x48 pix versions of our icons and they are also set to the XTPImageManager. Am I'm doing something wrong ? Please check out the attached picture. Best regards, Alex  |
Replies:
Posted By: Marco1
Date Posted: 29 October 2014 at 5:52am
|
Have you tried with the CJ ribbon sample? Same results? ------------- Product: XTP 18.3.0 on VS 2017 Platform: VS 2017 / Windows 10 (64bit) |
Posted By: Alex G.
Date Posted: 05 November 2014 at 5:26am
|
Sorry for the late reply. No, it doesn't help. Is there a possible way to set larger icons, lets say 48x48, and let scale them down ? The RibbonBar layouter doen't work very well with icons larger than 32x32  Alex |
Posted By: rdhd
Date Posted: 20 January 2015 at 9:41am
|
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(); } } |
Posted By: astoyan
Date Posted: 21 April 2015 at 10:01pm
|
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
|
Posted By: Alex G.
Date Posted: 22 April 2015 at 3:08am
| Nice! |