我們有一個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