C++/MFC - 防止挂起的子 (ActiveX) 控件冻结整个 UI？
我目前正在使用 Microsoft 的 WebBrowser ActiveX 控件，我注意到我可以通过加载导致嵌入式 IE 崩溃的网页来冻结整个程序。 所以我想知道是否有什么办法可以防止整个程序冻结？
我已经尝试过： - 创建一个新的 CWinThread 创建/处理控件 -->结果相同 - 要从此线程创建一个新对话框，创建/处理控件 -->相同的结果
问题似乎深藏在消息系统中，但我不确定。
谁能告诉我是否有可能防止整个 UI/对话框冻结以及导致此问题的原因是什么？
（我已经在网上搜索过，但找不到任何真正的解决方案）
Thanx，Gary
PS：目前对我有用的唯一方法是创建一个新的子进程来加载/处理控件。我可以修改它，使其看起来像主对话框的子窗口，但这需要我直接从主对话框代码访问控件的能力。
编辑：
好吧，我找到了一个令我满意的解决方案。我正在主应用程序中创建一个占位符窗口，并启动一个包含实际控件的新子进程。我委托所有窗口移动/大小/等。向子进程发送消息，以便它可以重新定位/做出反应。 重要的是不要从我的主应用程序创建新进程作为 WS_CHILD 对象，因为这样它仍然会冻结它。 我通过内存映射与进程共享信息，并使用自定义用户消息进行通信。 我希望它会更容易......
I'm currently playing around with Microsofts WebBrowser ActiveX control and I noticed that I can freeze my whole program by loading a web page that crashes the embedded IE.
So I wondered if there's any way to prevent the whole programm from freezing?
I already tried:
- To Create a new CWinThread creating/handling the Control --> Same result
- To Create a new Dialog from this Thread creating/handling the Control --> Same result
The Problem seems to be deep in the message system, but I'm not sure.
Can anyone tell me if it is is even possible to prevent the whole UI/Dialog from freezing and what causes this problem?
(I already searched the web but I couldn't find any real solution)
Thanx, Gary
PS: The only way that currently works for me is to create a new child process loading/handling the control. I can modifiy it so that it looks like a child window of my main dialog but this takes the ability from me to access the control directly from my main dialog code.
EDIT:
Okay I found a solution that satisfies me. I'm creating a placeholder window in the main application and start a new child process containing the actual control. I delegate all window move/size/etc. messages to the child process so that it can reposition/react.
It was important not to create the new process as a WS_CHILD object from my main application because that way it would still freeze it.
I'm sharing information through a memory map with the process and comunicate using custom user messages.
I Hoped it would be easier...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个非常复杂的领域。对于浏览器人员来说，防止一个 UI 对象中的问题导致直接相关的父 UI 对象中出现问题是一件耗费大量时间的事情，他们试图确保一个选项卡不会导致另一个选项卡崩溃。我认为可以公平地说，这是一个火箭科学，而且这个话题太大，无法在这里描述。
您选择了一个很好的起点（将框架分离到一个新的流程中）。您还需要了解的其他内容是线程输入队列和 AttachThreadInput (http://msdn.microsoft.com/en-us/library/ms681956(VS.85).aspx)。 Raymond 对此也有一些内容；包括 PDC 谈话的一部分 http://blogs.msdn。 com/b/oldnewthing/archive/2008/08/01/8795860.aspx。
额外建议：如果不需要，这里的另一种选择可能是简单地禁止在浏览器控件中加载 AX 控件。如果您确实需要它们并且正在构建一个非常通用的浏览器替代品，那么您应该做好大量工作来复制您在主要浏览器中找到的稳定性。
This is a very complex area. Preventing problems in one UI object causing problems in directly-releated parent UI object is something that has consumed a lot of time for the browser folks, who've attempted to ensure that one tab cannot crash another. I think it's fair to say that this is rocket science, and too large a topic to describe here.
You've picked a good starting point (separate the frame into a new process). Something else you will want to learn about is thread input queues and AttachThreadInput (http://msdn.microsoft.com/en-us/library/ms681956(VS.85).aspx). Raymond has some content on this too; including part of PDC talk http://blogs.msdn.com/b/oldnewthing/archive/2008/08/01/8795860.aspx.
Extra advice: An alternative here might be to simply disallow loading AX controls in your browser control if you don't need them. And if yo do need them and are building a very general browsing replacement, you should anticipate lots of work to replicate the stability you'll find in the main browsers.