1

I have an application which adds an icon to the notification area (aka the "system tray") using Shell_NotifyIcon. The icon has a context menu with various important commands. When the app runs on the local system, the context menu works fine. However, when the app is run as a Terminal Services RemoteApp, right-clicking the icon does not display the context menu. The various keyboard-based methods for opening the context menu also don't work.

Double-clicking the icon still behaves as expected, so I know it's not totally broken. We need the context menu to work as well, though. Does anybody know what might be wrong?

Edit: One more piece of information: if I press Ctrl+Alt+End to open the Windows Security screen (which lets you log off, lock the session, etc), and then close that screen, the context menu starts working.

Charlie
  • 44,214
  • 4
  • 43
  • 69

1 Answers1

1

It appears that this happens because the application does not receive a WM_CONTEXTMENU notification in the RemoteApp case. The usual WM_RBUTTONDOWN and WM_RBUTTONUP notifications arrive, but that's all. Strangely, if you try to activate the context menu with the keyboard, you also receive WM_RBUTTONDOWN and WM_RBUTTONUP, even though the mouse wasn't involved. Pressing Ctrl+Alt+End appears to resolve this problem; the system starts sending normal WM_CONTEXTMENU notifications. My guess is that this is a bug in the remote desktop client process.

One potential fix would be to trigger the context menu using WM_RBUTTONUP, but that breaks keyboard accessibility, so I don't recommend it.

The workaround I settled on was the following:

  1. When you see a WM_RBUTTONUP notification, set a timer with a short timeout (50-100ms).
  2. When you see a WM_CONTEXTMENU notification, cancel the timer and display the context menu.
  3. When the timer fires, cancel the timer and display the context menu.

This should work for local usage and RemoteApp usage. The timeout value in step 1 needs to be long enough that it doesn't expire before the WM_CONTEXTMENU comes in, but no longer.

Charlie
  • 44,214
  • 4
  • 43
  • 69