Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a <code>WM_NCPAINT</code> message and passes it on to <code>DefWindowProc</code>, which is part of User32.dll - the core window manager code. </p> <p>Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means <em>changing</em> the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing <em>all</em> of the non-client area. </p> <p>And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.</p> <p>That's just <em>one</em> of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!</p> <p>It would be a far less difficult job to <em>echo</em> the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is <em>very</em> common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application. </p> <p>What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload