I have a project with a lot of button bars and a lot of graphic interfaces, the problem I have is that with graphic cards and new high-resolution monitors, when scaling, for example, 150% is set in the screen configuration, the buttons appear with the image very small; the image inside is not re-scaled to 150% like the rest of the application.
There is a series of buttons to which I assign the image in this way:
CImageList ilTest;
ilTest.Create(IDB_IL_DOC, 32, 0, RGB(255, 0, 255));
m_picDoc.SetIcon (ilTest.ExtractIcon (0));
...
Can it be modified in some way so that the button image is scaled in the same proportion as the rest of the interface?
See this article: MFC applications now default to being DPI-aware.
To quote the introductory paragraph:
Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team,
mainly responsible for MFC. I wanted to make you aware of a subtle
but meaningful change that we have made regarding MFC applications in
Visual Studio 2010: all MFC applications are now marked as ‘DPI aware’
by default. This means that your application is expected to handle
various DPI (dots-per-inch) settings, not just the default (96 DPI),
because Windows will not automatically scale the user interface
elements of your application to match the selected DPI of the system.
It eventually links to this article: High DPI Desktop Application Development on Windows which goes into details with some examples.
I admit that I have not delved into addressing the DPI issues in my own projects. It is something I should do.
Related
I have an MFC app that is high dpi aware. The app displays a CTreeCtrl, which properly draws the expand/collapse (e.g. +/-) glyphs properly at different dpi settings. Here is a snippet at 200%.
In order to present a more modern appearance, I've set the tree control's theme to that of Windows Explorer by adding this to the tree control's PreSubclassWindow overide:
SetWindowTheme(m_hWnd, L"Explorer", NULL);
The tree control now draws the expand/collapse glyphs just like Windows Explorer, which is cool. But, the glyphs do not scale at high dpi settings. Here is another snippet at 200%
The theme part size at 200%, - GetThemePartSize(td, NULL, TVP_GLYPH, GLPS_OPENED, NULL, TS_DRAW, &size) - is 32 pixels. Clearly the Explorer themed glyphs are not growing in size as the dpi increases.
Has anyone else run int to this and, if so, did you find a resolution (other than owner/custom drawing the tree control?
Visual C++ 2015.
Thanks in advance...
I figured out that the high dpi issue has nothing to do with setting the Windows theme. CTreeCtrl has a high dpi bug in that the expand/collapse (e.g. +/-) glyphs are not being properly scaled with or without setting a Windows them.
If you call CTreeCtrl::GetItemPartRect at different dpi scales, you will see the returned rectangle's height is scaled (due to the scaled font), but the width isn't. Thus, what I thought was an issue with the theme was only an illusion, because the themed expand/collapse glyphs have more transparent pixels.
Sorry for wasting everyone's time...
I have a Picture Control in my application which is not scaled properly according to the Windows zoom - 100, 125, 150 % etc.
I have done a research but only found a solution for C#, which is handled by a property AutoScaleMode = AutoScaleMode.Dpi;
Can anyone tell me what is the alternative in MFC?
MFC applications automatically default themselves to be DPI aware, this means that it assumes any resizing for bitmaps etc will be handled by the app (e.g. the app may have multiple versions of the same bitmap depending on DPI settings). It makes the app look much neater on scaled machines because the alternative is to automatically scale the whole app which can make it look 'fuzzy'.
You can switch OFF DPI awareness, have a look at this article:
MFC applications now default to being DPI-aware
I am making my app dpi-aware per monitor by setting <dpiAware>True/PM</dpiAware> in the manifest file. I can verify with process explorer that this is indeed working or by calling GetProcessDpiAwareness.
This is all working fine and I can scale anything in the client area fine in my code. However, my only problem is that if I drag my app from a system-dpi monitor to a non-system dpi monitor, the title bar and any system menu would either become too big or too small. This isn't the case for most built-in apps (e.g. calc, edge browser, etc..) so there must be away to scale it properly. Does anyone how the devs at MS did this?
The screenshot below should explain my problem better. Also notice, that the padding between the close, min, and max button is different when it's scaled (96dpi).
Sample app I'm attaching a very simple app that is per-monitor dpi aware.
The Windows 10 Anniversary Update (v1607) has added a new API you must call to enable DPI scaling of the non-client areas: EnableNonClientDpiScaling. This function should be called, when WM_NCCREATE is received. The message is sent to the window's procedure callback during window creation.
Example:
case WM_NCCREATE:
{
if (!EnableNonClientDpiScaling(hWnd))
{
// Error handling
return FALSE;
}
return DefWindowProcW(...);
}
If the application's DPI-awareness context is DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2, then calling EnableNonClientDpiScaling should be omitted, as it won't have any effect, although the function will still return successfully.
From the documentation:
Non-client scaling for top-level windows is not enabled by default. You must call this API to enable it for each individual top-level window for which you wish to have the non-client area scale automatically. Once you do, there is no way to disable it. Enabling non-client scaling means that all the areas drawn by the system for the window will automatically scale in response to DPI changes on the window. That includes areas like the caption bar, the scrollbars, and the menu bar. You want to call EnableNonClientDpiScaling when you want the operating system to be responsible for rendering these areas automatically at the correct size based on the API of the monitor.
See this blog post for additional information about DPI scaling changes in Windows 10 AU.
Does anyone how the devs at MS did this?
This has a pretty disappointing answer. Using Alin Constantin's WinCheat and inspecting the top-level window of Calculator, I see a window size of 320x576, and a client size that is also 320x576.
In other words, Microsoft entirely avoids the problem by suppressing the non-client area of the window, putting everything in the client area instead. Making this work well for you may involve custom drawing of the title bar.
Something worth noting is that Calculator and e.g. Windows Explorer don't use the same colour for the title bars. Calculator doing custom drawing of the title bar would explain that perfectly.
UPDATE:
It is enough to add new <dpiAwarness> declaration to manifest to solve all this mess. Example is here.
Remnants of former investigations (obsolete):
More investigations on the subject.
System setup: two monitors, one is 96 dpi another one is 267 dpi (Microsoft Surface 4).
Testing window is moved to secondary 96 dpi monitor:
Here is rendering (wrong, IMO) with <dpiAware>true/pm</dpiAware> in manifest:
Note huge size of caption bar and wrong sizes of window icons.
And here is correct rendering using <dpiAware>true</dpiAware>
And I suspect that MSDN documentation is plainly misleading about values of PROCESS_DPI_AWARENESS. I do not see any differences in messages and styles between <dpiAware>true</dpiAware> and <dpiAware>true/pm</dpiAware>. The later one just makes caption larger. In both case application receives WM_DPICHANGED message while moving between monitors with different DPI.
Sigh.
The documentation says:
Note that the non-client area of a per monitor–DPI aware application is not scaled by Windows, and will appear proportionately smaller on a high DPI display.
The Microsoft apps that you link to deal with this by removing the non-client area and making the client area cover the entire window.
How to scale font sizes based on current DPI settings in VC++/MFC applications ?
As of now when I change the DPI from 100% yo 150% the font sizes remain the same, although the icons will scale down based on the current dpi ..
Please suggest the best way for above problem.
In Windows Vista and 7, the OS tries to hide the DPI from your program and does adjustments behind the scenes. If you want your program to react properly to DPI changes you must follow the guidelines from Microsoft titled Creating a DPI-Aware Application.
By specifying the text and control sizes in DLU's. That happens by default though, so I assume you are generating dialogs dynamically or from a memory-based DLGTEMPLATE. If you, you're (pardon my French) screwed, because you'll have to muck about with converting DLU's to pixels, a very painful and tedious process. Read the following KB articles:
http://support.microsoft.com/default.aspx?scid=kb;en-us;125681
http://support.microsoft.com/default.aspx?scid=kb;en-us;145994
Don't use DPI for font scaling. Instead, use the settings the user has configured in the "Appearance" section of Control Panel.
You might also want to consider making the font size configurable for just your application.
I wanted to adopt the Ribbon UI for my new project, I know it might be focusing more on the WoW factor than the true use of a Ribbon which is to replace the toolbar clutter. However when I started playing around with resizing the window, checking out some of the features related to automated scaling. After shrinking the window than a minimum width in size the Ribbon UI just disappeared, I even thought this might not exist in commercial software that have already adopted the Ribbon UI. Paint seems to be suffering from the same problem, don't know if Office 2007 or 2010 are also plagued by the same problem.
Paint and the other built-in Windows applications use the scenic Ribbon API that Microsoft is now including in the OS for all developers to use. Presumably, this is the same one you're using for your project. Microsoft Office uses proprietary ribbon controls, invented by the Office team in-house. That explains the difference in behavior.
And yes, it hardly shocks me that the ribbon disappears entirely when you make the window too small for it to appear. Eye candy has that way about it. Consider that the ribbon isn't very useful or functional when there isn't enough space to display its massive buffet of options. You can see that it tries to shrink itself down as much as possible, but you just can't fit 10 pounds in a 5 pound bag. Hiding it altogether seems like just as elegant an option as anything else.
This is spelled out in the Ribbon guidelines, page 76, lines 1026-1027:
Microsoft® Office User Interface Design Guidelines
Guidelines for Licensing the Microsoft Office User Interface
DEFINING GROUP COMBINATIONS FOR RIBBON RESIZING
13.. The entire Ribbon SHOULD completely disappear when the application window is less than 300 pixels wide or 250 pixels tall to provide more space for displaying the document.
Therefore the answer to your question about why it is doing that: it's trying to follow the rules.
What are you going to do with a ribbon that covers your entire window?