We have an add-in that is intended to be used when a user is remotely logged into a server. They open outlook, start a process with the add-in, then leave their session logged in but disconnect their session. The server is setup to never go to sleep and to leave the user logged in the entire time. As expected we can reconnect and outlook is still open and running just fine. Or at least that used to be the case...
We are using Redemption in the add-in to trigger a button on a 3rd party ribbon control as part of the process. This was working fine for months. It still works fine when using the app. However if you are disconnected from the RDP session or if you simply lock the screen with CTRL-ALT-Delete, it throws the following error when it tries to execute the control.
System.Runtime.InteropServices.COMException (0x80004005): Error in
IAccessible.accDoDefaultAction: MAPI_E_CALL_FAILED at
Redemption.ISafeRibbonControl.Execute()
Here is the code it is running through at that time:
Redemption.SafeExplorer sExplorer = new Redemption.SafeExplorer();
sExplorer.Item = Application.ActiveExplorer();
Redemption.SafeRibbon Ribbon = sExplorer.Ribbon;
Ribbon.ActiveTab = "RIBBONTABNAMEHERE";
ISafeRibbonControls Controls = Ribbon.Controls;
Redemption.SafeRibbonControl Control = Controls.Item("CONTROLNAMEHERE");
Control.Execute(); //<--HERE IS WHERE IT DIES
Marshal.ReleaseComObject(sExplorer.Item);
Marshal.ReleaseComObject(sExplorer);
Marshal.ReleaseComObject(Controls);
Marshal.ReleaseComObject(Control);
Marshal.ReleaseComObject(Ribbon);
I've tried a million things but I can't figure out why executing a control without the user connected even if they are logged in still no longer works. This worked for a long time!
Related
I am looking if it is possible to create a Reconnect button for the Reconnect function usually invoked by checking the Outlook Connection Status.
It would help me a lot to not have to open this dialogue but to just press Reconnect immediately from a button on the Ribbon.
Reason: We seem to have a lot of performance issues (O365) at our Management assistants. We also notice a reconnect gives them air.
I know this is not a solution but at least a workaround for the problems at hand.
Many thanks!
Mike
I have experienced this behavior in my automation application: when I "click" a button by calling the InvokePattern.Invoke() method everything stops until the handler of the click event inside the automated application finishes.
While this can make some thing simple (for example I don't have to write tons of code to wait for a dialog with progress bar to disappear, because I simply get the control back when everything is done), but I can't do anything else. It even blocks the access to the Automation API in another thread where it continues after the click handler is done.
This causes problems when click handler in the automated application opens a modal dialog, then I can't do anything, the access to the application through automation API is blocked until the dialog is manually closed.
Has anybody solved this somehow and can help me?
Thanks,
Karel
PS: Reference source is saying this:
Request that the control initiate its action.
/// Should return immediately without blocking.
/// There is no way to determine what happened, when it happend, or whether
/// anything happened at all
public void Invoke() { ... }
Edit: It works perfectly when automating Windows notepad application which is not a .NET application. And it does not work for a Notepad clone (C# WinForms aplication).
My problem concern an application which is currently running in production since 6 months. But last week, one user reported me this :
Above all, this application is a complement to Outlook, which allows users to create, edit and delete tickets through a new tab in the ribbon.
When this user clicks on a button (Create), a window is supposed to appear. In my code, this window is used in two places, one to create the ticket and the other to edit the ticket. When the user wants to edit a ticket, this window appears without problem. But just to create, he won't appear.
I call the window like this for creating :
Dim oForm1 As Create_form
oForm1 = New Create_form(Nothing)
oForm1.Show()
And like this for editing :
Dim oForm1 As Create_form
oForm1 = New Create_form(ticket)
oForm1.Show()
And here is the constructor :
Public Sub New(ticket As Ticket)
InitializeComponent()
MaximizeBox = False
actualTicket = ticket
Init_List()
Init_Fields()
End Sub
I have looked for solutions on the Internet, but it seems I am the only one with this problem. This code worked for this person until last week without any change.
One possibility I thought about is the Microsoft redistributable and the Outlook version (Developed and tested on Outlook 2016, used on Outlook 2013...).
Any ideas ?
Thanks for your help !
Ps : Please excuse my more than average English
First of all, make sure your add-in is enabled and running in Outlook.
Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in that has been disabled article.
Most probably the form is displayed behind the Outlook window. To show a form on top of the Outlook window you need to specify the parent window handle. In .net based applications or add-ins you typically use Windows forms classes to show a window. The Show and ShowDialog methods of the System.Windows.Forms.Form class accept an instance of the IWin32Window interface which stands for the parent window handle. See How to set the Window.Owner to Outlook window for more information.
Finally I found the solution, for the creation of one ticket, I'm using the system date with a specific function. But, the user who have the problem change the default setting in the Windows configuration. So the form could not be displayed due to an unmanaged exception (English date when the software expect French date).
I've written an Excel addin that periodically checks a remote repository for data updates, including a check when the addin loads at Excel start up (during the addin's Workbook_Open event). If new respository data is detected, the addin asks the user for permission to proceed with the update. If the user clicks "yes", the addin successfully updates itself and everything is happy... except...
If Excel is not already running and the user selects an Excel file to open (e.g. via double-click in Windows), this sequence of events occurs and everything works, but the user-requested file opening is interrupted and not re-engaged. The Excel app is running, but with no workbook loaded (the workbook area is an empty frame).
I believe I have two options, neither of which I know how to accomplish:
Prevent the addin from completing its update check until the user-selected file has completed its open sequence and is fully loaded, or
Allow the addin to update itself and then somehow re-engage the user-selected file to complete the file open/load.
I have not been able to discover the filename/path of the user-requested file, so my addin isn't able to direct that file to be loaded.
My current workaround is a MsgBox telling the user to close Excel and re-open the selected file. Ideally, the addin update should occur and the original action should complete without requiring user intervention.
(Building on Option 1, I could start a delay timer for the addin to check for updates XX number of seconds after Excel starts, but this seems kludgy to me.)
Any guidance or ideas are appreciated. My interwebz searches aren't hitting the right combination of keywords for the exact scenario.
Instead of opening the new addin update file immediately you can use OnTime to delay it which should allow the other file to open successfully. See here: Process for updating Excel add-in?
In the answer you'll also see a reference to this package here which does everything you need. Autoupdates are hard so I would recommend going with someone else's solution.
http://www.decisionmodels.com/downloads.htm#addload
(Scroll down to Add-In Loader Version 2)
I wrote a VB.NET Windows Forms app that requests a string from an out-of-process COM object every time the activate event fires. My form has two tabs, so I need to programmatically flip to the correct tab every time my window gains focus. Works fine, until...
By chance, someone ran a vbscript (yes, script, not exe) that contains:
Set shell = CreateObject("WScript.Shell")
shell.AppActivate("Window Title That Matches My App")
This script consistently crashes my app. Usually so badly that the Exception dialog usually can't paint itself. I have to kill it from task manager. Sometimes the Exception is readable. (I also confirmed the exception by attaching to the running exe with Visual Studio). It's: "System.Runtime.InteropServices.COMException (0x8001010D): An outgoing call cannot be made since the application is dispatching an input-synchronous call."
What's really messing with my mind is that my app has multiple instance detection using a mutex, and if an existing instance is running, my own code (compiled) uses VB.NET's own AppActivate keyword, and this does NOT crash my app. It activates the running instance and exits the redundant instance as expected.
The problem seems solely to be triggered by cscript/wscript's AppActivate. I wrote a 3-liner .vbs to confirm this. It's repeatable.
Is there a way to trap or avoid this in my compiled app?
It's not clear to me WHY this approach actually fixes the problem, but it DOES work:
Add a timer to the form.
Move all the _Activated code to the timer's _Tick event.
Make the _Activated event start the timer.
Make the _Tick event stop the timer then perform the COM stuff.