Windows 系统范围内的 Mac 风格菜单
我是 Mac 用户和 Windows 用户（曾经我是 Amiga 用户）。我更喜欢Mac（和Amiga）采用的屏幕顶部菜单栏方法（/采取），并且我想为Windows编写一些可以提供此功能的东西（并且可以工作）与现有应用程序）。
我知道这有点雄心勃勃，特别是因为这只是一个令人心痒痒的项目，而且由于家庭的不断壮大，我的空闲时间几乎为零。我几年前对此进行了研究，并得出结论，这非常困难，但那是在 StackOverflow 之前;)
我认为我需要做这样的事情才能达到预期的结果：
创建将是的应用程序位于所有其他窗口之上的自定义菜单栏。自定义菜单必须提供所有功能来替换标准 Win32 窗口内菜单。没关系，它只是一个行为类似于菜单栏的应用程序。
它将不断枚举窗口以查找正在创建/销毁的窗口。它将枚举子窗口集合以查找菜单栏。
它将构建一个代表窗口中菜单选项的菜单。
它将隐藏窗口中的菜单栏，并将所有直接子窗口向上移动相应的像素量。它也会缩短窗口高度。
它将捕获应用程序发送到其菜单的所有消息，以相应地调整自定义菜单。
它会不断轮询当前活动窗口，因此可以在必要时切换菜单。
它当发生菜单点击时，它会使用真实菜单子控件的 hwnd 向窗口发送一条消息。
当发生菜单点击时，它会使用真实菜单子控件的 hwnd
就是这样！容易，嗯？不，可能不会。
我真的很感激 Win32 专家提供的关于从哪里开始、想法、陷阱、关于是否可能的想法的建议。我白天不是一名 Win32 C++ 程序员，但我已经做了一些工作，并且我不介意深入研究 MSDN 平台 SDK 文档...
（我还有另一个想法，创建一个任务栏对于多显示器设置中的每个屏幕，并显示桌面的活动窗口 - 但我认为我可以在托管代码中做到这一点，并为自己节省大量工作）。
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Mac 顶部菜单与 Windows 方法之间的真正区别不仅仅在于菜单：- 它是如何使用菜单来破解打开的 MDI 应用程序的。
在 Windows 中，MDI 应用程序（例如 dev studio 和 Office）将所有文档窗口托管在应用程序框架窗口内。在 Mac 上，没有每个应用程序的框架窗口，所有文档窗口与其他应用程序的所有其他文档窗口共享桌面。
由于缺乏对传统 MDI 应用程序进行深入改造以将其文档窗口移至桌面的能力，获得桌面菜单的尝试无论多么高尚，似乎注定是一种新颖的东西，没有真正的用途或实用性。
考虑到所有因素，我对 Mac 和 Windows（以及 Linux）上窗口管理器的当前状态感到相当沮丧：浏览器中的选项卡式分页之类的东西实际上是应用程序开发人员的绝望行为，他们没有得到这些东西作为标准窗口管理器 - 我相信这是选项卡真正所属的地方。为什么 notepad++ 应该有一组选项卡、chrome、firefox 和 internet explorer（是的，我知道可以运行所有 4 个），以及开发工作室对接视图、各种绘画程序。
它只是对现代多文档界面应该是什么样子的不同解释的混乱。
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
典型窗口上的菜单栏是窗口非客户区的一部分。当 WndProc 收到
WM_NCPAINT消息并将其传递给DefWindowProc时绘制它，它是 User32.dll（核心窗口管理器代码）的一部分。同一条消息中还画了其他东西吗？标题、窗口边框、最小/最大/关闭框。这些都是在处理单个消息时绘制的。因此，为了隐藏应用程序的菜单，您必须接管此消息的处理，这意味着更改 user32.dll 的行为。隐藏菜单意味着您将负责绘制所有非客户区域。
所有这些元素的外观 - 标题、边框等都会随着 Windows 的每个主要版本而变化。所以你也必须追逐它。
这只是这个想法的十几个难以克服的问题中的一个。即使是微软也可能无法做到这一点，他们可以访问 user32.dll 的源代码！
在屏幕顶部回显每个应用程序的菜单将是一项简单得多的工作，即使这也是一项几乎不可能的工作。当菜单弹出时，会与应用程序进行大量交互，在此期间可以（并且经常）更改菜单。应用程序在绘制菜单项之前更改菜单项的状态是很常见的。因此，您不仅必须复制菜单的外观，还必须复制它们与应用程序的整个消息流交互。
你想要同时做十几个不可能的工作，如果你尝试一下，你可能会学到很多东西，但你永远不会让它发挥作用。
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
WM_NCPAINTmessage and passes it on toDefWindowProc, which is part of User32.dll - the core window manager code.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 changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
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.
That's just one 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!
It would be a far less difficult job to echo 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 very 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.
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.