JavaScript API does not work for Excel 2013

Question

The modification recommendation report for one of the add-ins I provided has just arrived. Your add-in is not functioning in Excel 2013 client on Windows 7 with Internet Explorer 11, according to the message. I've always used Excel 2016 and Excel Online to test my add-in. Therefore, the add-in does not function after I just installed Excel 2013 (version 15.0.4841.1000, which contains SP1). But it appears that not many things do.

For instance, the following example function produces nothing in Excel 2013 but writes haha in Cell A1 under Excel Online.

function test () {
    Excel.run(function (ctx) {
        var range = ctx.workbook.worksheets.getItem("Sheet1").getRange("A1");
        range.values = [["haha"]];
        return ctx.sync();
    });
}

So does anyone know if JavaScript API supports Excel 2013? If not, many professionals will not be able to use add-ins because they are still with Excel 2013...

PS: I see many add-ins in the office store that require Excel 2013 or later or Excel 2013 Service Pack 1 or later. If JavaScript API does not support Excel 2013, how have these add-ins (eg, Stock Connector) been developed?

Answer 1

Each method in the Office.js APIs is marked with an API set designation, which you can see when using them.

These API sets match the Office versions that the add-in will support. 

Excel 2016+ (and its Office Online and Mac/iOS equivalents) are the only platforms that support any of the new Office 2016 host-specific API sets (ExcelApi, WordApi, etc.). The API version number (1.1, 1.2, and 1.3) refers to API improvements that were made after Office 2016's RTM build (which shipped with 1.1 out-of-the-box). Customers that subscribe to Office 365 have access to those updates (home or business). Customers who purchased Office 2016 as a disk/MSI product will only have the original 1.1 APIs.

The requirement sets can be put to two different uses. You should identify any API sets that your add-in 100% depends on in your manifest file. That way, the add-in won't even be proffered on the "Insert/Manage Add-ins" dialog for Office versions that don't support that particular API set. On the other hand, if you're only using a few APIs in the set, and could do without (even if it's a bit of a degraded experience), you can do the "light-up scenario". That is, you will list the lowest possible version that you do need, and then use a runtime check to detect whether a particular API set is available. 

Concrete example: suppose you have an Excel Add-in that creates a new sheet and outputs data into a table. This requires ExcelApi 1.1 version or higher. Ideally, you would also like to be able to set the column widths, but range. format.column width is only available in ExcelApi 1.2. You don't want to block customers from using your Add-in if they have an old version -- after all, the bulk of your functionality will still work, even if not optimally -- but you do want to make use of the new APIs. In that case, you should specify ExcelApi 1.1 in your manifest, and then do a runtime check in your JavaScript to determine if you can run the range. format.column-width code. I.e.:

if (Office.context.requirements.isSetSupported("ExcelApi", 1.2 )
{
   range.format.columnWidth = 25;
}