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.
Related
I'm trying to properly DPI scale an application in C++ and I'm having trouble getting this to work with the File Picker window created from calling OPENFILENAMEW from commdlg.h.
I'm using three monitors: two with 1.0 dpi and one with 2.5 dpi. For me, the file picker only opens with 1.0 DPI regardless of what window my application is in. So when I drag the file picker to the 2.5 dpi monitor, the window is so small is hard to read. I can only get it to scale with 2.5 dpi when I disconnect the other monitors. I looked at the documentation for OPENFILENAMEW and there is a flag to allow the dialogue to resize manually but that's about it.
It has to register the dpi at some point to scale but I just can't find it.
Does anyone know how to do this?
Enabling per monitor DPI awareness in Manifest settings didn't solve this completely but it did lead me to the answer I was looking for! So the issue that persisted was that once the file-picker window was created, it kept it's DPI scale from its original window even after moving it to a window with different DPI.
Apparently the options in Manifest don't support this and neither does the SetProcessDpiAwareness function in the shellscaling api, which can be used to set that Manifest setting programmatically.
However, the SetProcessDpiAwarenessContext from winuser.h has one more option that the others don't: DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2. This can only be used on windows machines with the Creators update (named Redstone 2) and you can check that to do DPI scaling right when you can, and wrong but as good as possible when you can't:
if (IsWindowsVersionOrGreater(HIBYTE(NTDDI_WIN10_RS2), LOBYTE(NTDDI_WIN10_RS2), 0)) {
SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2);
}
else {
SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE);
}
And this works!
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 should design a dialog with size 640*480 ,which can be used on 800*600 resolution.
At present my dialog size is 411*292 ,look wise this itself looks good enough ,but actually I was
asked to design dialog with the size I mentioned above.I tried that also but that dialog is too biger
than my earlier dialog of 411*292 size.
while using in 800*600 resolution or my dialog seems to be bigger and not able to see some of my controls
This is size of my dialog,
IDD_DIALOG_MYPAGE DIALOGEX 0, 0, 411, 292
can anyone please let me know how to design a dialog with 640*480 (which should not be bigger).
And how can I make my application to fit to any resolution so that all the controls on the dialog should be visible.
Dialogs are scaled in Dialog Units and Dialog Units scale upon the current UI settings and depend upon the System font. So if the user selects a larger UI representation your Dialog will grow too.
Best advise 1 I could give: Size all you controls by youself. Pick a font you like. Set it to the Control, calculate the positions ofthe new controls and use SetWindowPos/MoveWindow.
Only in this case you have full Control.
You may also use a fixed font size in the Dialog resource, but alos this font scales upon the DPI untis selected for the Screen...
So best advise 2 I could give: Scale upon the DPI/UI Settings and Show the dialog n a size that the user wants too, thats what a normal dialog will do...
You're in for a world of pain. If I understand correctly, you're being asked to make a dialog that will always be 640*480 pixels. It seems like whoever is asking hasn't kept up with UI development since 1995. 'Pixels' are meaningless in 2014. First, the units in resource files are in 'DLUs', 'Dialog Length Units'. See e.g. http://blogs.msdn.com/b/oldnewthing/archive/2004/02/17/74811.aspx and support.microsoft.com/kb/125681 for some starters on how to convert one to the other. However, with high DPI displays these methods are insufficient. Now it doesn't just depend on the size of the system font any more, but also on the settings the user has selected for how big to display 'things' on various monitors, whether to differentiate between monitors at all, etc. See for a start http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266%28v=vs.85%29.aspx . But beware, because there are updates to these API's - e.g. Win7, Win8 and Win8.1 all have new features in this regards.
All of this of course doesn't help you. It's not terribly hard to make a dialog that will fit on 640x480 and up; just make it as small as possible. But this part: "And how can I make my application to fit to any resolution so that all the controls on the dialog should be visible." is really difficult. Does 'any' mean 'also smaller than 640x480'? And does 'fit' mean that it should look 'native' also on higher resolutions? Should the dialog be resizable? You can either go with the simple and robust approach suggested by xMRi above, or you will have to ask whoever is writing your spec to be more clear about what they want, keeping in mind all the things I outlined above.
I have a CListCtrl control (or a ListView in Win32) that is created with LVS_REPORT style.
I am intending to display icons in its items as such:
But the question is what size of icons do I need to make and load?
Let me explain. From the old Win32 samples, I can see that everyone creates image lists with 15x15 pixel icons. But the issue with those is that it looks horribly pixelated on any modern PC with higher DPI settings. Thus I was looking for a dynamic way to determine the appropriate size of image lists for the CListCtrl.
And also the first part of the question, what icon size should I make originally?
EDIT
PS: Since DPI scaling came up, how do you find it out? I'm currently using the following approach:
//No error handling for brevity
HDC hDC = ::GetDC(hAppsMainWindowHandle);
int nCx = ::GetDeviceCaps(hDC, LOGPIXELSX);
int nCy = ::GetDeviceCaps(hDC, LOGPIXELSY);
::ReleaseDC(hAppsMainWindowHandle, hDC);
//I technically get horizontal & vertical scaling --
//can those be different?
double scalingCx = (double)nCx / 96.0; //1.0 = 100%
double scalingCy = (double)nCy / 96.0;
Is font scaling something different?
A list view uses a "small" or "large" image list depending on its mode. In report mode, it uses the "small" image list. You can use GetSystemMetrics() to get the dimensions of "small" images using the SM_CXSMICON and SM_CYSMICON metrics (use SM_CXICON and SM_CYICON for "large" images).
Note that the returned values will be virtual/scaled if your app is not DPI-aware, so to get accurate values, make sure it is DPI-aware via SetProcessDPIAware(), SetProcessDpiAwareness(), or a DPI manifest.
Update: I just ran across this function, might be useful for you when writing a DPI-aware app:
LoadIconWithScaleDown()
Make larger images and let the API scale them down to smaller sizes.
The report style list view wants small icons, that is icons with SM_CXSMICON by SM_CYSMICON metrics. Assuming your app is high DPI aware, then the actual value of these metrics depends on the user's chosen font scaling or DPI setting. So up front you cannot know what size icons should be used. You have to query the system metrics at runtime, and use appropriately sized icons.
Now, what size icons you include in your executable depend on what DPI settings you wish to support. Back in XP days you could reasonably expect to encounter 100% and 125% font scaling. These days, high density display panels are common and you really need to support larger ratios. At least 150% and 200%, and quite probably 175%.
The closest I can find to guidelines is in this MSDN article: http://msdn.microsoft.com/en-US/library/windows/desktop/dn742485.aspx
This article was written around the Vista time frame and already shows its age. I think you have to use these articles as a guide and adapt to the hardware of the day.
You will also find that people run their machines at font scaling values in between the round numbers listed above, and in the article I link to. One of my colleagues runs at 120%. Interestingly this has highlighted various bugs in our code so it's always useful to have someone dog-fooding your program.
When you build your image lists at runtime, size them according to system metrics. And try to avoid scaling icons. For instance, if system metrics suggest an 18px icons, and you only have 16px and 20px icons, then make a new 18px icons. Fill the image with transparent pixels, and blit the 16px icon into the middle of this 18px image. Make the icon out of that. This approach will avoid aliasing problems.
I'm working on a Qt project and I've noticed a persistent problem with some GUI forms. The form looks fine on KDE (bottom picture) and Windows , but when the app runs on anything GNOME3-based (like Unity or GNOME3 itself) some parts of the form are hidden from view. (Top picture, everything below the Sort Ascending radio button is cut off)
The problem seems to be with how Qt layouts handle large font sizes. If the user is using normal-sized system font (<= 10pt) everything works fine. If they are using larger fonts, the form is not large enough to accommodate everything. Other forms affected by this bug are merely crowded, but that isn't as serious as having vital controls out of bounds. The layout doesn't want to resize itself to take advantage of new space if I enlarge the dialog. Is there an easy way to make it do this or do I need to hard-code it? Originally the code prevented dialog resizing during runtime, but restoring that functionality didn't fix the bug. Even if the dialog can expand, the problem is the layout won't expand with it.
Up until now, I've made all affected forms oversized to compensate for this bug, but it looks strange to have the dialogs much bigger than they need to be on Windows and KDE systems where the font is the proper size. Is there a way to cause an affected dialog/layout to resize itself so everything fits properly at runtime? If so, how would the program detect it when parts of the GUI are out of bounds? I would prefer not to force a certain font size (some people may prefer large fonts due to vision problems).
Thanks in advance for help.
The fix for this is using a different approach when displaying forms. A more dynamic way as I'll describe. I've successfully used this approach on Windows with 96 and very high DPI modes (over 120).
1.
Query the OS and get the user's chosen font for a particular system item; say the font used for the window caption or system dialog boxes. Also you could allow the user to choose their font later if they desired. Use True Type fonts when doing this if possible.
2.
Using that font, construct a string object that you'll use for a label or edit control (I don't know what this is for QT, for Windows it is GetTextExtentPoint32) and pass it to a system function to determine the width and height of the string for your environment.
3.
Given the above value, place the control and dynamically resize the form with the padding all around the control as you like. For buttons you might always add a certain percentage of pixels above and below the button to taste.
4.
For graphical elements like Bitmaps and jpegs, again query the OS for the current DPI settings of the monitor and use larger, pre-made resources. Naturally, all text around theses elements will be dynamically placed on the fly.
Note that on Windows you'll need to mark your exe as high dpi aware using a manifest.