8

The windows taskbar contains an area called the "Notification Area" or "system tray", where small icons appear for apps that want to run in the background and/or show system notifications. When the taskbar is on the bottom or the top of the screen, this area appears on the right.

In multi-monitor setups, this "Notification Area" only appears on one of the taskbars, even if the taskbar is set to show on all monitors. You can control which display the Notification Area appears on by dragging the taskbar to whichever display you prefer.

My question is:

Is there any straightforward API to find the screen, location, and orientation of the taskbar "Notification Area"?

I found one example which searches for the Shell_TrayWnd window handle, and then does math on its position try and figure out what orientation it is in (i.e. which edge of the screen the taskbar is on).

However, this is very fragile, as it depends on the current UI design of the windows taskbar.

Windows 10 introduced a new common toast notification system, including a snazzy notification flyout. However, even when you've moved the Notification Area to a different monitor, including the button which opens and closes the system notification flyout, the flyout itself is still displayed on the "primary monitor".

The above suggests there might be no way to do this, as if Microsoft's own notifications don't follow the Notification Area, there may be no way to practically do so. However, Microsoft documentation of the notification area suggests the very sensible idea that toast should display near it.... I think they just didn't think about the multi-monitor case.

microsoft toast location guideline

David Jeske
  • 2,306
  • 24
  • 29
  • I'm not entirely convinced, that Microsoft's decision/implementation/bug to always show toast notifications on the primary screen is any indication, that it's impossible to do what you want. For one, the toast implementation is very likely part of the Windows Runtime/Universal Windows Platform, and runs in a sandboxed environment, that doesn't have access to the full Windows API. Or it might be a conscious decision, for whatever reason. Or a bug. Nothing to help you solve your immediate issue, but just a comment highlighting, that this may not be a dead end after all. – IInspectable Dec 01 '17 at 18:46
  • *A winning answer would give a RECT or POINT that could serve as an anchor for a window to be opened when clicking the icon in the system tray* - but correct answer already exist - inside *wParam* will be point. simply need not forget call `Shell_NotifyIcon(NIM_SETVERSION, &ni);` with `NOTIFYICON_VERSION_4`. possible and use [`Shell_NotifyIconGetRect`](https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shell_notifyicongetrect?redirectedfrom=MSDN) – RbMm Jan 28 '21 at 21:32
  • wParam of what message? I'm probably missing something obvious, but I don't see how calling Shell_NotifyIconXYZ() starts sending Windows messages, or I just don't know what WM_ to be handling in the WinProc, which I assume is what you mean with position being contained in wParam. – Tim Beaudet Jan 29 '21 at 15:56
  • @TimBeaudet - `Shell_NotifyIcon` take pointer to [`NOTIFYICONDATA`](https://learn.microsoft.com/en-us/windows/win32/api/shellapi/ns-shellapi-notifyicondataa) and here exist `uCallbackMessage` - *The system uses this identifier to send notification messages to the window identified in hWnd*. as result we and got (x,y) in *wParam* on `WM_CONTEXTMENU` and in all mouse messages between `WM_MOUSEFIRST` and `WM_MOUSELAST` – RbMm Jan 30 '21 at 11:54

1 Answers1

1

If you want to show some window as a response to tray icon action there is no need to manually search for tray location because corresponding tray message will contain cursor coordinates as wparam. Even if event was generated by keyboard then message will contain icon upper left corner coordinates. See NOTIFYICONDATA structure documentation

user7860670
  • 35,849
  • 4
  • 58
  • 84