322 lines
14 KiB
HTML
322 lines
14 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
|
|
<html>
|
|
|
|
<head>
|
|
<meta http-equiv="Content-Type"
|
|
content="text/html; charset=iso-8859-1">
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
|
|
<title>IE/Shell ActiveX Document Hosting</title>
|
|
</head>
|
|
|
|
<body bgcolor="#80FFFF">
|
|
|
|
<h1>IE/Shell ActiveX<font size="5"><tt>TM</tt></font> Document
|
|
Hosting</h1>
|
|
|
|
<h2>Features and Known bugs</h2>
|
|
|
|
<p>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. </p>
|
|
|
|
<ul>
|
|
<li><a href="#features">ActiveX Document Features</a></li>
|
|
<li><a href="#bugs">Known app-specific bugs (build 1115)</a>
|
|
-- <a href="#Word95">Word95</a>, <a href="#Excel95">Excel95</a>,
|
|
<a href="#Excel 97">Excel97</a>, <a href="#PowerPoint">PowerPoint95</a>,
|
|
<a href="#PowerPoint">Visio</a></li>
|
|
<li><a href="#news">What's New (or latest check-in's)</a></li>
|
|
</ul>
|
|
|
|
<p>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. </p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="features">ActiveX Document Features</a></h2>
|
|
|
|
<h3>A. Features that are supposed to work</h3>
|
|
|
|
<ol>
|
|
<li>Navigate-in-place a document over HTTP protocol</li>
|
|
<li>Navigate-in-place a document over FILE protocol</li>
|
|
<li>File->Save is always disabled over HTTP protocol</li>
|
|
<li>File->Save is enabled (and works) after modified over
|
|
FILE protocol</li>
|
|
<li>File->SaveAs is always enabled regardress the protocol
|
|
(Default name is not fancy -- #23452 shdocvw)</li>
|
|
<li>Refresh button re-loads the document (does not work
|
|
except for HTML -- #20995 shdocvw)</li>
|
|
<li>Negotiate the toolbar space correctly (opening,
|
|
drag&drop, activating an embedding, etc.)</li>
|
|
<li>Closing the browser window will shutdown the app
|
|
correctly.</li>
|
|
<li>Navigate-in-place in a sub-frame works and shouldn't
|
|
merge menu or add toolbars.</li>
|
|
<li>Help pulldown is either merged or replaced and works.</li>
|
|
<li>When navigating away from the modified document, a
|
|
"may save" message box will pop up (IE does,
|
|
but Explorer doesn't -- #5067 explorer).</li>
|
|
<li>If the user says No to the "may save" message
|
|
box and navigate back, the document should be re-loaded.</li>
|
|
<li>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. </li>
|
|
<li>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. </li>
|
|
<li>Keyboard input (including accelerators) will be handled
|
|
by the appropriate component. </li>
|
|
</ol>
|
|
|
|
<h3>B. Features that will work only if the DocObject support it</h3>
|
|
|
|
<ol>
|
|
<li>File->Print and Print button in the Internet Toolbar
|
|
is enabled and works.</li>
|
|
<li>File->Page Setup is enabled and works.</li>
|
|
<li>File->Properties is enabled and works</li>
|
|
<li>Print/Pring-Preview buttons on app's toolbar (donot work
|
|
right now -- #19852 shdocvw)</li>
|
|
<li>Save button on app's toolbar</li>
|
|
<li>Non-conflicting accelerator should work Conflicting
|
|
accelerator will be handled by the DocObject.</li>
|
|
<li>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. </li>
|
|
</ol>
|
|
|
|
<h3>C. Features that are not supposed to work</h3>
|
|
|
|
<ol>
|
|
<li>New/Open button on app's toolbar -- they are supposed to
|
|
be disabled.</li>
|
|
<li>App specific status bar components -- the status bar is
|
|
owned by the frame.</li>
|
|
<li>Edit->Copy/Paste/Cut applies to text on the Internet
|
|
Toolbar -- just like Word95.</li>
|
|
<li>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. </li>
|
|
<li>Many other features DocObjects intentionally disable
|
|
(which we can reproduce under Office Binder)</li>
|
|
</ol>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="bugs">Known app-specific bugs (build 1089)</a></h2>
|
|
|
|
<h3><a name="Word95">Word95</a></h3>
|
|
|
|
<p>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. </p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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</p>
|
|
|
|
<p>A-9 (was able to work-around): We found a bug in Word95, which
|
|
does not display anything until we <em>UIActivate</em> 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 <em>SetRect</em> right after
|
|
SetInPlaceSite. If it fails, we call <em>UIActivate</em> on it
|
|
(with a hidden frame window so that added toolbar won't be
|
|
shown). </p>
|
|
|
|
<p>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</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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</p>
|
|
|
|
<p>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</p>
|
|
|
|
<p> </p>
|
|
|
|
<h3><a name="Excel95">Excel95</a></h3>
|
|
|
|
<p>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). </p>
|
|
|
|
<p>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)</p>
|
|
|
|
<p>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)</p>
|
|
|
|
<p>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). </p>
|
|
|
|
<p>B-4/5 (won't fix): The Print/PrintPreview/Save buttons on
|
|
Excel's toolbar are disabled, which is a bug in Excel. </p>
|
|
|
|
<p>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</p>
|
|
|
|
<p>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. </p>
|
|
|
|
<p>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).</p>
|
|
|
|
<h3><a name="Excel 97">Excel 97</a></h3>
|
|
|
|
<p>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
|
|
href="email/ExcelFocusProblem_4441.msg">a couple of e-mail</a>
|
|
and concluded that Excel guys are going to fix this problem. (IE
|
|
bug #4441). </p>
|
|
|
|
<h3><a name="PowerPoint">PowerPoint</a></h3>
|
|
|
|
<p>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</p>
|
|
|
|
<p>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 <em>UIActivate</em> it. This is
|
|
a PowerPoint bug but we need to come up with a work-around --
|
|
#23495</p>
|
|
|
|
<h3><a name="Visio">Visio</a></h3>
|
|
|
|
<p>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). </p>
|
|
|
|
<p>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)</p>
|
|
|
|
<hr>
|
|
|
|
<h2><a name="news">What's New (latest resolved/understood bugs)</a></h2>
|
|
|
|
<ul>
|
|
<li>5/30/96 24776-fixed in 1089: Toolbar flashes heavily when
|
|
navigating from one Word document to another.</li>
|
|
<li>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).</li>
|
|
<li>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 <a href="#Word95">Word95</a>/A-7 for
|
|
detail.</li>
|
|
<li>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. </li>
|
|
<li>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 <a href="#Word95">Word95</a>/A-1&2 for
|
|
detail.</li>
|
|
<li>7/8/96 29828 -- by-design. Found out why Excel complains
|
|
that the document is already "being modified"
|
|
when the file is cached. See <a href="#PowerPoint">Excel95</a>/A-1
|
|
for detail. </li>
|
|
<li>9/27/96 IE bug 4441 -- Resolved as won't fix. See <a
|
|
href="#Excel 97">Excel97</a>/A-15 for detail. </li>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<p><a href="dochost0.htm">Go to the parent page</a></p>
|
|
</body>
|
|
</html>
|