we have a working outlook form in our company which includes a button in outlook ribbon
By clicking it a New Mail window opens which has the designed custom form with some combo-boxes, the printscreen image is attached
Below this form there are some VB Macros which fills the combo-boxes and runs some code and when we click Send, a new mail which has this form will be sent for the recipient(s) The Problem is: the recipient receives the vb macros behind this form and sometimes this macros will be accidentally modified and ..., so we don't like this approach
Currently I'm working on a C# VSTO project to replace a AddIn(.dll) with this macro.
My first solution: I have imported a copy of the custom form as a form region and add combo-boxes and other controls in it and fill them and everything was ok, but this form have not been sent by mail to recipient!
My Second solution: I think it would be better to remove all macros from the old custom form and try to fill combo-boxes of the old custom form in my AddIn.
My Question is which solution is better? Is there a better way to do this?
I think I'm going wrong direction because of lack of knowledge with VSTO and outlook forms. please help
Outlook custom forms is an old approach. Defintely, form regions is the better way to go. But it requires better coding skills. Be aware, Outlook form regions can't be sent to recipients with the item.
You need to have the Outlook add-in installed on both sides (sender and recipients) if you want to see the data entered on the form region. Moreover, you have to create corresponding user properties on the item being sent. On the recipient side your add-in can handle the NewMailEx event of the Application class which is fired when a new item is received in the Inbox. So, you may read user properties and display on the form region. Also you may consider using any web server (web service) for uploading such data there. In that case you will be sure the data is preserved when user properties are truncated on the recipient side.
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".
Is there an easy way to disable , hide and capture the event of click of outlook mail send button ? The solution has to be compatible with outlook 2007 and 2010 versions. Code examples will be appreciated.
Thanks.
You can handle the Send event of the MailItem class which is fired when the user selects the Send action for an item. Also you may find the ItemSend event of the Application class helpful. It is fired whenever an Microsoft Outlook item is sent, either by the user through an Inspector (before the inspector is closed, but after the user clicks the Send button) or when the Send method for an Outlook item, such as MailItem, is used in a program.
To disable or hide the button you may consider using a form region which can override the whole inspector region leaving the ribbon control intact (the Replace-all region type). See Creating Outlook Form Regions for more information. Also you may consider using Advanced Outlook view and form regions.
I want to have an explorer like column (something like list of emails in inbox) that comes with Outlook. In this column I want to populate list of data, where I could drop any email from the my inbox list.
How should I proceed to achieve this, any hints OR links where I could move forward as I am new to Visual Studio development. I went through couple of tutorials where I can design a form (with an icon coming at the tool bar and it opens a different window on click), but I am wondering if it is possible to have a form visible within the same explorer window (on the right hand side ) with a flexibility to show OR hide it.
The reason I want it on the same window is because I want to achieve drag and drop functionality for my emails in inbox to my custom list data in my new column. e.g. associating email X and Y to process Z in column C.
Thanks
You need to develop an Outlook add-in with an adjacent form. Unfortunately the Outlook extensibility model doesn't provide anything for that out of the box, so you need to use Windows API functions or use third-party software to get the form shown in the Explorer window. You can read more about the adjacent forms on the Creating Adjacent Windows In Outlook page where you can also find the sample code. Or may consider using Advanced Outlook view and form regions as an alternative.
FYI Command bars were deprecated and are not used any longer. The Fluent UI is used instead.
I would like to develop an Outlook 2013 add-in that can be clicked and then comes up with a form that asks for user name, phone number etc.
After all the information entered that data can be appended to the end of the mail content as the signature.
I really don't know how to call the form with input text field when clicking the add-in.
Could you give me any ideas?
You may treat your VSTO based add-in as a regular .Net application. For example, in the Ribbon's button Click event handler you can create a new Windows Form instance and display it for users for gathering the required information. In the same way like you do this in WinForms applications.
You may find the Outlook Solutions section in MSDN helpful.
I want to add a form with a submit button in it in an outlook mail which I could send to a group. Once user clicks on submit button, I want data in the form to be saved in my database. Any idea how to do?
It looks like you need to develop an Outlook add-in with a form region where you can place all your custom controls for dealing with a Db. See Walkthrough: Creating Your First Application-Level Add-in for Outlook to get started quickly. The Creating Outlook Form Regions section in MSDN provides all the required information about form regions.
You can repurpose button controls on the ribbon in Outlook. See Temporarily Repurpose Commands on the Office Fluent Ribbon. But the Send button is not located on the ribbon in Outlook inspectors. You need to handle the Send event of Outlook items instead.
Also you may consider handling the ItemSend event of the Application class. It is fired whenever an Microsoft Outlook item is sent, either by the user through an Inspector (before the inspector is closed, but after the user clicks the Send button) or when the Send method for an Outlook item, such as MailItem, is used in a program.