Issue
I've had users reporting that the button for reaching our task-pane Office Add-in (on the ribbon) disappears. There are cases where multiple add-ins are enabled, but ours is the only one that is missing. Seems like it is occurring on both Mac and Windows.
When they look in the Store it still looks like it is enabled. One way to fix it is to remove the add-in and install it again, but when it happens reguraly it's annoying and users can't bother to fix it every time.
The add-in is hosted on S3 in AWS
The add-in is configured to only be visible when composing email
Question
What could be the cause of this happening? How can we fix it?
There is currently no known issues surrounding this. Where the Add-in is hosted, should not matter. If where your icon is cannot be reached, then your add-in will load after a certain amount of time with a default icon. (this does not sound like what is happening, but this can cause your add-in to not show up for a while)
In general, when users complain about this, it is because they have switched tabs on the ribbon. This can be confusing because add-ins are in a different location when doing an inline reply vs doing a pop-out window. (see below screenshot). Most of the time, this occurs during inline reply, and the user has clicked away from the "message" ribbon to the "Home" ribbon. Clicking back on the "message" ribbon, and the add-in should show up again. If the "message" ribbon is not there, then selecting another message, then back on the draft should put the "message" ribbon back.
Another possible explanation is that an admin has disabled the add-in, but not installed it.
If this is not what is happening, we would need more information on the repro steps. Version numbers of the Client Hosts. Version number of the server, and perhaps a copy of the add-in manifest.
Related
I work on an add-in for Microsoft Outlook, and we’ve noticed that in the Outlook Web App our Add-in cannot open at all when we attempt to open it from the “More Add-ins” button. The menu that lists more add-ins will open, but then clicking our add-in closes the menu with nothing happening.
We used to have our Add-in’s ribbon menu open when it was clicked here. We first encountered the broken behavior yesterday (7/28/22).
We’ve checked if this is happening to all Add-ins with a list of ribbon commands, and this seems to be the case for all Add-ins. To reproduce this error, we’ve implemented Microsoft’s example for Add-in commands (https://github.com/officedev/outlook-add-in-command-demo) by uploading to https://officeapp.s3.amazonaws.com/command-demo-manifest.xml and installing from URL.
Clicking the “Add-In Command” closes the menu, and nothing happens.
The expected behavior is a list of commands should show:
Additional Note: The ribbon command menu correctly appears if the Add-in is pinned to the toolbar via Settings->Mail->Customize actions->Toolbar. This is how we were able to take a screenshot to demonstrate the expected behavior.
Thank you.
Thank you for reaching out. This is a known issue within the Outlook web client. We are working on a fix for this issue, but do not have a timeline to share at this moment.
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.
When trying to open Outlook 2007 on Windows Server 2003, I get this error message:
“A dialogue box is open. Close it and try it again.”
I try and open Outlook in safe mode by using outlook /safe (in the Run command) and it works fine after it says configuring outlook accounts "Please enter your full name and initials below" (the full name and intials fields are already prefilled) and I click the OK button on the same and I answer the RSS Feeds subscription as either Yes or No.
Once I try closing and reopening Outlook, again I see the same error message as “A dialogue box is open. Close it and try it again.”
This does not let me open any new window to send emails. How can I fix whatever is causing this error?
It could possibly be due to an add-in that is acting up. Try to determine which add-in it is by disabling them one by one until it is identified. To disable an add-in, go to the Tools menu, click Trust Center, and then click Add-ins. A list of add-ins are listed. For each Type of add-in you see, choose them in the Manage listbox at the bottem and click Go. Uncheck the add-in to disable it.
Try using Task Manager to end any other Outlook processes, then try opening it again. Your problem could be due to a non-responsive Outlook process, or a background one.
Good luck!
Do you happen to use a virtual window manager (like virtuawin or bbbLean)? If so, you may not see the modal dialog box as it is in another virtual window and Outlook will not accept any input. It happens to me often and at first I was frustrated that Outlook 'hangs' frequently and is not a robust app. For me it was dialog box that said something like "Do you want to auto-archive the folder?".
The dialog box may also be hidden behind the main window. You can try using Alt-TAB to cycle through you windows and you should see the dialog box.
This was caused by a windows update on windows 2003 server.
I did a system restore to an earlier point and it worked fine. Thanks for the support.