有关 win32 多进程窗口所有权的 MSDN 文档在哪里? (chrome使用这个)
描述多个进程如何控制和拥有其他进程(如 Google Chrome)中的其他窗口的 MSDN 文档在哪里?
where is the MSDN documentation that describes how multiple processes can control and own other windows in other processes like Google chrome?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
嗯,我只是模拟了一个例子,如果我打开记事本,然后打开一个资源管理器窗口,我可以执行以下操作,没有麻烦:
这将我的音乐文件夹窗口放入记事本中,每个窗口都属于自己的进程,这甚至不是我自己的过程。哦亲爱的。
这是在 XP SP2 上完成的。
Hmmm, I just mocked up an example, and if I open up Notepad, and open up an explorer window, I can do the following, no trouble:
This puts my music folder window inside Notepad, each window belongs to its own process, which is not even my own process. Oh dear.
This was done on XP SP2.
您可以使用 FindWindow 查找句柄另一个过程。有一系列消息可用于遍历窗口层次结构以查找句柄。
然后,您可以使用 PostMessage 操作句柄。
微软给出了一个WTL库的源代码。您可以使用该库,因为其中的控件都有一个 Attach 方法,可以附加到任何窗口句柄。您可能需要稍微修改一下才能使用 PostMessage 而不是 SendMessage。
You can use FindWindow to find a handle in another process. There is a whole series of messages which can be used to traverse the window hierarchy to find handles.
You can then manipulate the handles using PostMessage.
There is a library WTL which microsoft gives out the source. You can use that library because controls in there all have an Attach method that can attach to any window handle. You might need to hack it a bit to use PostMessage instead of SendMessage.
我不相信有任何关于此的明确文档,因为 Win32 API 中没有直接支持它的内容。您可以使用 SetParent 或 SetWindowLongPtr 与 GWLP_HWNDPARENT 分别更改为窗口的父级和所有者您可以使用 SendMessage() 将任何您喜欢的窗口消息发送到另一个进程窗口。
如果您想在两个不同的进程之间移动任何数据,请查看 进程间通信 (IPC),Windows 有多种方法可以实现这一点。
I don't believe there is any explicit documentation on this, because nothing directly in the Win32 API that supports that. You can use SetParent or SetWindowLongPtr with GWLP_HWNDPARENT to change to window's parent and owner respectively and you are free to any window message you like to another processes window with SendMessage().
If you want to move any data between two difference processes you are looking at Inter-process Communication (IPC), which Windows has several ways to do.
我不知道 Chrome 是否也这样做,但进程外 COM 服务器多年来一直在做类似的事情。例如,当您将 COM 对象嵌入到文档中,然后双击该对象将其打开进行编辑时,您可以通过以下两种方式之一打开它。提供该内容的应用程序可以提供在托管应用程序内进行处理的 DLL。或者,您可以进行就地激活,即在托管应用程序内部打开提供嵌入内容的应用程序。它通常将自己的菜单项添加到菜单中,并接管显示区域。
让就地激活顺利进行是很困难的,因为它需要在大多数彼此不知情的应用程序之间进行合作。然而,对于像 Chrome 这样的东西,所涉及的流程都是一起开发的,并且对彼此的工作方式等有深入的了解,因此这样做应该不会那么复杂。
我应该补充一点,我并没有真正仔细研究过 Chrome,所以我不确定它是否真的是这样工作的。我只是指出这绝对是可能的,而且我们中的很多人几年前就做到了。现在这没什么大不了的,但我很确定操作系统应该仍然支持这一切。
I don't know that Chrome does it the same way, but out of process COM servers have been doing similar things for years. For example, when you embed a COM object into a document, then double click that object to open it for editing, you can open it one of two ways. The application that supplied that content can supply a DLL that does the processing inside the hosting application. Alternatively, you can get in-place activation, where the application that supplied the embedded content gets opened inside of the hosting application. It usually adds its own menu entries to the menus, and takes over the display area.
Getting in-place activation to work well is hard, because it requires cooperation between applications that are mostly oblivious to each other. In the case of something like Chrome, however, the processes involved are all developed together, and have intimate knowledge of how each other work and such, so doing it shouldn't be nearly as complex.
I should add that I haven't really looked hard at Chrome, so I'm not sure this is how it really works. I'm just pointing out that it is definitely possible, and quite a few of us did it years ago. It's not as big of a deal now, but I'm pretty sure the OS should still support it all.