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.