Add Workbook.calculate() to avoid recalculating all open workbooks
Today, the Office.js API exposes Excel.Application.calculate(calculationType), but it recalculates all currently opened workbooks in Excel. This becomes a performance and UX problem when users have multiple large workbooks open and an add-in needs to trigger calculation only for the workbook it’s running in. Request: Please add a workbook-scoped calculate API that recalculates only the active workbook, while reusing the existing Excel.CalculationType enum (recalculate, full, fullRebuild). Example API shape (one option): await Excel.run(async (context) => { context.workbook.calculate(Excel.CalculationType.recalculate); await context.sync(); }); This would preserve the current semantics of Excel.CalculationType while avoiding unintended recalculation of unrelated open workbooks (the current Application.calculate behavior).
Improving Excel Add-in API failures when in CellEditMode
Hello Microsoft Add-in team! I'm developing an Excel Add-In and have some suggestions relating to Excel.ErrorCodes.invalidOperationInCellEditMode. I'm finding that having the Excel Add-In APIs all either delay execution or throw the CellEditMode error while the user is in cell edit mode is making for a bad user experience in my Add-in. For example, at launch, my Add-In TaskPane needs to check the workbook CustomXML for metadata specific to my Add-In. But (if I'm not mistaken) I can't do that if the user is in cell edit mode. It seems I have to call the API, get a failure, then tell the user something like "The Add-In is waiting for you to finish editing your cell" and try again with { delayForCellEdit: true }. It's messy. So my suggestions are three, supposing CellEdit errors are in some cases necessary: 1.) Can we make it so that not *every* API call is blocked when in CellEdit mode? For example, why should reading/writing CustomXML be blocked because of cell editing? Is the error being thrown unnecessarily in some cases? 2.) Can we add a new "addHandlerAsync" event for CellEditMode enter/exit, to allow a TaskPane to disable buttons that aren't going to work while the user is in CellEdit mode? Disabling such buttons (with explanation, of course) could make for a better TaskPane user experience than having the user clicking a button and getting an error. (I do realize the error could still happen, as change events seem to fire on a delay, but they might at least happen less frequently!) (For example, in my Word Add-In, I am enabling/disabling buttons based on user's content selection, and the experience seems to be nice, even with the slight delay.) 3.) Can we add another callback param to "Excel.run({ delayForCellEdit: true }, ...)" so the developer can know that their API calls will be delayed and the user can be prompted to exit CellEditMode? (That might clean up me having to try, catch and then retry with delay?) I'm sure you've thought about all this more than I have, but these are the issues I'm running into. Thanks for your time and keep up the good work!Outlook Addin - enable Clipboard API
Outlook Addin currently does not support Clipboard API, because containing iframe does not have appropriate permissions. Currently the only other option to copy text is to use deprecated document.execCommand("copy"). For more information, please see this issue: https://github.com/OfficeDev/office-js/issues/1991
Preserve Add-in signature HTML on Outlook for iOS across all clients
Summary When an Office Add-in inserts HTML into a message on Outlook for iOS (for example, an email signature), Outlook for iOS rewrites the inline CSS at the point the content is added to the message body. The rewritten CSS uses modern shorthand and the currentcolor keyword, which classic Outlook on Windows (the Word based rendering engine) does not render correctly. The result is that recipients opening the message in classic Outlook on Windows see missing or incorrect styling, most visibly missing border colors on signature elements. The same message renders correctly when opened in Outlook on the web, new Outlook for Windows, Outlook for iOS, and Outlook for Android. Only classic Outlook on Windows is affected, because only the Word rendering engine fails to interpret the rewritten CSS. Who this affects Any organisation using a third party signature Add-in (or any Add-in that injects styled HTML) on Outlook for iOS, whose recipients include users of classic Outlook on Windows. This is a large population: classic Outlook on Windows is still the default client in many enterprises. We are raising this on behalf of a significant number of affected customers who currently have no workaround. What we observed We insert this HTML into the message via the Add-in: <td align="left" style="padding:12px; border-top:none; border-right:none; border-bottom:none; border-left:solid 8px #F5F736; vertical-align:top; font-family:Calibri,Arial,sans-serif;"> Outlook for iOS rewrites it, before it is committed to the message body, to: <td dir="ltr" align="left" style="white-space: nowrap; border-width: medium medium medium 8px; border-style: none none none solid; border-color: currentcolor currentcolor currentcolor #F5F736; padding: 12px; vertical-align: top;"> Two behaviours are problematic: The individual border-top, border-right, border-bottom, border-left declarations are merged into border-width, border-style, and border-color shorthand. The merged border-color uses the currentcolor keyword for the three unset sides. Classic Outlook on Windows does not honor currentcolor reliably in this context, and its handling of this particular shorthand combination drops or miscalculates the actual colored side. The colored border the sender intended is not displayed to the recipient. Why this is a problem specifically for Add-ins Authors of Office Add-ins cannot control what the host client does to HTML after body.setSignatureAsync, body.setAsync, or equivalent insertion APIs are called. The HTML we provide is valid, and it renders correctly on every other Outlook surface. The rewrite is happening inside Outlook for iOS, silently, and we have no API to opt out of it. Reproduction Build a simple Outlook Add-in that inserts the HTML snippet above into a new mail message using the standard Office JS body insertion APIs. Send the message from Outlook for iOS (tested on iOS 18.3.2, Outlook for iOS 4.2513.1). Open the sent item in Outlook on the web or Outlook for iOS: the yellow left border renders correctly. Open the sent item in classic Outlook on Windows: the left border color is missing. Prior report This was previously reported against Office JS on GitHub: https://github.com/OfficeDev/office-js/issues/6521. The response was that the issue will not be fixed in the short term, and the recommendation was to raise a Tech Community item so the team can gauge demand. That is what this post is for. What we are asking for Ideally one of the following: Stop Outlook for iOS rewriting inline CSS that was supplied by an Add-in through the supported insertion APIs. Pass the author's HTML through unchanged, or If normalisation has to happen, avoid emitting currentcolor and avoid collapsing per side border properties into shorthand in ways that known Outlook rendering engines cannot interpret, or Publish a documented, supported HTML and CSS subset that is guaranteed to round trip across all Outlook clients (including the Word rendering engine in classic Outlook on Windows), so Add-in authors can target it deliberately.
Ability to dynamically change ribbon button at runtime
Our ribbon button actions are awkward! We need the ability to interact with them more dynamically at runtime. Ideas: Change Office.Ribbon.RequestUpdate() so that it can change a ribbon button's label at runtime, like the "Protect Sheet"/"Unprotect Sheet" button in the Review tab. Give us the option to create toggle buttons in the manifest and in contextual tabs, like Excel's native "Filter" button in the Data tab, or the "Bold" button. Change Office.Ribbon.RequestUpdate() so that it can remove a ribbon button, or change its icon, at runtimeAbility to disable Copilot Agent / Edit functionality on a sheet + Copilot events
We developed an Excel addon which intercepts certain Excel events - sorting of Excel tables, editing cells, etc. on special add-on managed sheets. This functionality is broken when Copilot Agent/Edit starts modifying the sheet. Would it be possible to disable Copilot Agent/Edit mode on particular sheets in full and to provide rich API to intercept Copilot's actions?Get selected chart element in Excel JS API
We need to read the data point when a user clicks on one of the parts of a bar chart or pie chart. Something like getSelectedChartElement() that points to the underlying cell range where the data point resides. Or a Chart event whenever a chart element is selected.Support for Split Button in ribbon
We need a way to declare a split button (an action button with a drop down menu accessible by clicking the down arrow next to the button. (like. the Flags split menu in Outlook (button can clear the flag while dropdown menu can select a flag). The manifest could be a menu with an ExecuteFunction at the item level. If an execute function is present, the rendering is a Split-Button otherwise it's a classic menu. A example taken from New Outlook for MacOS. The split button exists, but it's unavailable to office.js add-ins.Add Method to Create Hyperlinks in PowerPoint JavaScript API
I am writing to request the addition of a method in the PowerPoint JavaScript API that allows developers to programmatically convert text into hyperlinks. Currently, this functionality is available in the Word JavaScript API, where the Range.hyperlink property can be used to set a hyperlink on a range of text. However, a similar capability does not exist in the PowerPoint JavaScript API. At present, the only ways to create hyperlinks in PowerPoint are through the user interface or by using VSTO add-ins. These methods are not ideal for developers who wish to automate the process within web and Mac add-ins. Implementing a method to set hyperlinks on text within the PowerPoint JavaScript API would greatly enhance its functionality and bring it closer to parity with the Word JavaScript API. This addition would be beneficial for developers seeking to create more robust and feature-rich PowerPoint add-ins. Thank you for considering this feature request. I believe it would be a valuable enhancement to the Office.js library and look forward to any updates on this matter. Sincerely, Simon Breslav
