What are differences between adxOutlookEvents_ItemSend and ProcessSend?

What are differences between adxOutlookEvents_ItemSend and ProcessSend?

Byung Kun Kim

Posts: 48Joined: 2011-12-15

There are two different locations that I can handle outlook mail send event.
Which one is better? Just the same functionality? One thing I know is 'adxOutlookEvents_ItemSend' can be used without connectTo method.

In one of your example source code, 'outlookItemEvents.ConnectTo' is called when InspectorActivate. InspectorActivate(and ExploreActivate either) event occurs on every inspector window or outlook itself got focused. Is it safe to call connectTo method multiple times without removeConnection? (Though adxOutlookEvents_InspectorClose event occurs just one time when inpector window closed.)

adxOutlookEvents_ItemSend is the last event which occurs during the process of sending an email. Note that MailItem.Send occurs on an early stage; the user may cancel the process "manually" after this event occurs.

Byung Kun Kim writes:
In one of your example source code, 'outlookItemEvents.ConnectTo' is called when InspectorActivate. InspectorActivate(and ExploreActivate either) event occurs on every inspector window or outlook itself got focused. Is it safe to call connectTo method multiple times without removeConnection?

In almost all examples I created, I implemented the approach requiring just one instance of the events class. This instance is reconnected to the selected Outlook item when you select an item or when you activate an explorer window. This events class instance is connected to the opened Outlook item when you activate an inspector window. When using this approach, you need to disconnect from the previously connected item before connecting the class to another item.

In other situations, you may need to manage an array (list, dictionary) of events class instances. The reconnection logic may be different but disconnecting from an item (it is a COM object!) is correct when reconnecting the events class to another item.

Thank you for your reply, could you please how user can cancel? some delayed mail you mean?
-> I tested, but using delayed mail option, both two events occurred when I click send button. (here, another question, how can I capture delayed mail send event? no event was captured)

Could you explain some usage scenarios? when to use Application.ItemSend and when to use MailItem.Send events?

---

When using only one itemEvents class instance, with connectTo on InspectorActivate, ProcessBeforeAttachmentAdd event was missed when I drop a file to no-focused window. or send button click on not-focused window. I'm not sure both of them or one was missed the events. (some old memory)

Does reconnecting needed when creating each itemEvents for inspector? Can I approach below way? connect on NewInspector and removeConnection on InspectorClose. This time what can be the key for dictionary, 'inspector As Object' can be a key?

Byung Kun Kim writes:
Thank you for your reply, could you please how user can cancel? some delayed mail you mean?

Imagine entering an incorrect email address which isn't recognized when the recipient is being resolved. In this case, Outlook shows a message box which allows the user to cancel the send operation.

Byung Kun Kim writes:
When using only one itemEvents class instance, with connectTo on InspectorActivate, ProcessBeforeAttachmentAdd event was missed when I drop a file to no-focused window. or send button click on not-focused window. I'm not sure both of them or one was missed the events. (some old memory)

I'm afraid, I don't follow. Whatever you do with a non-focused window, it becomes focused as soon as you touch it in any way. Accordingly, this fires the InspectorActivate event. In the event handler you need to disconnect from the currently connected Outlook item and connect to the item from the inspector just activated.

Byung Kun Kim writes:
Does reconnecting needed when creating each itemEvents for inspector?

If you *create* an Item Events class, then you don't need to *re*-connect it.

Byung Kun Kim writes:
Can I approach below way? connect on NewInspector and removeConnection on InspectorClose. This time what can be the key for dictionary, 'inspector As Object' can be a key?

I wouldn't call RemoveConnection on InspectorClose. This is because immediately after closing an inspector you get one of the following events:
- ExplorerActivate
- InspectorActivate (e.g. there was two inspectors, you close one of them, the other one becomes active)
- the add-in unloads

That is, you can use InspectorActivate, ExplorerActivate, and ExplorerSelectionChange to disconnect from the currently connected item and connect to another one. Inspector can't be used as a key. This is because the inspector parameter passed to your event handlers is released as soon as your event handler finishes. This occurs with all COM objects that Add-in Express passes to your code.

You could bypass this restriction by getting an inspector object yourself but I wouldn't recommend this because the Inspector object (actually, each object that the Outlook object model returns) is a COM object. And Outlook is specifically sensitive to COM objects that your add-in doesn't release: many, many problems occur due to a COM object(s) left unreleased.

Could you please describe what you need to achieve? Probably, there are some other ways.

I'm afraid, I don't follow. Whatever you do with a non-focused window, it becomes focused as soon as you touch it in any way. Accordingly, this fires the InspectorActivate event. In the event handler you need to disconnect from the currently connected Outlook item and connect to the item from the inspector just activated.

Thank you. Now I see. That is, although the event does occur, it isn't handled just because the events class is connected to the events of the Outlook item in the active inspector window.

In this case, you need to connect (re-connect) to items opened in *all* Outlook inspector windows. This means, you need to manage a dictionary of events class instances. The best place to add an instance to that list is the NewInspector event (see the Outlook Events component). To remove such an instance, you need to use the InspectorClose event. And using an Inspector object as the key is rational.

Byung Kun Kim writes:
It seems working well using inspector key dictionary though (just now?), what would you recommend for my approach? for the key! I'm afraid of using inspector key, too.

I suppose this works because Add-in Express maintains a list of inspectors and it releases an Inspector object only when the corresponding inspector closes, right after Add-in Express generates the InspectorClose event. So, it looks like you can use an Inspector object as a key.

This technology is now available for our custom development services only. Based on the Add-in Express for Office core, it is designed for building custom-tailored Office add-ins with far less coding than you usually have to do. Plus, it includes all Add-in Express features such as True RAD, visual designers, Outlook view and form regions, etc.

Get the best platform for building version-neutral, fast and easy deployable plug-ins by using Add-in Express projects templates, visual designers, components and wizards in combination with a perfect Delphi compiler.

This is an extension for Visual Studio that allows developers to quickly create WiX-based setup projects in a familiar Visual Studio way.

The Designer for WiX Toolset lets you forget the plain Windows Installer XML and concentrate on your deployment logic. It integrates several editors with the Visual Studio IDE and provides a set of vdproj designers to configure the file system, registry, user interface, custom actions, launch conditions and more for your setup projects.

The innovative technology for customizing Outlook views and forms. It is included in all Add-in Express for Office products and can be used to extend Outlook views, e-mail, task and appointment windows, To-Do bar, Reading and Navigation panes with your own custom sub-panes.

Microsoft and the Office logo are trademarks or registered trademarks of Microsoft Corporation in
the United States and/or other countries. All other trademarks are property of their respective owners.