Is it possible to access Office.context.document.settings from VSTO?
We have an VSTO AddIn that currently writes to the CustomXML in Excel workbooks. We would like to make it Napa/O365 compatible. Since Napa can't read CustomXML parts in Excel we want to write to Office.context.document.settings, hence the question above.
Or is there a better way to share storage between VSTO and Napa in a Excel workbook?
Ron.
The JavaScript for Office API can't be used in a VSTO solution, as it requires a web context. Your desktop add-in solution would have to be ported to use the web-based APIs and tools.
Related
I have recently moved from developing VBA Excel Add-Ins to using the new Office JavaScript Add-ins platform. I am used to my VBA Add-In being active across the whole of Excel and the state of the variables is available no matter what workbook you are interacting with.
This does not seem to be the case with JavaScript Add-ins. I have been testing my Add-In and happened to create a new workbook and noticed that none of the Add-In state appeared to be active any longer.
Am I missing something or is this a consequence of the new Office JavaScript Add-ins architecture where it runs inside a browser within Excel?
Just to confirm I have already enabled the Shared Runtime option, that is not my question. I am able to share state between Commands, Takspane and Functions. But all within a single workbook.
I have tried one of the example Yeoman generator for Office Add-ins and it certainly seems that global variables are not shared between the Add-In in two different workbooks.
This behavior is expected. With Office (web) add-ins, each add-in runs in an embedded JavaScript runtime that is a completely separate process from Office and any other add-ins, so it cannot share data across add-ins. Some people have made sharing across add-ins work using the OfficeRuntime.storage object, but it only works in Windows. It won't work on Mac or in Office on the web. Frankly, the Office platform team considers it a bug that it can be done on Windows and that may be fixed at any time, so you should not create an add-in that depends on it even if you know your add-in will only be run on Windows.
Depending on what your scenario is, you might be able to store state in the document with either Office.document.settings or Office.document.customXmlParts. Another possibility is to store state in a database on your server side.
(Desktop version) I'm new to using the javascript API for excel, but is it possible to create an excel add-in and share with other users without having to add the add-in to an app source etc? Can it be embedded in the excel file etc. I'd like to share scripts with other users the same way that I can share VBA if it's possible?
for security reasons as well as to make manageability of your add-ins easier, we do not store the code within the workbook, like VBA. Instead, the javascript is hosted on your website and we have a reference to your add-in saved in the workbook.
What this means, is to get a similar experience to VBA, you must either have the add-in hosted on app source (which will make it accessible via the Office Store), OR each user in an organization must have the add-in deployed or available to them (here we recommend centralized deployment as it will give the most robust experience).
This has all the current deployment options you can use for Office add-ins: https://learn.microsoft.com/en-us/office/dev/add-ins/publish/publish
thanks!
I am creating an Office 365 plugin for Excel using Angular. I use Office-JS library to interact with Excel. My plugin appears in the Excel task-pane.
I want to know that my add-in is open/close in task-pane via code, I want to know as I need to solve some issue related to this in my add-in.
Unfortunately our API doesn't provide the event for Taskpane open/close. which is a known feature gap.
So would you please provide us feedback via https://officespdev.uservoice.com/forums/224641-feature-requests-and-feedback?category_id=163563 and upvote for this feature. Thanks for your support.
I'm currently developing a tool using the Office javascript API. However, I would like to provide an own Excel function (something like =SUM(A1:A5)), which is based on code in C#.
Is there any way to avoid shipping two individual plug-ins from the users point of view? Can I combine both technologies to one plug-in?
If you are only targeting the desktop version of Excel then you can create a VSTO add-in instead of a JavaScript-based add-in. Within this adding you can include the code for your custom functions in the VSTO project and make sure they are correctly registered. One solution could be to create your own MSI-based installer, e.g. using Windows Installer XML (WIX) or Nullsoft's NSIS tool.
With this "classic" VSTO add-in technology you won't be able to target Excel on Mac, on mobile platforms or Excel Online in the browser though.
Yes there is also an alternative solution to creating a desktop C# add-in with VSTO or ExcelDNA as suggested by Dirk.
A javascript web add-in is just a web page with a library : office.js filling the gap between your logic and the office host application.
Why not passing the input to an API written in C# (this can be or not the same server serving the add-in) that will do the calculation ? The javascript will be there only to pass data and set the calculation results in spreadsheet.
I use ILMerge to combine my dlls. You can add it as a post build command so that they are merged on successful build.
I'm developing an Office Excel Task Pane add-in, and I have the need to import the content of external files (other spreadsheets and PDF files) into the active workbook.
On VBA (also VB and C#), workbooks could be open with the Workbooks.Open() method, but it is not available on Office/Excel JS library.
So, how may I open files from Office/Excel Task Pane add-ins?
Thanks in advance!
At this point in time our APIs do not support opening external applications.
Please feel free to submit your feature request at https://officespdev.uservoice.com/ and we will take it into account for future APIs.
Regards,
Philip, Developer on the Microsoft Office Extensibility team