Neat ways to get environment (i.e. Office version)
Neat ways to get environment (i.e. Office version)
Neat ways to get environment (i.e. Office version)
Re: Neat ways to get environment (i.e. Office version)
**Update Dec 5, 2016: We will soon be releasing an API to detect the platform info** (partially in response to the fact that the `_host_info` URL paramater, which folks had unofficially relied on, needed to be recently removed for Office Online). We also have a temporary workaround in anticipation of the forthcoming official API. **See "[In Excel Online, OfficeJS API is not passing the host_Info_ parameter anymore to Excel Add-In](https://stackoverflow.com/questions/40688057/in-excel-online-officejs-api-is-not-passing-the-host-info-parameter-anymore-to/40963500#40963500)" for information on the API and workaround.**
I am keeping the **old answer** below, as it is *still relevant for most light-up scenarios*. **Platform-detection should still be used sparingly, as querying API sets give you more fine-grained control**, and ensures that your add-in "lights up" new features when they are added to a particular platform].
It sounds like you're describing a "light-up" scenario. For these sort of use cases, it isn't so much the *actual* version that you care about (do you really want to keep an internal list of all the minimum versions -- of Excel desktop, and soon Excel Online and iOS, and keep that updated?), but rather, you want to check the *capability* that something is present. And then offer a differentiated experience depending on whether the capability is there or not.
To that end, I would recommend a brand-new API that we just released alongside these APIs (and that is back-ported to all previous versions -- so as long as you're using the latest Office.js from the CDN, you should be good to go). That API offers you the ability to check, at runtime, whether a particular API set is supported. It looks like:
`if (Office.context.requirements.isSetSupported('ExcelApi', 1.1)) {
// Do something that is only available via the new APIs
}
```
Official documentation for it is forthcoming shortly, and our sample will soon start using it as well. Stay tuned...
Th
*(Réponse tronquée)*
I am keeping the **old answer** below, as it is *still relevant for most light-up scenarios*. **Platform-detection should still be used sparingly, as querying API sets give you more fine-grained control**, and ensures that your add-in "lights up" new features when they are added to a particular platform].
It sounds like you're describing a "light-up" scenario. For these sort of use cases, it isn't so much the *actual* version that you care about (do you really want to keep an internal list of all the minimum versions -- of Excel desktop, and soon Excel Online and iOS, and keep that updated?), but rather, you want to check the *capability* that something is present. And then offer a differentiated experience depending on whether the capability is there or not.
To that end, I would recommend a brand-new API that we just released alongside these APIs (and that is back-ported to all previous versions -- so as long as you're using the latest Office.js from the CDN, you should be good to go). That API offers you the ability to check, at runtime, whether a particular API set is supported. It looks like:
`if (Office.context.requirements.isSetSupported('ExcelApi', 1.1)) {
// Do something that is only available via the new APIs
}
```
Official documentation for it is forthcoming shortly, and our sample will soon start using it as well. Stay tuned...
Th
*(Réponse tronquée)*