I have build a MDG Toolbox. I have a windows form which is created using C#.
Now We want to enable i.e to open the windows form only when the particular stereotype is selected in the project browser of EA.
When the context item (selection) is changed, EA fires an event to all Add-Ins. In order to respond, write a handler called EA_OnContextItemChanged() in your Add-In main class.
Related
The Add In
I have written a VSTO Add-In for Outlook. The crux of the add-in is to put a button on the Ribbon when a user is replying to email that will allow them to quickly set the Email Sensitivity to Confidential or back to Normal. Currently the process to do this on an email is multiple steps, and my client wants it to be one click. The button icon is Red or Green based on the sensitivity of the current email.
Sensitivity = Normal => Red Button
Sensitivity = Confidential => Green Button
There are a few basic use cases I have uncovered:
A user Creates a new Email
In this case the button should start Red and change when clicked.
A user Creates a reply to an email
In this case the button should start the same color as the parent email. If the parent email was Red, the button should be Red and if it was Green the button should be Green
A user Edits a draft
If the user has a draft the button should reflect the value of the Sensitivity property of the saved draft.
The way I chose to accomplish this was with two buttons in a ribbon XML where I override the getVisible property and based on the current MailItem set the appropriate button visible. Another way would have been to have one button and toggle the image and functionality based on MailItem sensitivity property.
Regardless of my choice I think I would have run into the same problem in that the Office Ribbon is meant to be a static object, drawn once at creation of the Explorer or Inspector and you need to force a redraw by calling the InvalidateUI method.
With that in mind, to cover my 3 use cases above I had to hook into some events from the application.
I'm not sure I can post the exact code, but the basics of it are as follows:
On Startup subscribe to:
Application.ActiveExplorer().SelectionChange
Application.Inspectors.NewInspector
On SelectionChange
If there is one item selected, and that one item is a MailItem
Refresh the Ribbon UI - Call Ribbon.InvalidateUI();
On NewInspector
If the Inspector.CurrentItem is a MailItem
Refresh the Ribbon UI - Call Ribbon.InvalidateUI();
The SelectionChange event handler covers if a user is clicking around in Outlook 2013 and up and selects an Inline Draft. It will draw the ribbon in the TabSet TabComposeTools, TabMessage. This places the icon on the main outlook window Ribbon when necessary.
The NewInspector event handler covers if the user double clicks on the draft, creating a new window.
The Problem
I have been receiving reports of Outlook crashing. At first I had limited logging and relied on the Event Logs generated by Outlook. Not very helpful.
Then I implemented log4Net, and I'm writing to a log file in the AppData folder of the user's profile. This has given me some insight
I have wrapped a try/catch around every method code block, so nothing in my add-in (that I wrote) runs outside of a try/catch, and each block just catches Exception, logs it, and throws it. This is an attempt to find the problem.
My latest log shows the UI refreshing, so it called my GetVisibility override, in there based on if the control.Context is an Explorer or Inspector I get the ActiveInlineResponse or CurrentItem as a MailItem, read the Sensitivity property and based on that return True or False if the button calling the handler should be visible. (I have one handler for both buttons)
The crash appears to happen when I am casting an ActiveInlineResponse to a MailItem. The next item in my log is the logging I do in the Startup handler of the Addin. (So the user restarted Outlook)
Other Details
The user base is currently running Outlook 2010 - Outlook 2016.
We have one add-in that runs on all of them as nothing we are doing should be specific to any version of office.
The add-in works without fail on Outlook 2010.
The add-in project selected was Outlook 2013-2016.
I'm using Ribbon XML over Designer because Designer doesn't support putting buttons in TabSets.
Update
I have put in some event handler local variables to my Add-In class as described by https://www.experts-exchange.com/questions/27305112/Problem-with-VSTO-event-handler-going-out-of-scope-in-Outlook-AddIn.html I haven't seen the error since, but also haven't had much feedback as I did this on a Friday and this Monday is a holiday. I'll update with an answer if this appears to be a "Fix".
I am creating a new VSTO add-in for Outlook 2013 & 2016. I have setup a Ribbon (XML) with a button that fires an event, which eventually opens a standard WinForm. The design (Ribbon location, menu, popup window size & location, etc...) is based off the "Signatures" ribbon button under "New Message".
Everything is fine and dandy until I realized that some of the features I want needs Outlook-specific controls. Adding them to my project's toolbox, I found out that they can only work on Outlook Form Regions, and not standard WinForms. I am able to get this to work with the standard FormRegion under the "New Message", but this is not desired behavior. Instead, I would prefer to have it pop up much like the standard "Signature" panel.
I would prefer solutions in C#/VSTO. If a solution would require a third-party alternative to VSTO, I would rather implement this in C++ instead.
i am developing an Outlook AddIn for Outlook 2010 with VS 2010.
When the user opens some Mails, and he changes the focus from one mailitem to another: Is there any event which can give me the currently displayed/focused mailitem?
It looks like you are interested in the SelectionChange event of the Explorer class. It is fired when the user selects a different or additional Microsoft Outlook item programmatically or by interacting with the user interface.
If you switch between inspectors, you need to handle the Activate event of the Inspector class. It is fired when an inspector becomes the active window, either as a result of user action or through program code.
I am using System.AddIn library from .NET 3.5 AddIn & Extensibility features. I have a requirement to add a Button in the toolbar of the existing application which acts as Add Host. I was able to add the button and invoke the custom Win Form from the button click action.
OnClick of the Add-In button, I am invoking a win form which loads WebBrowserControl. Every thing work perfect except the none of the Keyboard events get triggered. If I make my form as Dialog window Keyboard events get triggered. I am bit blocked due the behavior. Any inputs would be appriciated.
Thanks,
Nags
Does anybody know if it is possible (and in that case how) to navigate programmatically in an Office 2010 addin?
The idea is to create a settings button on a ribbon tab, that when clicked, will direct the user to the settings of the add-in that would be located in the backstage view. Is there a way to programmatically change the active view being displayed to the user or something like that?
Thank you!!
As a developer putting on the user spectacles, I find your approach not convincing. If I click on a settings button, I expect a well-designed dialog, not to be thrown into backstage view. On the other hand - as a developr I'm much more at ease with a well-designed Windows Form than with the controls Microsoft provides for the backstage user interface; I guess you'll find there more limitations then you like.
As far as I understand your question, you want to have two different entry points to your settings dialogue - one from a button in the ribbon, and another from a point in the backstage view. Why not combining and showing from both positions the same form? Also Microsoft provides you with additional dialogues, if you click on controls in the backstage view.
Technically:
If you want to start the action of a ribbon control, you can use the "ExecuteMSO" command of the application.commmandbar object, e.g. in Word you may use
Application.CommandBars.ExecuteMso "ApplicationOptionsDialog"
to open this dialogue. However, I've done a limited test to call a custom button in backstage view, and it failed. Sol I guess that you can use ExecuteMSO only for built-in commands.