Because ActiveX Document (DocObject) mechanism is new to us and it is sometimes difficult to tell what we can expect and what should be reported as a bug. Therefore, I wrote this document to summarize list of features that are supposed to work, may work or are expected not to work, including known bugs. I also describe some of work-around we put in the container code (IE/shell frame) to work around some bugs in ActiveX Document objects.
By the way, please remember that application programs may intentionally behave differently when it's opened as a DocObject. If you notice a certain feature is disabled under IE, please double check if it is disabled under the Office binder as well. If it is disabled, it's most likely a by-design.
A-1&2 (was able to work-around): Word95 (and 97 as well) has an internal state which indicates whether or not that's an embedding or not. Just loading a document (via IPersistFile::Load) and activating in-place won't work because of this internal state. In order to make it work we need to call its IOleObject::SetHostName. To avoid side-effect with other apps, we do it only for Word95 and Word97.
A-1&2: A few people reported a problem in in-place navigation (opens up in a separate window instead), but reinstalling Office solved that problem in all cases. In one of these cases, we found that docobj.dll was not registered correctly as a marshaller of IOleDocument interface -- the cause is unknown.
A-7 (won't fix): When switching the view mode (among Normal, Outline, Page Layout, ...), Word puts its toolbar behind the internet toolbar. It relocated those toolbars correctly if I resize the frame window. As far as I can tell, it seems that Word is assuming that the border rectangle (which we return from IOleInPlaceUIWindow::GetBorder) is the same as the client rectangle of the hwndFrame in this particular senario. Because this Word bug is hard to work-around (we need to call its ResizeBorder when we detecct this senario, but it's very hard to detect it) and the user can work-around (need to resize the frame window), we resolve this bug as "won't fix". -- #23271
A-9 (was able to work-around): We found a bug in Word95, which does not display anything until we UIActivate it. This is fine if the document is the top-level DocObject, but not fine if the document is opened in a sub-frame. To work-around this bug, we detect this case by calling SetRect right after SetInPlaceSite. If it fails, we call UIActivate on it (with a hidden frame window so that added toolbar won't be shown).
A-13 (probably won't fix): There is a report that drag&dropping a Word document onto a browser window will cause many problems occationally (the exact repro senario is not known). It's most likely a bug in WinWord. Unless we can come up with a way to work-around this bug, we have no choice other than shipping IE/Nashville without adressing this bug. -- #20475
A-14 (won't fix): Under a certain condition (typically the document is already opened by another machine), Word pops up its own dialog box (such as "Document is already opened by foo. Do you want to open it read-only?") while we are activating it. When this happens, Word incorrectly make its own MDI frame visible and bring it to the front.
Other (to be investigated): Under Nashvile opening a Word's dialog (such as View->Toolbar) multiple times while the dropdown box on the shell toolbar has the focus will eventually cause GPF in Word. It sounds like a bug in Word. -- #6530
Other (by design): The Wizard button if Table->Insert dialog box is disabled. This button is disabled when you open a Word document in a binder file. -- #24095
A-1 (probably by-design): When opening an Excel document over HTTP for the second time (when it's cached), Excel complains that the document is being modified and can be opened only as read-only. This is caused by the fact that WININET keeps the cached file left open when it's already cached. Although there is a bug in WININET (WININET must be consistent -- #29828), it is almost by-design that Excel pops up this dialog box for a cached file because a http protocol is virtually a read-only protocol (don't argue about POST).
A-1/2 (Excecl bug - won't fix): Excel95 fails to perform IPersistFile::Load while another excel file is UIActive. This is a known problem and Binder95 has a work around (it calls pUIActiveObject->OnFrammeWindowActivate(FALSE) before calling pmk->BindToObject). We can't apply this work around in IE because we need to make it sure that we hit this code path only if we are navigating from an Excel page to another. Even though we put this work around (using the CLSID nodified by the URLMON), it won't cover all the cases, which involves a frame-set. (#4214)
A-8 (looking for a work-around): It's known that Excel does not shutdown correctly even after we close the browser window. It seems that the excel object is not closed/released correctly. Because of this bug, visiting the same page causes a wrong message box, which says "XXX is being modified by YYY. Open as read-only?". We have been trying to work-around this Excel bug, but not successful at this moment The latest work-around suggested by Excel team (QI'ing to IDataObject calling OleCreateFromData) stopped the GPF but leaks a temp file, which is pretty BAD (#6030 excel)
A-4: A person is experience that File->Save menu is always enabled when opening an Excel document over File protocol, although I can't reproduce it on my machine. It very much looks like a bug in Excel, which returns S_OK to IsDirty under a certain condition even though the document has not been modified. Since this is an Excel bug and the symptom is minor; we will not do anything on this bug. (#15551 won't fix -- Excel bug).
B-4/5 (won't fix): The Print/PrintPreview/Save buttons on Excel's toolbar are disabled, which is a bug in Excel.
B-6 (probably won't fix): Ctrl+O does not work. Excel is unneccessarily eating ctrl+O key even though it does not own the File menu. -- #25633
B-7 (won't fix): Excel95 does not support help menu merging. Therefore, only Excel's help menu items are available under the Help menu. You'll see the same result under the Office binder.
Other (won't fix): Selecting the "Insert..." menuitem of the context menu of a tab won't allow you to insert a module. Excel doesn't allow you to add it when it's opened under the Office Binder either. This is an Excel bug and we won't fix (#19840 won't fix). Harvard Chart XL Chart causes a Macro error, "a method of Workbook class failed" -- it also happens under the Office Binder (#25876 won't fix).
A-15 (won't fix -- app bug): When the user clicks the address bar then clicks the client are of Excel, the input focus remains on the address bar. This is caused by the fact that Excel does not call SetFocus when it's clicked. From IE's point of view, there is nothing we can do. The same problem happens under both Outlook and Binder. We've exchanged a couple of e-mail and concluded that Excel guys are going to fix this problem. (IE bug #4441).
A-4 (won't fix): Powerpoint does not save when the user select the File->Save (after modifying the document over file protocol). IPersistFile::Save always returns E_NOIMPLE. It looks like the Powerpoint does not implement IPersistFile::Save. -- #35211
A-9 (looking for a work-around): Just like Word95, PowerPoint does not create a window (leave it blank) when it's opened in a sub-frame, in which case we won't UIActivate it. This is a PowerPoint bug but we need to come up with a work-around -- #23495
A-1/2 (investigating): We have a report that there is a case when Visio opens up in a saparate window. I was able to repro this bug on my own machine a couple of times but not consistently. The cause is unknown, but probably a Visio bug (#17878).
A-4 (postponed): After opening a VISIO file over file protocol and modify it, File->Save is enabled correctly. It, however, does nothing when the user select it. We've found out that passing TRUE as fRemember to IPersistFile::Save will fix this problem, but we are not making that change for IE 3.0 (#35077 - #29938 and 35101 are realted)