0

I have a custom shortcut filetype registered that defines custom verbs and handles them by implementing IContextMenu. Thus, when you click on one of these shortcuts in the Start Menu, all of the processing of that click gets routed to my IContextMenu implementation (with the default verb). The implementation launches a trampoline process, which identifies what action should be taken and then launches the actual application the user wants.

What I am finding is that the Start Menu does not close when the shortcut is clicked on. The process that gets ultimately launched shows its window and begins processing, but the Start Menu is still open and the shortcut can be clicked on a second time, and other shortcuts can be clicked on.

How can I programmatically tell the Start Menu, "Your job is done, the user did in fact make a selection, you can close now"?

Jonathan Gilbert
  • 3,526
  • 20
  • 28
  • I have tried, as a test, altering my handler to directly launch Notepad with a fully-visible window, and the Start Menu still doesn't close. So the cause is more than just launching a trampoline process with no visible window. – Jonathan Gilbert Nov 27 '19 at 16:52
  • I sincerely hope to find a proper solution to this, but for now I've implemented what I'm hoping is a robust heuristic of retrieving the foreground window, looking up the process ID that owns it, attempting to open the process ID, then, if that succeeds, query its name and compare against `StartMenuExperienceHost`, otherwise check the window class and compare against `Windows.UI.Core.CoreWindow`, and then whichever branch was taken, if the test passes, using `SendInput` to inject an Esc keypress into the input queue. Kludgy as hell but it seems to work. – Jonathan Gilbert Dec 03 '19 at 05:47

0 Answers0