Can and can't do

[CC]

Hi everyone,

I am trying to explore what an Outlook add-in can or cannot do. Here
are some questions I have in mind:

1. I know it is not possible to add a new button on the Navigation
Pane, but is there a way to somehow intercept its listener? (i.e. can I
create a callback method that responds to the "Calendar" button on the
Navigation Pane?)
2. This is related to the last question. Is there a way to fire an
event back to the Navigation Pane? (i.e. simulate a "Calendar" button
click in Navigation Pane so the view will switch back to the calendar
pane)
3. Can I create a custom pane to replace any of the existing panes
(e.g. the preview pane in "Mail", calendar pane in "Calendar", etc)? I
heard it is possible to add a custom pane in folder view window in 2000
using MAPI, is there something similar in 2003?


Other interesting questions:
1. I notice most of the sample codes or tutorial out there are in VBA,
but I am coding in C++ ATL for the sake of integrating a third party
library. Any recommendations on where to find good resources/books?
2. I am also aware of the new .NET Outlook 2003 Integration API. Is it
more powerful than the existing object model or is it just easier? If I
used that instead of native code, my plug-in will definitely not work
in previous versions of Outlook, correct?

Thank you,
CC,

 

[Ken Slovak - [MVP - Outlook]]

Forget about using the Nav Pane for any coding. Even if you replicate some
of the internal XML the pane may or may not use that depending on the phases
of the moon or something. Not reliable at all and not supported.

Creating a custom task pane is a job that involves Extended MAPI and using
the Win32 API's to overlay things. Very messy and hard and not really
documented much if at all.

There are some examples of C++ coding in the KB and some samples at
www.outlookcode.com.

The .NET interface to Outlook through the COM InterOp is no more powerful
than direct COM coding. You do have the chance to use the framework features
though. As far as easier/harder, it's definitely harder and there are a
number of unresolved bugs and known bugs that you have to work around. For
myself I do all my Outlook coding using a COM language and never mess with
..NET. In the words of a very prominent Outlook developer ".NET is a less
than compelling story for Outlook coding".