我们有一个activex控件，它需要在win32消息的同时阻塞IE以保持响应。为了避免由activex引入的一些非常讨厌的javascript问题，我们希望跳过activex控件的win32消息泵中的WM_TIMER消息，IE可以在IE的消息泵重新获得控制权时处理它们。可以安全地延迟IE中WM_TIMER的处理吗？
这是有效的，但我对这种方式非常害怕利用IE内部进行分析，如果我们选择继续进行，期望发生随机不可重现的失败，当然也不期望能够面向未来。我们正式支持IE7 +。 IE6的兼容性不错，但我们已经有一个适用于所有IE版本的迂回解决方法。
我认为这种方法实际上可能是合理的唯一原因是IE浏览器开发人员工具中的一个断点出现在JavaScript调试器停止整个过程，这意味着延迟WM_TIMER消息不是完全搞砸东西，至少在IE8 。
如果我在1GB文件下载时延迟了半个小时的消息，该怎么办？
WM_TIMER消息是“低优先级”消息，无法保证按时交付 - 您必须注意的是如果定时器消息用于对IE部分执行延迟初始化 - 如果您等待IE在退出循环之前进入某种状态，被禁止的消息可能会导致进程死锁。
除此之外，模态消息循环的要点是启用这种过滤。
如果我在一个1GB文件下载的情况下延迟了半个小时的消息，该怎么办？ – 2010-11-04 18:27:00
然后随机脚本将不会触发30分钟。渲染经验有些不可靠。这一切都取决于正在显示的网页。 – 2010-11-05 05:53:30
为什么地球上会阻塞IE线程？我明白，有时候甚至需要丑陋的黑客，但我很难想象。如果是我，我会将一个JavaScript事件放入DOM中，让页面知道正在发生的事情，并以正常的方式处理意外关闭的控件。
除非绑定IE进程，否则请启动另一个进程。如果您在安装过程中注册它，则可以从ActiveX控件内部启动中等完整性过程。无论哪种方式，您的ActiveX控件都可以跟踪它，因为它在另一个线程（或进程）中运行，您可以使用跨线程或进程间同步和通信来跟踪发生的事情。
我们正在扩展的activex产品是一个文件下载器，它暴露了一个阻塞的Download（）方法。即使它阻塞，它也会泵送窗口，所以IE仍然响应点击，并且JS可以重新调用控件。正如听起来那样，它确实感觉像作者知道他在做什么...... – 2010-11-05 14:30:52
我认为要求是它是相同的过程，以便控制（通过WinINET）可以发送请求与IE的上下文和饼干和东西。 – 2010-11-05 14:32:12
您可以在不使用阻塞方法的情况下异步执行此操作; FireBreath使用WinINET进行下载，并以浏览器友好的异步方式处理所有内容。我会非常强烈地建议不要阻止。我很确定你仍然可以在不同的过程中做到这一点，但我没有看到任何你需要的理由。如果劫持winproc似乎工作，你可以做到这一点......但你永远不会确定不会有负面的副作用。即使现在有些东西可能会改变。 – taxilian 2010-11-06 03:41:57
由于首先不保证WM_TIMER消息的交付时间，我认为你会没事的，FWIW。 – 2010-11-03 22:20:47