问上下文菜单随Word自动化而消失

EN

当通过ActiveX托管办公应用程序时，你会发现一些办公应用程序的一些版本对通知窗口激活的变化非常敏感，这尤其会影响它们的上下文菜单。

基本上，如果当他们失去或获得焦点时，以及顶级窗口获得或失去焦点时(即使窗口中的子控件没有获得焦点)，你都不告诉他们，那么他们就会变得混乱。

这是我与之斗争了很长时间的事情，尤其是当你不得不告诉应用程序他们比你更有资格知道的事情时，尤其令人沮丧(比如当他们直接失去或获得焦点时……或者当他们创建一个弹出式菜单，将焦点从他们身上移开，并且必须以不同于其他应用程序/窗口的方式处理焦点时，你可以去预测……呃。

无论如何，Office应用程序应该公开一个IOleInPlaceActiveObject接口，并且您应该确保调用它的OnFrameWindowActivate方法来告诉它激活/停用。

从内存中快速浏览一下我自己用于托管Office的代码，这是最重要的事情之一。这也是一件容易被忽视的事情，你会想“不，这不是那么重要……为什么任何东西都会如此关心窗口是否处于活动状态？”你可能认为它只会导致一些小的表面问题(比如当它不是活动的时候看起来很活跃)，但它可能会导致整个事情锁定或崩溃。相信我，Office太关心这类事情了！我的印象是，在Office的封面下，仍然有一个非常古老的，单线程的设计，从合作的多任务笨拙的日子，它可能会变得非常混乱，当它的两个窗口似乎是同时活动的。

很抱歉，我不能给出更多的建议，只是指向那个方向……编写ActiveX主机是一门黑色的艺术(所有文档都是面向主机的，而不是主机:( )而我让自己的代码工作的唯一方法是经过几个月的试错和大量地狱般的调试。不幸的是，这是一场噩梦。

最后一条建议:不要害怕为特定的应用程序硬编码。这就是IE本身所做的，使用注册表设置来控制哪些kludge应用于什么(我怀疑在代码中会有更多的硬编码)。ActiveX是一个定义如此模糊的混乱，以至于各种控件都有自己的怪癖和bug，而且不可能编写一个干净的、通用的主机来处理所有的控件。(修复一种变化会破坏另一种变化。)你还会发现，只有当你以IE相同的顺序尝试接口时，它们才能起作用，只是因为它们只用IE测试过；稍微不同的做法，它们就会崩溃。:(

我想知道您是否可以从包含OLE容器的窗体中捕获任何Lost Focus类型事件，此时您可以销毁OLE容器中的文档，但将其保留在内存中。然后，在窗体的任何Got Focus类型事件上，您可以检查是否有该文档；如果有，则将其重新加载到OLE容器中。

这对你有用吗？

也许您可以使用组件来调用应用程序。创建自定义组件以通过接口调用word，然后在菜单中注册特殊命令时，我从来没有遇到过问题。在容器中，你可以不在表单上设计一个特殊的菜单吗？有一些WordSink Evenet可以帮助保存和关闭，它们可以与word com对象结合使用。