|
Sven Knauer
Guest
|
I've implemented an event handler of an Outlook context menu button's PropertyChanging event.
The event handler registration:
_addinModule.OpenAttachmentsContextMenuButton.OnClick += OpenAttachmentsContextMenuClick;
The event handler:
private void AttachmentContextMenuOpen(object sender, ADXRibbonPropertyChangingEventArgs e)
{
try
{
if (e.PropertyType == ADXRibbonControlPropertyType.Enabled)
{
Log.Debug($"{nameof(AttachmentContextMenuOpen)}: Fired!");
AttachmentSelection context = e.Context as AttachmentSelection;
if (context != null)
{
IOutlookAttachmentSelection attachmentSelection = new OutlookAttachmentSelectionWrapper(context);
using (IOutlookApplication application = new OutlookApplicationWrapper(context.Application))
using (IOutlookExplorer explorer = application.ActiveExplorer())
{
if (explorer != null)
{
UpdateContextMenu?.Invoke(this,
new ContextEventArgs<IOutlookAttachmentSelection>(explorer, attachmentSelection));
}
}
}
else
{
if (Log.IsDebugEnabled)
{
dynamic c = e.Context;
Log.Debug($"{nameof(AttachmentContextMenuOpen)}: unexpected context parameter with Class = {c.Class}");
}
}
}
}
catch (InvalidCastException ice)
{
Log.Warn($"{nameof(AttachmentContextMenuOpen)} - exception ignored", ice);
}
catch (Exception ex)
{
Log.Error($"{nameof(AttachmentContextMenuOpen)}", ex);
}
}
On my machine the context never null, but an instance of the AttachmentSelection COM object.
On one of our customer's machine it is always an Explorer object.
I've found this https://www.add-in-express.com/docs/net-ribbon-components.php#context which states it could be an Explorer, and I need to be ready for every types.
My questions are: do you have any idea, what is the difference between my machine and the customer's machine? What determine which object will I get as the ADXRibbonPropertyChangingEventArgs's Context?
Thank you. |
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello Sven,
I don't understand your code. I assume you create and release COM objects behind the scenes. Still, you should understand that using an Outlook.Application other than the one provided via the OutlookApp property of the add-in module may end with your add-in raising Outlook security warnings.
Sven Knauer writes:
I've found this article which states it could be an Explorer, and I need to be ready for every types.
That article is a general-purpose one.
As to your case, I remember, some Outlook 2016 builds returning AttachmentSelection and other returning Explorer. There was a topic right on this forum. I've found it: at https://www.add-in-express.com/forum/read.php?FID=5&TID=13763, the developer reported the issue existed on 16.0.4312.1000 - this is one of the first Office 2016 builds. I suggest that your user updates their Office.
Andrei Smolin
Add-in Express Team Leader |
|
|
Sven Knauer
Guest
|
Hi Andrei,
thank you for your quick response, as always.
You may be right, my customer really using a 64 bit Outlook, and I will ask him to update.
Yes, you are right, we've just wrapped the COM releasing stuff in a .Net facade object, and using the IDispose in the add-in where possible.
Do you think the context object (which is an AttachmentSelection COM object) Application property may be different than we get from the Addin-Express? I've used this Application, becasue I thought it must be a valid object as I just got it from the event handler parameter. |
|
|
Dmitry Kostochko
Add-in Express team
Posts: 2875
Joined: 2004-04-05
|
|
Forums
Topics
Search
Help
Login
Register