I want the user to press on a command button which will run an API. If the API returns results, I want this to launch the taskpane and then display the result of the API.
Is this possible?
If we speak about web add-ins the task pane is launched by the button click independently of API results. At runtime you may decided what to display on the task pane.
But if you mean a custom task pane as a part of COM add-in you can do whatever you like - hide, show and etc.
For web add-ins, launching a task pane after running some code/API is not possible today. We track Outlook add-in feature requests on our Tech Community Page. Please submit your request there and choose the appropriate label(s). Feature requests on Tech Community are considered, when we go through our planning process.
Here are two alternatives I would suggest considering to see if they can work for your scenario
adding a command with ExecuteFunction as an action https://learn.microsoft.com/en-us/office/dev/add-ins/reference/manifest/functionfile and launching a dialog (displayDialogAsync)
Or, run ExecuteFunction that adds notification message with an action link that user can click to open a taskpane https://learn.microsoft.com/en-us/javascript/api/outlook/office.notificationmessageaction?view=outlook-js-preview
Related
i'm running timer on task pane Add-in in outlook. when user inactive means if user switch to other tab I need to stop timer and when user back click on outlook mail, I need to resume timer. can anyone guide how to do this?
OfficeJS doesn't provide any events for that. You may consider posting your suggestion to the Tech Community at https://aka.ms/M365dev-suggestions, feature requests are considered when the team goes through our planning process. Don't forget to use the Github label: “Type: product feature request”.
In case of COM based add-ins (VSTO) you could handle the Inspector.Activate an Inspector.Deactivate events for the inspector windows in Outlook. If you need to deal with Explorer windows you may consider using the Explorer.Activate
Im currently developing Outlook Add-In, which is supposed to be a CRM. It loads 3rd party Web App in the task pane, where user has to log in. On desktop Outlook, I can make task pane pinnable and refresh it on item change. On the OWA, it looks like I can't pin my task pane, but I want at least to force Add-In, to not reload itself each time user changes e-mail. It loads from scratch every time with new session/cookies and user needs to relog again. Any ideas if it is possible? Or how can I work around this?
I've been experiencing a mysterious problem where the task pane hosting my add-in closes completely after code in my add-in sends and receives an XMLHttpRequest - but ONLY with the new Outlook Online UI. It works perfectly fine in Outlook desktop on Windows and Mac. There are no exceptions thrown in the web debugger and nothing relevant from my add-in's console logs. I can set a single breakpoint on random lines of code in various functions across multiple app classes that are run after the button that fires the webrequest is clicked, and the breakpoint gets hit and stops for a second – before the task pane closes completely. It is very bizarre.
I’ve also ran a network trace of what happens when the task pane disappears, and notice that two requests always occur in the new Outlook Online only (the numbers change but are always sequential):
https://outlook.office.com/owa/service.svc?action=GetConversationItems&n=55&app=Mail
https://outlook.office.com/owa/service.svc?action=GetConversationItems&n=56&app=Mail
I’m guessing that the new Outlook Online is erroneously detecting a context switch of some kind to trigger any open task panes to close. And note that the task pane NEVER disappears when the task pane is pinned or when the task pane is hosted in a full item window.
Here’s a recording of the task pane disappearing: https://www.screencast.com/t/RO7p0Zu5oP. Note how the selection of the current email is also cleared.
I know I'll be asked to provide a code sample, but given how the add-in has been firing this web request for months without issue until running in the new Outlook Online, I can't see how the problem lies within my code. Also note that:
Add-ins cannot close a read item task pane with code, only compose add-ins can (mine is a read mode add-in)
Only the user changing the message selection should close a task pane (if it is not pinned)
Add-ins cannot change the message selection
Any exceptions in the add-in that cause it to crash should be handled by the add-in framework and a message should be displayed in the task pane header (e.g. "This add-in is not responding"). The task pane should NEVER close
Is this happening to anyone else? Can somebody on the Office Dev team confirm that there's no way this scenario should occur?
Whenever I have an add-in open in outlook, it closes immediately when I open a different email. Is there a way to keep an add-in open while I browse through multiple emails? Or is outlook coded in such a way that forces the add-in to close every time you click on a different email?
Thanks.
As far as I understand your questions you are the user of the Outlook Add-on. If this is correct, you will not be able to change this behavior. Every time you switch the item you would need to click to invoke the add-on once again. You may also contact the developers of this add-on and request them to implement a pinnable taskpane with explanation of your business case.
Well, if I was wrong and you are the developer of this add-on, you should look at pinnable taskpane in Outlook. This would cover exactly the case you have described. What you would need to do is just support VersionOverrides v1.1 schema in your add-on manifest as well as register and implement the Office.EventType.ItemChanged event handler in your add-on JS implementation.
I have one windows form UI wizard as custom action in MSI setup project in Visual Studio 2013. During installation one small progress bar dialog appears on top of the UI. This dialog also has a Cancel button and text like 'Please wait while Windows configures....'
Can we hide or disable this dialog somehow? Can we disable the Cancel button on this dialog? Or can we take this dialog behind the main UI so that user will not be able to click Cancel? Or Can we detect this Cancel button click event and handle in custom action?
There's no good answer to this, so basically this is just information.
The Windows Installer architecture expects all UI to be done in the first UI sequence, that's where data is entered. You probably understand this from the vast majority of other setups that do this. The execute sequence is intended to be silent except for errors and a progress bar. When Visual Studio setups allowed installer classes as a way for people to run managed code custom actions I don't think they expexcted people to have UI there. It often doesn't work because of the STA/MTA thread differences for message pumps, and since Windows Installer itself knows nothing about your custom action showing UI (there's not supposed to be UI!) it still believes it has the user's focus. The other issue is that many customers expect to be able to do silent installs, your requirement for a UI wizard defeats this.
I think some people have tried to solve your problem by enumerating all the Windows on the system to find the Windows Installer one and forcing it to the background, but I haven't seen anything recently on this or any code examples.
In your case, if your UI data can be collected up front with one of the canned UI dialogs then try that. Unfortunately VS setups don't give you a way to validate the input. If the UI wizard is for the app itself then it's usually easier to do it when the app first runs, as well as being easier to test and debug, being able to run later to reconfigure, and avoiding this kind of issue.
The limitations of VS setups include not being to design your custom dialogs to collect and validate input in the expected way at the beginning UI sequence. Also you cannot disable the Cancel button because VS custom actions run after everything is installed, which is too late to send the message saying "disable the cancel button". The overall issue is that you're fighting the limitations of VS setups, and another tool might be a better way to go, or have that UI wizard run at first boot of the app.
I am able to hide the progress bar dialog itself using Win32 APIs.