M
MacTruck
I know there are some MVPs around here that can answer
this question. The background to this problem is long-
winded, so bear with me.
I am the author of an add-in for Outlook that attempts to
add an Office CommandBar object to every object type that
supports it. I'm using the C++ ATL COM way of doing
things using Visual Studio .NET 2003. I can't use VBA for
this because of the type of application I'm working with.
So, being stuck with C++ and ATL COM, adding CommandBars
to objects should be logically straight-forward, right?
Make sure everything has proper sink maps and what-not for
the CommandBars and the Explorer object. Getting all of
that hooked up is fairly straight-forward. The purpose of
this add-in is NOT automation (which may be part of the
problem - the Outlook objects are designed, more or less,
for automation only). From the Explorer object, I want to
be able to click on my Office::_CommandBar object and open
a new Mail object and insert or attach (depending on the
settings) the item. **All of this works fine**. The
trouble starts when attempting to add the same CommandBar
object to any Outlook Inpsector object. Whenever there is
a new Inspector object being created, the Explorer object
gets notification of its creation. During the
notification, a new class is instantiated that
specifically handles managing the CommandBar and Inspector
object for the Inspector.
Problem #1: When the CommandBar is added, sometimes the
object is a NoteItem object. CommandBars are invalid for
these types of objects, so a COM error is raised and the
CommandBar is NOT added for this object and the COM error
is basically ignored. Also, during the creation process,
different versions of Outlook are handled for Outlook
2000, XP, and 2003 and whether or not Word is the e-mail
editor. You can imagine the mish-mash of code that is
running here to do different actions based on version and
there obviously has to be something wrong when, in order
to get something correct operation, an AddRef() has to be
done in the constructor to not get Outlook to NOT hang on
exit. Is there something I am missing in MSDN or is there
some big hush-hush secret I'm not being let in on. Surely
a hack like this isn't necessary and there is a cleaner
method...I'm using smart COM pointers all over the place
and still have to AddRef() objects.
Problem #2: Outlook 2000 refuses to close on exit when
NoteItem objects are opened and closed when the add-in is
installed. Simply opening and closing a NoteItem object
causes Outlook 2000 to not close on exit. Outlook XP and
2003 are fine. This is probably due to some weird oddity
with COM throwing an exception when the CommandBar is
attempted to be added. I've tried detecting that it is a
_NoteItemPtr and it still doesn't fix the problem
(although it did fix a weird crash issue).
Problem #3: Outlook, from time to time, will create what
I call "ghost" Inspector windows. I call them that
because there is no reason on earth to fire the
NewInspector event. Whatever is happening is going on
behind the scenes and is _usually_ a hidden mail object.
Used to have a crash bug with this until I moved to smart
COM pointers - doing the EXACT same thing as normal COM
pointers - and appears to be related to when Outlook
queries the exchange server for new mail. This says to
me, as a programmer, that the Outlook object model is
flaky at best and miserably buggy at worst.
Problem #4: A customer with roughly 1000 licenses of the
product containing the add-in is running a mix of Outlook
2000/XP systems and they have problems with TaskItems and
ContactItems where, when the add-in is installed, users
can't edit objects more than once without getting
notification that the object is locked for editing.
Occasionally, the user who just edited the object gets
told that they themselves have the object locked. Also,
when Outlook gets in a state like this, it refuses to
close (stays in the list in Task Manager).
Problem #5: I tried to find a way to detect Inspector
objects being created the same way Explorer objects are
created (e.g. via the OnConnection() method from the
IDTExtensibility2 interface) and didn't find any, so I do
my Inspector hooking during the NewInspector event.
Perhaps this can all be cleaned up if there is a way to
add a CommandBar through the IDTExtensibility2 interface
instead of this hack'ish workaround to the problem?
I suspect the NoteItem bug in Outlook 2000 and the other
problems (especially #4) are related somehow.
Technically, there should be nothing different between
using normal COM pointers and smart COM pointers...but
there is. Also, detecting the version of Outlook to
determine whether or not to do an AddRef() is not kosher.
Something is wrong and what I really need to see is C++
ATL COM source code for a _correctly-written_ add-in that
works with all Explorer and Inspector objects.
MacTruck
this question. The background to this problem is long-
winded, so bear with me.
I am the author of an add-in for Outlook that attempts to
add an Office CommandBar object to every object type that
supports it. I'm using the C++ ATL COM way of doing
things using Visual Studio .NET 2003. I can't use VBA for
this because of the type of application I'm working with.
So, being stuck with C++ and ATL COM, adding CommandBars
to objects should be logically straight-forward, right?
Make sure everything has proper sink maps and what-not for
the CommandBars and the Explorer object. Getting all of
that hooked up is fairly straight-forward. The purpose of
this add-in is NOT automation (which may be part of the
problem - the Outlook objects are designed, more or less,
for automation only). From the Explorer object, I want to
be able to click on my Office::_CommandBar object and open
a new Mail object and insert or attach (depending on the
settings) the item. **All of this works fine**. The
trouble starts when attempting to add the same CommandBar
object to any Outlook Inpsector object. Whenever there is
a new Inspector object being created, the Explorer object
gets notification of its creation. During the
notification, a new class is instantiated that
specifically handles managing the CommandBar and Inspector
object for the Inspector.
Problem #1: When the CommandBar is added, sometimes the
object is a NoteItem object. CommandBars are invalid for
these types of objects, so a COM error is raised and the
CommandBar is NOT added for this object and the COM error
is basically ignored. Also, during the creation process,
different versions of Outlook are handled for Outlook
2000, XP, and 2003 and whether or not Word is the e-mail
editor. You can imagine the mish-mash of code that is
running here to do different actions based on version and
there obviously has to be something wrong when, in order
to get something correct operation, an AddRef() has to be
done in the constructor to not get Outlook to NOT hang on
exit. Is there something I am missing in MSDN or is there
some big hush-hush secret I'm not being let in on. Surely
a hack like this isn't necessary and there is a cleaner
method...I'm using smart COM pointers all over the place
and still have to AddRef() objects.
Problem #2: Outlook 2000 refuses to close on exit when
NoteItem objects are opened and closed when the add-in is
installed. Simply opening and closing a NoteItem object
causes Outlook 2000 to not close on exit. Outlook XP and
2003 are fine. This is probably due to some weird oddity
with COM throwing an exception when the CommandBar is
attempted to be added. I've tried detecting that it is a
_NoteItemPtr and it still doesn't fix the problem
(although it did fix a weird crash issue).
Problem #3: Outlook, from time to time, will create what
I call "ghost" Inspector windows. I call them that
because there is no reason on earth to fire the
NewInspector event. Whatever is happening is going on
behind the scenes and is _usually_ a hidden mail object.
Used to have a crash bug with this until I moved to smart
COM pointers - doing the EXACT same thing as normal COM
pointers - and appears to be related to when Outlook
queries the exchange server for new mail. This says to
me, as a programmer, that the Outlook object model is
flaky at best and miserably buggy at worst.
Problem #4: A customer with roughly 1000 licenses of the
product containing the add-in is running a mix of Outlook
2000/XP systems and they have problems with TaskItems and
ContactItems where, when the add-in is installed, users
can't edit objects more than once without getting
notification that the object is locked for editing.
Occasionally, the user who just edited the object gets
told that they themselves have the object locked. Also,
when Outlook gets in a state like this, it refuses to
close (stays in the list in Task Manager).
Problem #5: I tried to find a way to detect Inspector
objects being created the same way Explorer objects are
created (e.g. via the OnConnection() method from the
IDTExtensibility2 interface) and didn't find any, so I do
my Inspector hooking during the NewInspector event.
Perhaps this can all be cleaned up if there is a way to
add a CommandBar through the IDTExtensibility2 interface
instead of this hack'ish workaround to the problem?
I suspect the NoteItem bug in Outlook 2000 and the other
problems (especially #4) are related somehow.
Technically, there should be nothing different between
using normal COM pointers and smart COM pointers...but
there is. Also, detecting the version of Outlook to
determine whether or not to do an AddRef() is not kosher.
Something is wrong and what I really need to see is C++
ATL COM source code for a _correctly-written_ add-in that
works with all Explorer and Inspector objects.
MacTruck