I've got a dialog box where I need to display the standard Information icon. Here's my RC code:
ICON "",IDC_ICON_INFORMATION,18,70,21,20
I process the WM_INITDIALOG message as follows:
HICON aIcn = LoadIcon(NULL, IDI_INFORMATION);
SendDlgItemMessage(m_hWnd, IDC_ICON_INFORMATION, STM_SETICON, (WPARAM) aIcn, 0);
Everything works great under 96 DPI: the static control displays a 32x32-pixel icon.
However, when I switch to higher DPI's (through right-clicking on the Desktop, choosing Screen resolution, and clicking Make or other items larger or smaller) the icon does not scale! Since everything else scales nicely, the icon looks visually much smaller than the neighboring text. I would expect that on 144 DPI (150%) the icon dimensions will be 48x48 pixels. I did declare my application as DPI-aware through an XML manifest.
The damnedest thing is that when I use my own custom-made icon (also coming from the RC file), everything scales perfectly. Furthermore, the MessageBox function called with the MB_ICONINFORMATION flag does display a scaled version of the icon, as well.
Given these thoughts, I assume of the following:
The static control with the SS_ICON style can display scaled versions of icons.
The icon resource that contains the standard Information icon has a scaled version of the icon (48x48).
What am I doing wrong then?
Use LoadImage() instead of LoadIcon(), and specify the cxDesired and cyDesired params with the values you get from GetSystemMetrics(SM_CYICON) and GetSystemMetrics(SM_CXICON).
Or maybe just declaring your app as DPI aware could be enough? You can try that easily by simple creating a text file making it a manifest file.
See the example in the remarks section for the SetProcessDPIAware API
Related
When adding a system tray icon from in Windows there are two versions of API that we can pass to Shell_NotifyIcon() via NOTIFYICONDATA structure. There are subtle differences between the two API, and these are not listed anywhere on MSDN. It took me some effort to figure out some of the differences, which I am going to share now. Improvements/additions to the answer are always welcome.
PS: This question is purely for sharing what I have learnt over last few days experimenting with windows DPI scaling.
uVersion member of the NOTIFYICONDATA structure can have 3 possible values, representing the version of the API being used to create the taskbar icon.
0 Use this value for applications designed for Windows versions prior to Windows 2000.
NOTIFYICON_VERSION Use the Windows 2000 behavior. Use this value for applications designed for Windows 2000 and later.
NOTIFYICON_VERSION_4 Use the current behavior. Use this value for applications designed for Windows Vista and later.
When it comes to message handler for the tray icon, the wParam, and uParam have the differences as illustrated in the following image.
Notice that in NOTIFYICON_VERSION_4 the wParam gives X, and Y coordinates of various events, but there is no provision for getting the coordinates in NOTIFYICON_VERSION. This gives rise to an interesting behaviour (which was a cause of a BUG I was trying to solve). If you use NOTIFYICON_VERSION, and then invoke the context menu of the tray icon, then the mouse cursor, wherever it may be while you are invoking the menu, gets placed right at the center of the tray icon. Even if you use keyboard (WINDOWS+B) for invoking context menu of the icon, the mouse cursor still moves to the icon.
This may not be of particular interest to you until you look at this particular BUG I am trying to solve in Pico torrent application.
Here is the scenario.
OS : Windows 10
Application isn't per-monitor DPI aware, but is system level DPI aware.
There is an initial value of Desktop scaling set, say 150%, when the user logs in.
Pico torrent is running.
DPI scaling value is changed to, say 125%
Pico torrent's context menu is invoked
The context menu will not be displayed at its proper place, and will be displaced a little, showing a deviance.
See the following images to understand what's happening.
The problem is that although MSDN says that GET_X_LPARAM(wParam), and GET_Y_LPARAM(wParam) should give correct values in the handler of tray icon, but it doesn't, in the presence of DPI scaling (i.e. for a change in DPI scaling without doing a sign out and sign in). On the other hand the API GetCursorPos() returns the correct value of mouse cursor coordinates. Note that NOTIFYICON_VERSION_4 along with GetCursorPos() will not work, since the context menu can be invoked using keyboard, at which the mouse cursor can be anywhere on the screen(s).
So, how do you combine all the knowledge just learnt to display the tray icon's context menu correctly when DPI scaling is done in the manner above, without making you application per-monitor DPI aware (for per-monitor DPI aware applications GET_X_LPARAM(wParam), and GET_Y_LPARAM(wParam) always return correct value)?
Use NOTIFYICON_VERSION instead of NOTIFYICON_VERSION_4, this will position the mouse cursor at the tray icon when context menu is invoked, and then use GetCursorPos() to get mouse cursor's position. Display the context menu using TrackPopupMenu() with the coordinates.
PS: In the example above the DPI scaling value is changed from 150% to 125%. The context menu deviance is more pronounced when DPI scaling is done from a bigger value to a smaller value, when your tray icon area is on lower right of the screen. This is because when DPI scaling is done, and windows magnifies UI elements which are not per-monitor aware, using DPI virtualization, then things move right-wards, and down-wards. eg. if in an application a windows rectangle is (0,0,100,100) (screen coordinates), then after magnification to 150%, it may become (0,0,150,150). Now for tray icon's menu, if you specify coordinates which lie beyond bottom-right of the screen, then the OS will still display is at a bottom right position which lies inside the screen, and which ensures that menu is displayed properly. eg. if a screen is 1920x1080, and TrackPopupMenu()is given (10000,10000) for menu, the menu will still be displayed inside the 1920x1080 screen rectangle. Thus increasing DPI scaling will not move the context menu any further, if it has already reached the right-bottom most position.
#sahil-singh you are right about it, and I agree with everyone else that your application should be DPI aware, but when this is not a point here.
I had a similar issue where my application is (still) not DPI aware and GET_X_LPARAM(wParam) will return non-virtual coordinates. After passing this value to the TrackPopupMenu() I get wrong position on the screen.
The best way is to use GetMessagePos() instead of wParam. In this case, Windows will give you new DWORD with virtual coordinates and then use GET_X_LPARAM/GET_Y_LPARAM to get a values that you can pass to the TrackPopupMenu().
This seems to (2 years later in 2019) be documented on MSDN:
NOTIFYICONDATAA structure
uCallbackMessage
Type: UINT
When the uVersion member is either 0 or NOTIFYICON_VERSION, the wParam parameter of the message contains the identifier of the taskbar icon in which the event occurred. This identifier can be 32 bits in length. The lParam parameter holds the mouse or keyboard message associated with the event. For example, when the pointer moves over a taskbar icon, lParam is set to WM_MOUSEMOVE.
When the uVersion member is NOTIFYICON_VERSION_4, applications continue to receive notification events in the form of application-defined messages through the uCallbackMessage member, but the interpretation of the lParam and wParam parameters of that message is changed as follows:
LOWORD(lParam) contains notification events, such as NIN_BALLOONSHOW, NIN_POPUPOPEN, or WM_CONTEXTMENU.
HIWORD(lParam) contains the icon ID. Icon IDs are restricted to a length of 16 bits.
GET_X_LPARAM(wParam) returns the X anchor coordinate for notification events NIN_POPUPOPEN, NIN_SELECT, NIN_KEYSELECT, and all mouse messages between WM_MOUSEFIRST and WM_MOUSELAST. If any of those messages are generated by the keyboard, wParam is set to the upper-left corner of the target icon. For all other messages, wParam is undefined.
GET_Y_LPARAM(wParam) returns the Y anchor coordinate for notification events and messages as defined for the X anchor.
My application is a Windows Forms one.
I tried using the windows wallpaper, but this depends on the "Fill", "Stretch", "Fit" or "Tile" settings.
I just need the image as it is on the desktop, but including the part "under" the taskbar, because this part is visible in case of transparent taskbar.
Why I need this?
Because I have a tray application which slides from under the taskbar when opening. And I need to set a mask there, so it can't be seen sliding, until it reaches the top of the taskbar. Again, this is only a problem when the taskbar is transparent.
I am not sure if I understood your question correctly. But to me, it seems that you need the image that has created wallpaper. If it seems easier, take a look at registry entries at following location:
HKEY_CURRENT_USER\Control Panel\Desktop
This will give you the path, size, tile/no tile etc. information for the wallpaper.
There is a Win32 function called PaintDesktop you could try but unless I'm misunderstanding things you should be able to just adjust the height of your window so it is never really behind the taskbar...
Why I need this? Because I have a tray application which slides from under the taskbar when opening. And I need to set a mask there, so it can't be seen sliding, until it reaches the top of the taskbar. Again, this is only a problem when the taskbar is transparent.
The problem here is that you're starting the slide up from the bottom of the entire screen, rather than starting from the bottom of the screen's working area (i.e., the top of the taskbar). That's why you're seeing the pop-up window slide up behind a transparent taskbar.
Luckily, the solution is much simpler than obtaining the desktop background and/or doing any type of masking. It's also much faster, and it's always good that your eye candy isn't unnecessarily taxing the user's computer.
All you need to do is determine the coordinates of the screen's working area, which is defined by Windows as the area that can be used by applications, not including the taskbar and other side bars. You can obtain this information easily in WinForms by querying the Screen.PrimaryScreen.WorkingArea property. This will return a Rectangle that corresponds to the primary screen's working area. Since you know that the taskbar is always displayed on the primary screen, this is exactly what you want.
Once you have the coordinates of the primary screen's working area, start your pop-up window's slide from the bottom of that.*
This is a good lesson of why you should always include an explanation of why you want to accomplish something. There's often an even better way that you haven't thought of.
*Of course, I'm ignoring the fact that a user might not have their taskbar positioned at the bottom of the screen. You can put it on either side or even on top. It sounds to me like you haven't considered this in your question, either. If this is an app that you're writing only for yourself or for a controlled environment where you can be sure that no one has their taskbar in non-default positions, that might be OK. But if you're writing software to distribute to a wider audience, you will need to take this into account. The rcWork coordinates will be correct, regardless of where the taskbar is positioned, of course, but you will need to know whether to start the pop-up window's slide from the bottom, the left side, the right side, or the top.
My purpose is to size a window to a width/height greater than the size of my physical screen programmatically under Win32. How can I do this?
On my systems it seems the maximum size of a given window is bound by the size of my screen whether programmatically or whether sizing manually by dragging the sizing cursor.
I have tried programmatically with SetWindowPos() and MoveWindow() and both cap the size of the target window. Oddly I know some people do not have this 'cap' so I wonder whether this is perhaps due to some OS setting (registry). Does anyone know something about this? Or perhaps some way to workaround it?
// Edit: new developments
I am testing on Windows XP and Windows 7. The graphics cards I'm using are a NVIDIA Quadro NVS 290 (256MB) and a Geforce 9800GT (1GB). After further investigation it looks like Windows is intercepting the message and fiddling with the parameters. For example, if you call SetWindowPos to make a target 2000x2000 it will only receive a WM_SIZE for the capped x/y.
Implement a message handler for WM_GETMINMAXINFO to stop Windows from applying the sane default behavior:
case WM_GETMINMAXINFO: {
DefWindowProc(hWnd, message, wParam, lParam);
MINMAXINFO* pmmi = (MINMAXINFO*)lParam;
pmmi->ptMaxTrackSize.x = 2000;
pmmi->ptMaxTrackSize.y = 2000;
return 0;
}
Windows with a thick frame (to allow user resize) are restricted from growing larger than the desktop.
Try SetWindowLong() clearing the THICKFRAME (0x40000) flag.
The following should allow programatic sizing, but the user will lose the ability to resize. If you add the Thickframe back after sizing, the user can resize, but when he does so the window will immediately shrink back to the desktop limited size.
The following is from some csharp code that also removes all borders, caption, etc:
WS style = (WS)GetWindowLong(ptr, GWL_STYLE);
style = style & ~WS.BORDER & ~WS.ThickFrame & ~WS.SYSMENU & ~WS.CAPTION | WS.POPUP;
SetWindowLong(ptr, GWL_STYLE, (int)style);
A good tool to play with window settings is uuSpy.
It's like Microsoft Spy++, but allows you to modify settings like THICKFRAME.
Yes, windows can be larger than the screen (or even the sum of all your monitors). Windows can also be positioned off-screen (which some applications do as a hack to hide while remaining active).
Perhaps the Windows 7 desktop manager is kicking in and trying to "dock" those windows to the edges of your screen for you.
You might try using the slightly lower-level API SetWindowPos, which gives you control over notifications, z-order, and other stuff.
You can get a window to be larger in resolution (and even way way larger) than your screen, using the 'Infinte Screen" software:
http://ynea.futureware.at/cgi-bin/infinite_screen.pl
Here's how to use it:
Download it, run it.
In the Oversize tab, choose the Windows you want to enlarge.
Give it the Width and Height you want. Done!
Just in case you need a large screenshot (that's how I ended up here):
If you want to get a screenshot of the window, you've got a screenshot option in the same Oversize tab. (Because screenshots are normally no bigger than the screen size, even if the window is larger). Another (and better) way to screenshot the window is using Greenshot, as you can save them in .tiff and directly watching the window.
I am trying to create a full-screen control panel window with many controls: buttons, sliders, list boxes, etc.
I can create a dialog window and add controls to it, but everything is scaled in dialog units. I just want to create a window in the GUI editor that is scaled in pixels, not derived units like dialog units.
I can sort of lay out all the controls in the GUI editor and then resize the window programmatically to full-screen using SetWindowPos, but the dialog window in the GUI editor will not look the same as the final product. I want it to be WYSIWIG in the GUI editor.
This is the front end for a small dedicated instrument control computer running XP. The SDK is written in MFC. I have to add and change controls frequently. The screen is small, 7" # 800 x 600, so of course I am developing the program on a different computer. I don't want the program window to change when I change monitors -- I want it fixed at 800 x 600, and I want the controls to be fixed in size and layout as well.
There must be a way -- this is more basic than the default functionality.
Thanks.
Dialog Units are based on properties of the font used by the dialog. A horizontal dialog unit is equal to 1/4th the average width of the current font.
A vertical dialog unit is equal to 1/8th the average character height of the current font.
I'd recommend using method 2 (MapDialogRect() for a 4 x 8 dialog) to figure out how many DLUs 800x600 corresponds to on your output display then make a reference form equal to that size. You can later use that reference form while you're designing.
p.s.-I'm glad Visual Studio no longer emphasizes dialog units since they were always a pain to deal with.
Thanks. I was able to make a reference form by just resizing the form manually in the GUI editor over and over again until it exactly filled the screen... No kidding that dialog units are a pain. From your response, I guess in the current Visual Studio there is a better way to do this? (This is my first experience with Windows programming).
My application draws all its own window borders and decorations. It works fine with Windows taskbars that are set to auto-hide, except when my application window is maximized. The taskbar won't "roll up". It will behave normally if I have the application not maximized, even when sized all the way to the bottom of the screen. It even works normally if I just resize the window to take up the entire display (as though it was maximized).
I found the problem. My application was handling the WM_GETMINMAXINFO message, and was overriding the values in the parameter MINMAXINFO record. The values that were in the record were inflated by 7 (border width) the screen pixel resolution. That makes sense in that when maximized, it pushes the borders of the window beyond the visible part of the screen. It also set the ptMaxPosition (point that the window origin is set to when maximized) to -7, -7. My application was setting that to 0,0, and the max height and width to exactly the screen resolution size (not inflated). Not sure why this was done; it was written by a predecessor. If I comment out that code and don't modify the MINMAXINFO structure, the Auto-hide works.
As to why, I'm not entirely sure. It's possible that the detection for popping up an "autohidden" taskbar is hooked into the mechanism for handling WM_MOUSEMOVE messages, and not for WM_NCMOUSEMOVE. With my application causing the maximize to park my border right on the bottom of the screen, I would have been generating WM_NCMOUSEMOVE events; with the MINMAXINFO left alone, I would have been generating WM_MOUSEMOVE.
This is dependant on whether 'Keep the taskbar on top of other windows' is checked on the taskbar properties. If it's checked then the taskbar will appear.
But don't be tempted to programmatically alter this setting on an end users machine just to suit your needs, it's considered rude and bad practice. Your app should fit whatever environment it gets deployed to.