Hello,

I think I have discovered an error introduced in service pack 3 for
Excel 2003 regarding OLE linking from a named range.

We have an application that makes extensive use of the uniform data
transfer facilities of OLE (namely we allow users to "Paste Link" data
from Excel to our application and keep the data up-to-date by
responding to data change notifications via IDataObject.DAdvise).
This was all well and good until Office 2003 SP3 was rolled out when
there was a change in behaviour when the data source is a Named Range.

Previously (SP2), obtaining the OLE source display name (via
IOleLink.GetSourceDisplayName) would return a string of the format
Book1.xls!Sheet1!R1C1:R5C1 for a standard excel selection or Book1.xls!
Sheet1!TestRange if the source was a Named Range (called "TestRange"
in this example).

Now (SP3) the un-named range behaves as before, but the string
returned for the named range is of the form Book1.xls!Sheet1!
R1C1:R5C1TestRange (including both the cell reference and the range
name).

I believe this is an error rather than a deliberate change as
attempting to recreate this ole link by passing this string to
MkParseDisplayName results in excel returning a syntax error. Hand-
editing the display name string back to the original format (Book1.xls!
Sheet1!TestRange) works as expected.

The bug can be recreated using Excel 2003 and Word 2003 as follows:

1) Create a new excel spreadsheet, with and type a number into a
cell.
2) Create a named range for the cell.
3) Copy the cell to the clipboard
4) Create a new word document and select Edit - Paste Special
5) Choose 'Paste Link' and choose any data format you like (eg.
Unformatted Unicode Text) and press OK

Get an error: "Word cannot obtain the data for the Excel.Sheet.8
link". As far as I can tell there is no way to get more error detail
from word. But if you repeat the above steps but without the named
range everything works correctly. Similarly, once you have a working
link in word if you press Alt+F9 to view field codes and edit the
field code to use the named range then it also works.

Can anyone here confirm my findings? If not, is there somewhere more
appropriate that I should have posted this?

Regards,

Malcolm Stockham

Hi Malcolm,

I came accross a similar problem (see note below which I pasted into the
group recently) and I wondered if you found a solution.

"In MS Word (2002 SP3) I've pasted as a link MS Excel objects, Charts and
unformatted text into my document. Later when I try to Update the Links I get
the
following error message:

"Objects in this document contain links to files that cannot be found. The
linked information cannot be updated"

I can fix this problem by deleting and pasting in the MS Excel objects and
Charts again (the problem doesn't seem to affect Unformatted text) but it
becomes tedious when there are 20 to 30 links to fix each time the error
occurs."

Since I posted the above message I've attempted to rebuild my document from
scratch and now I can't even paste as link as I get the following message:
"Word cannot obtain the data for the Excel.Sheet.8.link"

Any help gratefully received

kind regards

Ian


" wrote:

Hello,

I think I have discovered an error introduced in service pack 3 for
Excel 2003 regarding OLE linking from a named range.

We have an application that makes extensive use of the uniform data
transfer facilities of OLE (namely we allow users to "Paste Link" data
from Excel to our application and keep the data up-to-date by
responding to data change notifications via IDataObject.DAdvise).
This was all well and good until Office 2003 SP3 was rolled out when
there was a change in behaviour when the data source is a Named Range.

Previously (SP2), obtaining the OLE source display name (via
IOleLink.GetSourceDisplayName) would return a string of the format
Book1.xls!Sheet1!R1C1:R5C1 for a standard excel selection or Book1.xls!
Sheet1!TestRange if the source was a Named Range (called "TestRange"
in this example).

Now (SP3) the un-named range behaves as before, but the string
returned for the named range is of the form Book1.xls!Sheet1!
R1C1:R5C1TestRange (including both the cell reference and the range
name).

I believe this is an error rather than a deliberate change as
attempting to recreate this ole link by passing this string to
MkParseDisplayName results in excel returning a syntax error. Hand-
editing the display name string back to the original format (Book1.xls!
Sheet1!TestRange) works as expected.

The bug can be recreated using Excel 2003 and Word 2003 as follows:

1) Create a new excel spreadsheet, with and type a number into a
cell.
2) Create a named range for the cell.
3) Copy the cell to the clipboard
4) Create a new word document and select Edit - Paste Special
5) Choose 'Paste Link' and choose any data format you like (eg.
Unformatted Unicode Text) and press OK

Get an error: "Word cannot obtain the data for the Excel.Sheet.8
link". As far as I can tell there is no way to get more error detail
from word. But if you repeat the above steps but without the named
range everything works correctly. Similarly, once you have a working
link in word if you press Alt+F9 to view field codes and edit the
field code to use the named range then it also works.

Can anyone here confirm my findings? If not, is there somewhere more
appropriate that I should have posted this?

Regards,

Malcolm Stockham