safe to delay processing of WM_TIMER in IE?

we have an activex control, and it needs to pump win32 messages while it blocks to keep IE responsive. to avoid some really nasty javascript problems introduced by activex, we want to skip WM_TIMER messages from inside our activex control's win32 message pump, and IE can process them all when IE's message pump regains control.

this works, but I am absolutely terrified of mucking with IE internals in this way and, should we choo开发者_开发问答se to proceed, expect random un-reproducible failures and certainly don't expect to be future-proof. We officially support IE7+. IE6 compatibility is nice but we already have a roundabout workaround in place that works in all IE versions.

The only reason I think this approach might actually be reasonable is it appears that a breakpoint in the IE developer tools javascript debugger halts the entire process, which means that delaying WM_TIMER messages isn't totally screwing something, at least in IE8.

What if I delay the messages for half an hour, while a 1GB file downloads?

---

WM_TIMER messages are "low priority" messages and not guaranteed to be delivered on time anyway - what you must watch out for is if the timer messages are used to performed a delayed initialization on the part of IE - If you wait for IE to get into some state before exiting your loop, the inhibited messages might deadlock the process.

Other than that, the point of modal message loops is to enable this kind of filtering.

---

Why on earth would you block the IE thread like that? I understand that even ugly hacks are needed at times, but I have a hard time imagin. If it were me, I would instead fire a javascript event into the DOM to let the page know what is going on and handle the control being shut down unexpectedly in a graceful way.

Barring that, instead of tying up the IE process, launch another one. If you register it during install you can launch a medium integrity process from inside your ActiveX Control. Either way your activex control can keep track of it as it runs in another thread (or process) and you can use either cross-thread or interprocess synchronization and communications to keep track of what is going on.