We currently have a team that uses an Outlook Add-In (call it Add-In A) that we developed internally that attaches to the Send event and, if some rules around the From address and Subject are met, a form is displayed, data is written to a SQL database and the email is sent. This works fine.
We've also just had a company-wide rollout of a third party Outlook Add-In (call it Add-In B) that checks any emails you send to see if they're going to an external address and if so asks if you're sure you want to send. Again, this works fine.
The problem is when these two are combined. While there's no technical problem where they conflict or anything like that, there is a potential logical error where you could try and send an email, Add-In A kicks in, the user completes the form and data gets written to the database. Then Add-In B kicks in, warns the user they're sending an external email, they decide against sending and the whole process is cancelled. However, the database has been updated to say it was sent, which is incorrect.
I'm struggling to think of any way to prevent this - if we could force Add-In B to fire before Add-In A then that would solve the issues, but I'm pretty sure that you can't specify the order that each Add-In should fire or be enabled, and we have no control over the code for Add-In B as it's a third party product.
Any suggestions to prevent this from being a possible outcome?
First of all, you may handle the ItemAdd event of the Sent Items folder in Outlook to be sure that a mail item (Outlook Item) was sent for sure. Be aware, the Sent Items folder can be specified an runtime using the SaveSentMessageFolder property of the MailItem class.
Also you may choose the ProgID name for the add-in to make sure that your add-in is loaded after others. The events are fired in the reverse order. But all of these facts are not documented and can be changed at any time. Nobody can guarantee that it work stable all the time.
Related
Since upgrading to Office 2013, we have some issues with an Outlook add-in disabling itself. I know that the time it takes to start can be an issue, but while we've done everything possible to speed it up, the fact it is a .net add-in means that, on our systems, we cannot get it to start faster than 1 second - the threshold beyond which Outlook disables it automatically.
We previously modified the add-in to catch all exceptions in all interfaces by default. The add-in should never pass an exception back to Outlook, but I have seen the odd occasion where Outlook's internal interface has crashed, disabling the add-in.
The add-in itself is critical to the way part of our application works - outgoing emails are intercepted and scanned, and if they meet certain criteria, uploaded to a document management system automatically. The users love it, except when it doesn't work.
I know when the add-in gets disabled, Outlook is meant to warn the user via a notification bar, but this doesn't always happen, especially in Citrix, where users don't have the requisite permissions to enable or disable add-ins.
Ideally what we would like is some way to warn a user when the add-in is not enabled. Obviously the add-in can't do this, because if it's not enabled it can't warn the user that it's not enabled. Does anyone know of another way of doing this?
I am using Add-in Express(v 7.6.4084) to create an Outlook plugin.
The problem is, that the MailItem.PropertyChange isn't triggered when reply an email on reading panel.
I have searched several topics but wasn't able to find a solution.
Seems you are talking about the inline response feature. If so, you need to use the ActiveInlineResponse property to get an item object representing the active inline response item in the explorer reading pane. It fires the PropertyChange event as expected on my PC with Outlook 2013 installed.
Note, you need to declare the source object at the global scope to prevent it from being swiped by the garbage collector.
I have a RibbonBar with some Buttons that appears in the Outlook Explorer (Double Click on a mail).
Some progresses in the background edit the attachments of the mail. If the user close the Explorer, outlook will ask to save the edited mail (save the changes).
is there a Event to handle this? i don't want that the message appear if my programm has changed the mail.
I wasn't succesfull on the search for an Event. But maybe i just missed something.
There is no need to handle any event for this.
If the user close the Explorer, outlook will ask to save the edited mail (save the changes).
This is a good indicator that changes were not saved or Outlook objects (actually underlying COM objects) were not released correctly. Use System.Runtime.InteropServices.Marshal.ReleaseComObject to release an Outlook object when you have finished using it. Then set a variable to Nothing in Visual Basic (null in C#) to release the reference to the object. You can read more about that in the Systematically Releasing Objects article in MSDN.
Some progresses in the background edit the attachments of the mail.
Don't use the Outlook object model from secondary threads. Office applications (Outlook in your case) use the single threaded apartment model. You can gather the required info on the main thread (keep it in a string for example) and process it on another thread. Or you can use a low-level API (Extended MAPI) which allows to run multiple threads. Also you may consider using any wrapper around that API. Frankly speaking, Outlook is a big wrapper around that API.
My Excel addin (XLL AddIn, call it MyAddIn) is built with C#, ExcelDNA, NetOffice, VS2010. Client has another addin (let's call it B), I guess it is written in VBA.
Client says B works fine without MyAddIn. Once MyAddIn is installed, B fails with error:
Error code: 406
Error message: Non-modal forms cannot be displayed in this host application from an ActiveX DLL, ActiveX Control, or Property Page.
I did see this Microsoft resource, but I do not want to just tell the client that B addin needs changing. I want to do something to avoid this from my side.
Here is the steps reported to see the issue:
When B addin is installed, it does not make any registry entry for the Microsoft Excel.
When MyAddin is installed, it makes a registry entry for Microsoft Excel.
Registry entries here basically tells that the addin should be opened when Excel is launched, so B addin is not launched, Excel works fine, MyAddIn works fine.
Now when B addin is launched, it gives the 406 error shown above.
We can ignore the error and keep working with the B addin; disabling MyAddIn is the workaround.
When the B addin is launched, we see that MyAddIn is loaded first before the B addin and then get the 406 error.
When we uninstall MyAddIn, this error is no longer encountered and everything works fine.
To remove this error, we tried changing the registry order to make the B addin always open before MyAddin.
This works, but then this a global change for Microsoft Excel, which means B addin will always open, even when we launch only Excel. This is not desired, as B addin then can't let users work with the static data as the B addin keeps on refreshing real-time. That is the reason the B addin doesn't make an entry in the registry settings. So registry changes are not an option. We can’t always open B addin whenever Excel is open.
I don't have an answer, but here are a couple of things you can try.
You can tell what type of Addin you are dealing with by executing File | Options and selecting the Addins Tab.
If the event happens as soon as you load Addin B, it probably means you are calling a non-modal dialog box as it states, but there are a few other things that could give you similar errors.
Based on your description, it sounds like the error could either be a dialog box in your Addin, or it could be in the other addin, and it gets called as a side effect of some state change your addin made.
To get to the bottom of it, you need to attach a debugger. You can do that by making Excel your Startup Project, or by attaching later. The former is probably easier in this case.
In Visual Studio, Use Project | Properties | Debug, select Start external program and put in the fully qualified pathname to Excel.
Load Addin B manually to give yourself the error
Break into the debugger and examine the call stack.
That will frequently but not always give you good clue as to where the problem is, but it's always the first step. If it doesn't give you useful information (stack info is frequently completely lost in transitions between addins), you may want to put some breakpoints in your projects in any events you handle. Even this doesn't reliably work all the time, but it's worth a shot.
If I had to guess, I would say probably have some event handlers in your add-in that are causing the problem, And you might have to do something like change a .Show to a `.ShowDialog', or defer the processing of the form until outside the event handler but that's just a guess.
Bit of a weird one this: I've got a shared Office addin that currently targets Outlook 2007 on XP and Win7 (Excel/Word and other versions later). It adds a toolbar button, and this fires off my code. My code just reads data from Outlook. First time round, it works a treat. Second time, the button click does nothing. No errors, nothing. The rest of Outlook responds as normal.
The entire event code is in a try/catch that writes any exceptions out to a temporary file (this mechanism works if a throw an exception in code), but nothing is picked up.
According to the "Trust Center", my addin is active (not inactive or disabled). If I restart Outlook, or stop and start the addin via the Trust Center, it again works once and then stops.
If I reduce the amount of work my code does, the button will sometimes respond for about ten clicks or so, then gives up. Whichever version of my code I try, resources don't seem to change much (memory moves up a mite, the thread count stays the same).
I've read of a similar thing with Word, but this was explained by Word recreating the toolbars or menus every time it loads a document (not sure how correct this is). For me, I select an email, click once, it works, click again (no changing views in Outlook, selecting different emails, etc), and it doesn't.
Has anybody got any clues here?
You should place the variable that contains your toolbar buttons to a global scope (You can keep then as fields of the addin object). If you don't keep a valid path to them at all times, .NET garbage collector will eventually clean up these objects and the event handlers with it. This will however not remove the visible button so it will still be visible.