Open rgallagherab opened 3 weeks ago
After looking more closely at this repo, I understand that this won't fix my use case since this is separate from the MS CDN hosted office.js. I'm really not sure how best to get the issue brought to their attention, but I guess I'll need to dig deeper on that.
One other thing of note is that when we extracted the contents of the XLSX file we noticed that the definedNames
entries are stored with node contents like [1]Controls!$A$1
instead of the normal value Controls!$A$1
(where the sheet name is Controls
).
Hi @XuanZhouMSFT @SiruiSun-MSFT Could you help take a look this issue? Thanks.
@rgallagherab, Thanks for your reporting! We could repro the issue with the steps you provided. And the root cause is under investigation. Will share more information when we get any. Thanks for your patience!
While performing internal testing of a recently published Excel add-in we discovered a case where ranges stored in
worksheet.names.items
will be corrupted onceworksheet.name
is set. This issue specifically occurs on the first usage of the add-in after installation.When installing a new add-in from the AppSource Marketplace an XLSX document is opened from office.com. For example, when installing Script Lab there is a button that links to
ms-excel:https://api.addins.store.office.com/addinstemplate/en-US/608681f0-c758-4481-81ce-306f9dd4f3f1/WA104380862/none/Script-Lab--a-Microsoft-Garage-project.xlsx?omexsrctype=1
. The issue described here only occurs when this initial document is opened. Closing the document or doing "Save As" before performing these actions works as expected.Your Environment
Expected behavior
Ranges remain valid when references are stored in
worksheet.names
on first usage of add-in when installing from AppSource Marketplace.Current behavior
As noted above, this issue only happens on first usage of a newly installed add-in. That means that the following sequence of events is required as a precursor:
worksheet.names
are bad.If the document is closed and a new one opened, the issue will no longer be present. It only occurs in this initial load that the installation is bootstrapped to.
Steps to reproduce
The issue has been confirmed on installation of several different add-ins, but repro steps will use the Script Lab add-in since it will be used to run the code that demonstrates the issue.
worksheet.names
.After completing the above steps the following will occur: An error will be thrown when attempting to freeze the header row of the sheet. This appears to in some way be caused by the bad references stored on
worksheet.names
:After clicking "Display Worksheet Names" another
console.log
will output the bad data I believe is the source of the problem here:Note here that the first item shows
"type": "Range"
and"value": "'Worksheet 1'!$A$1"
(a valid range in the worksheet). The second and third items both show"type": "Error"
and"value": "#REF!"
since they were added afterworksheet.name
is set.The sequence executed when clicking "Configure Sheet" in the included Script Lab script is as follows:
worksheet.names
for A1 (this range is stored correctly)worksheet.name
to "Worksheet 1"worksheet.names
for B1worksheet.names
for C1freezeRows
to freeze row 1Link to live example(s)
Live example can not be provided as this only occurs on installation of a new add-in.
Context
Our add-in uses these named ranges to open a dialog when cells in certain columns are selected. This allows users to interact with our application's API to populate cells with data from the product's database. Since these are associated with bad range references this makes the add-in unusable immediately upon installation.
At this time our only idea is to insert a warning into the workbook that informs the user they must close this document and create a new one in order to start using the add-in which is a poor first impression.
Additional Information
Issues can also be observed when attempting to call
worksheet.activate
. Callingworksheet.activate
before the name is set works as expected, but doing so after settingworksheet.name
results in a very nondescript "GeneralException: There was an internal error while processing the request." As with the other issues this only occurs on the initial document load from the "Open in Excel" link on the AppSource Marketplace.Useful logs
Log information is found above in Steps to Reproduce.