# IE/Shell ActiveX`TM` Document Hosting

## Features and Known bugs

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.

- ActiveX Document Features
- Known app-specific bugs (build 1115) -- Word95, Excel95, Excel97, PowerPoint95, Visio
- What's New (or latest check-in's)

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.

## ActiveX Document Features

### A. Features that are supposed to work

1. Navigate-in-place a document over HTTP protocol
2. Navigate-in-place a document over FILE protocol
3. File->Save is always disabled over HTTP protocol
4. File->Save is enabled (and works) after modified over FILE protocol
5. File->SaveAs is always enabled regardress the protocol (Default name is not fancy -- #23452 shdocvw)
6. Refresh button re-loads the document (does not work except for HTML -- #20995 shdocvw)
7. Negotiate the toolbar space correctly (opening, drag&drop, activating an embedding, etc.)
8. Closing the browser window will shutdown the app correctly.
9. Navigate-in-place in a sub-frame works and shouldn't merge menu or add toolbars.
10. Help pulldown is either merged or replaced and works.
11. When navigating away from the modified document, a "may save" message box will pop up (IE does, but Explorer doesn't -- #5067 explorer).
12. If the user says No to the "may save" message box and navigate back, the document should be re-loaded.
13. Dragging a DocObject document (from the shell) onto the title bar of a browser window (which is looking at another DocObject including a HTML document) will open that document in-place.
14. Typically a LocalServer DocObject application creates its own top-level stand-alone window. It is supposed to keep it invisible (or inactivated if it's already visible) while we are navigating in-place.
15. Keyboard input (including accelerators) will be handled by the appropriate component.

### B. Features that will work only if the DocObject support it

1. File->Print and Print button in the Internet Toolbar is enabled and works.
2. File->Page Setup is enabled and works.
3. File->Properties is enabled and works
4. Print/Pring-Preview buttons on app's toolbar (donot work right now -- #19852 shdocvw)
5. Save button on app's toolbar
6. Non-conflicting accelerator should work Conflicting accelerator will be handled by the DocObject.
7. Help menu will be merged (both IE help menu items and DocObject help menu items will be available under a single Help menu) only if the DocObject supports the help menu merging. Word supports it, but Excel doesn't. If DocObject does not support it, only DocObject help menu items will be available.

### C. Features that are not supposed to work

1. New/Open button on app's toolbar -- they are supposed to be disabled.
2. App specific status bar components -- the status bar is owned by the frame.
3. Edit->Copy/Paste/Cut applies to text on the Internet Toolbar -- just like Word95.
4. DocObject in sub-frame being UIActivated (merging menu/toolbar) -- the top-level HTML DocObject is supposed to be UIActivated no matter which sub-frame has the focus.
5. Many other features DocObjects intentionally disable (which we can reproduce under Office Binder)

## Known app-specific bugs (build 1089)

### Word95

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

### Excel95

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).

### Excel 97

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).

### PowerPoint

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

### Visio

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)

## What's New (latest resolved/understood bugs)

- 5/30/96 24776-fixed in 1089: Toolbar flashes heavily when navigating from one Word document to another.
- 5/30/96 24763-fixed in 1089: Explorer popup menus missing when hosting a Word document with embedded (24764 is also fixed by the same delta).
- 5/31/96 23271-won't fix: When you open a word doc in IE3.0, and use the page layout button, you loose the toolbars. See Word95/A-7 for detail.
- 6/12/96 25633 - fixed: Ctrl+O and Ctrl+X now works correctly while hosting a Word document. The number of entries in the accelerator table returned from IOleInPlaceSite::GetWindowContext was wrong.
- 7/5/96 We call SetHostName only for Word95 and Word97 (instead of always). We found calling SetHostName causes some side effect on other apps (such as Excel and MSPaint). See Word95/A-1&2 for detail.
- 7/8/96 29828 -- by-design. Found out why Excel complains that the document is already "being modified" when the file is cached. See Excel95/A-1 for detail.
- 9/27/96 IE bug 4441 -- Resolved as won't fix. See Excel97/A-15 for detail.

Go to the parent page