Context menu disappears with Word automation

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 o