When hosting Office apps via ActiveX, you'll find some versions of some Office apps are ridiculously touchy about being informed of window activation changes and this can especially affect their context menus.
Basically, if you don't tell them whenever they lose or gain the focus and also whenever your top-level window gains or loses focus (even if their child control in the window isn't gaining focus), then they can go haywire.
It's something I fought with for a long time and especially frustrating when you're having to tell the applications things that they are in a better position to know than you are (like when they lose or gain the focus directly... or when they create a pop-up menu which takes the focus away from them and has to be handled differently to some other app/window taking the focus, which you are left to divine... Ugh.
Anyway, the Office apps should expose an IOleInPlaceActiveObject interface and you should ensure you call its OnFrameWindowActivate method to tell it about activation / deactivation.
From memory, and a quick look at my own code for hosting Office, that is one of the most important things. It is also an easy thing to overlook, thinking "Nah, it can't matter that much... Why would anything care that much about whether the window is active or not?" You might think it could only lead to some minor cosmetic issues (like appearing active when it isn't) but it can lead to the whole thing locking up or crashing. Trust me, Office cares way too much about such things! I get the impression that under the covers of Office there is still a very old, single-threaded design from the days of co-operative multitasking clunking away and it can get very confused when two of its windows seem to be active at once.
Sorry that I cannot give more advice than just pointing in that direction... Writing ActiveX hosts is a black art (all the documentation is geared towards being hosted, not being the host :( ) and the only way I got my own code to work was through months of trial and error and a hell of a lot of debug-out. It's a nightmare, unfortunately.
One last piece of advice: Don't be afraid to hardcode kludges for particular applications. This is what IE itself does, with registry settings to control which kludges get applied to what (and I suspect some more hardcoded into the code). ActiveX is such a poorly-defined mess that various controls have their own quirks and bugs and it's impossible to write a clean, generic host that works with all of them. (A change that fixes one will break another.) You'll also find things that only work if you try interfaces in the same order that IE does, just because they've only been tested with IE; do things slightly differently and they fall apart. :(
