M
malcolm.nntp
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
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