[cap-talk] [Off-topic] Document linking in Microsoft OLE

[James A. Donald]

James A. Donald:
 >> Upon reopening the Word file, I find that the word
 >> file *asks* me for *permission* to access the
 >> external file, rather than assuming an automatic
 >> right to dynamically access the Excel file.  If I
 >> deny that, the Excel data in the Word file acts as an
 >> ordinary paste, as Excel data contained *inside* a
 >> Word file, not as a dynamic link.

Karp, Alan H wrote:
 > Actually, it asks me if I want to update the data from
 > the linked files (one message no matter how many
 > linked files).  When I say NO and open the file from
 > inside Word, I see the updates.

I, however, do not see the updates.


 > Clearly, it's not using data stored in the Word file.

Upon reading what you just wrote, I just opened Excel,
and loaded my Excel file displaying a graph of US
poverty rates from 1957 to 2005.  It shows the updated
version of the graph, in which poverty is displayed as a
line graph.

I then opened a word document dynamically linked to that
Excel file.  It shows the earlier version, in which
poverty is displayed as a dot graph.  It asks if it can
access linked files.  I say no.  It continues to display
poverty as a dot graph, which is what I expect, but
tells Excel to stop displaying the conflicting and more
up to date version, which is not at all what I expect.
The more up to date version remains on disk - it is just
not displayed at the same time.  When I reopen Excel
after closing word, I see the version I should see, the
more up to date version.

Clearly Word is just using the data stored in the word
file if I tell it no updates.

 > I am also able to edit and save the file after Word is
 > closed.

I find this statement confusing.  Opening Word should
not open a separate instance of Excel.  If *you* open a
separate instance of Excel, then of course you should be
able to edit and save the file.

 > We discussed this behavior when we thought about
 > adding support for linked files to Polaris.  Asking
 > the user to approve access to each linked file
 > everytime the containing file was opened seemed too
 > dangerous.  After all, the macro virus could ask for
 > access to a lot of files, one of them being my Quicken
 > data.  In my rush to get my editing done, I might just
 > select OK to All.  Instead, we thought we could ask
 > the first time the containing file was opened and
 > remember the choice. The "capability" wouldn't be
 > durable, but it would have the same effect from the
 > user's point of view.

You have shown me that effectively durable capabilities
are a necessary evil when retrofitting compatibility
with existing software.

Very few programs utilize linkages between existing
files.  If retrofitting compatibility with existing
software, these programs represent a big problem.

In the long run, ideally they should all be rewritten to
go through a project file powerbox, but that is not
going to be done any time soon.  Another solution is to
privilege all well known well behaved software, and give
the user the run time option of privileging software
that runs into the restriction - which if I understand
you correctly is approximately what you did.

Would be nice if the UI approximated project file
powerbox behavior by associating a file list, and giving
the user the option of approving changes in the file
list and discovering changes in that file list but that
of course conflicts with the goal of getting the
software out.