views:

59

answers:

1

Hello,

we've got a problem with one of our non dpi aware MFC applications.
If you change the system setting to high dpi (e.g. 120 or 144 dpi), the application icon on the taskbar looks screwed up. Unfortunately, we have to register our own WNDCLASS for the mainframe, and in the WNDCLASS.hIcon member you have to set an icon. This icon is loaded using the LoadIcon function. And that function tries to load the image in a standard size (the same as being returned by GetSystemMetrics(SM_CXICON)), which for 120dpi is 40x40 pixels. That's unfortunate because we do not provide an icon in that size. But there's a workaround for this: Since strangely, the dpi virtualization seems to not be in effect for 120 dpi, GetDeviceCaps(..., LOGPIXELSX) does indeed return 120 dpi and GetSystemMetrics(SM_CXICON) returns 40. So we can catch that and just load the icon in a different size. But for 144 dpi it doesn't work, because now the virtualization seems to be in effect, and we get 96 dpi and 32 pixels, which again cause the icon to look very ugly.
I found out that if I just set the WNDCLASS.hIcon member to NULL, the icon shows up fine. But I wonder if that's ok because according to MSDN:

hIcon
Handle to the class icon. This member must be a handle to an icon resource. If this member is NULL, the system provides a default icon.

So can I count on the icon showing always up even if I set that member to NULL? The other way would be to also load the icon in the correct size but for that I would have to know that the system is actually set to 144 dpi. And there we are at my initial question. Does anyone know if it is possible to determine the system's DPI setting (from within a dpi virtualized application)? Note that I've also thought about doing something dirty like having a dpi aware application tell me the actual dpi and stuff like that, but I wanna avoid such things if possible.

Best regards,

humbagumba

Update:
I found out that setting the WNDCLASS.hIcon member to NULL is not a good idea, because then the icon of the mainframe is replaced by a default icon (even though it looks fine on the taskbar...) - I didn't notice that during my first test.

+2  A: 

You will have to add a manifest to your program (or edit the existing one) to turn DPI Virtualization off. It should look like this:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"&gt;
      <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

That's not unlikely to cause several new problems. Everything you'd want to know about this is covered very well in this MSDN Library article.

Hans Passant
thanks for the link
Alexandre C.
Thanks but I've already been there. This is not really what I'm looking for, since enabling dpi awareness causes too many problems especially at 144dpi. Do you know why the applications behaves like it is dpi aware at 120dpi (e.g. no virtualization and therefore no xp-style scaling)? The article also doesn't mention if it is possible to know what the system's real DPI setting is (without enabling dpi awareness).
humbagumba
DPI virtualization doesn't kick in until the DPI goes past 120. Finding the real DPI requires turning the virtualization off.
Hans Passant
Ok thanks! I guess I'm out of luck then :)
humbagumba