T
Ted Byers
I have downloaded piles of examples, most of which seem to have been
developed after VS6 was released. Some are not documented and others
contain errors (according to VC++6). I am extremely frustrated.
The closest I got to getting something working is where I created an ATL COM
project. But I got stuck on how I can gain access to Outlook's contact
data. I am ONLY working with contact data, and my design is simple. I will
be using a mix of DLLs and EXEs (one of which MAY be on some other machine),
but the key to the design if the in-proc COM object. It will talk only to
Outlook 2000 or later, and to a COM object living in the exe that may or may
not be on another machine. It needs to detect Add, Change and Delete events
generated by the user using Outlook, and send the complete contact data to
the COM object in the exe. I intend to store this data in a local object
which has an additional tag to indicate whether the change came from my exe
or from Outlook (so that I can ensure that the change in the data passes
through my in-proc COM object only once.
Can I ask this in stages?
1) Assuming I have created a new ATL COM project using the AppWizard, to
produce a DLL and Allow merging of proxy/stub code, and that I have added an
ATL object using the wizard (the SimpleObject from the Objects category),
adding support for ISupportErrorInfo, and finally that I have had it add the
_IDTExtensibility2 Interface, what do I do next to get access to the contact
data in Outlook 2000 (remember I am using VC++6). IIRC, there is a contact
list object in the Outlook object model, but how do I get at it?
2) Is there an operator that will compare one instance of the contact class
with another, and is there an assignment operator defined for contact
objects? Or do I have to make my own C++ class and implement these
operators myself? And, if I want to make a contact data manager COM object
which has, as part of its interface, a function to accept an instance of the
contact data class, and this lives in both the out of proc and in proc COM
object servers), that in the out of proc COM object server call that
function on a com object in the in-proc COM object server? How can the out
of proc COM object server find all of the COM objects created by the in-proc
COM object servers? While I know I don't need to derive my contact C++
class from anything (it is, after all, just data), assuming I need to make
it, I am not certain which class to derive the pure abstract base class for
my contact manager class from, especially with the complication of using ATL
(but I'd be just as uncertain if I was using the MFC counterpart).
3) Assuming I have received contact data and an event id (which could be one
of add, remove or delete), how do I tell Outlook to add, remove or edit the
appropriate contact data? I assume there must be a function to add contact
items and another to find and remove one, and yet another to find and change
a contact item, but where are these documented?
4) One final question is this: "How can I get an in-proc COM object to
respond to an out of proc COM object, distributed or otherwise?" What has
to happen is that when my COM object detects an Outlook event to which I
need to respond (WITHOUT altering how Outlook normally handles then in any
way), it needs to send the new contact data to the out of proc com object
which then needs to transfer the data to one or more other COM objects.
And, of course, when it receives data from these other objects, it needs to
tell my in-proc COM object about it so that it can then tell Outlook about
changes made to contact data made by the other COM objects. Imagine a LAN
with three workstations, each running Outlook 2000. The objective is to
have an instance of the in-proc COM object running on each machine, and an
instance of the out of proc COM object running on only one of them, and the
four combined work to keep the Outlook contact data on the two machines in
sync, with any edit made on one machine being immediately visible on the
other. Yes, I know that can be handled by configuring Outlook on the two
machines to share the contact database, but my situation is actually a bit
more complicated with other applications being involved. Is this design
adequate, or do I need something a little more complex? I know that there
is a method of installing a COM object on another machine on a LAN, and
configure a given workstation to work with it using RPC (as opposed to LPC),
so I know I can get my in-proc COM object to call functions in the interface
of the out-of-proc COM object, regardless of whether or not the latter is on
the local machine or some other machine. What I am not certain of is
whether or not the reverse is true?
Once I get past this, I am sure I will have more questions about deployment.
Any assistance would be greatly appreciated.
Thanks,
Ted
developed after VS6 was released. Some are not documented and others
contain errors (according to VC++6). I am extremely frustrated.
The closest I got to getting something working is where I created an ATL COM
project. But I got stuck on how I can gain access to Outlook's contact
data. I am ONLY working with contact data, and my design is simple. I will
be using a mix of DLLs and EXEs (one of which MAY be on some other machine),
but the key to the design if the in-proc COM object. It will talk only to
Outlook 2000 or later, and to a COM object living in the exe that may or may
not be on another machine. It needs to detect Add, Change and Delete events
generated by the user using Outlook, and send the complete contact data to
the COM object in the exe. I intend to store this data in a local object
which has an additional tag to indicate whether the change came from my exe
or from Outlook (so that I can ensure that the change in the data passes
through my in-proc COM object only once.
Can I ask this in stages?
1) Assuming I have created a new ATL COM project using the AppWizard, to
produce a DLL and Allow merging of proxy/stub code, and that I have added an
ATL object using the wizard (the SimpleObject from the Objects category),
adding support for ISupportErrorInfo, and finally that I have had it add the
_IDTExtensibility2 Interface, what do I do next to get access to the contact
data in Outlook 2000 (remember I am using VC++6). IIRC, there is a contact
list object in the Outlook object model, but how do I get at it?
2) Is there an operator that will compare one instance of the contact class
with another, and is there an assignment operator defined for contact
objects? Or do I have to make my own C++ class and implement these
operators myself? And, if I want to make a contact data manager COM object
which has, as part of its interface, a function to accept an instance of the
contact data class, and this lives in both the out of proc and in proc COM
object servers), that in the out of proc COM object server call that
function on a com object in the in-proc COM object server? How can the out
of proc COM object server find all of the COM objects created by the in-proc
COM object servers? While I know I don't need to derive my contact C++
class from anything (it is, after all, just data), assuming I need to make
it, I am not certain which class to derive the pure abstract base class for
my contact manager class from, especially with the complication of using ATL
(but I'd be just as uncertain if I was using the MFC counterpart).
3) Assuming I have received contact data and an event id (which could be one
of add, remove or delete), how do I tell Outlook to add, remove or edit the
appropriate contact data? I assume there must be a function to add contact
items and another to find and remove one, and yet another to find and change
a contact item, but where are these documented?
4) One final question is this: "How can I get an in-proc COM object to
respond to an out of proc COM object, distributed or otherwise?" What has
to happen is that when my COM object detects an Outlook event to which I
need to respond (WITHOUT altering how Outlook normally handles then in any
way), it needs to send the new contact data to the out of proc com object
which then needs to transfer the data to one or more other COM objects.
And, of course, when it receives data from these other objects, it needs to
tell my in-proc COM object about it so that it can then tell Outlook about
changes made to contact data made by the other COM objects. Imagine a LAN
with three workstations, each running Outlook 2000. The objective is to
have an instance of the in-proc COM object running on each machine, and an
instance of the out of proc COM object running on only one of them, and the
four combined work to keep the Outlook contact data on the two machines in
sync, with any edit made on one machine being immediately visible on the
other. Yes, I know that can be handled by configuring Outlook on the two
machines to share the contact database, but my situation is actually a bit
more complicated with other applications being involved. Is this design
adequate, or do I need something a little more complex? I know that there
is a method of installing a COM object on another machine on a LAN, and
configure a given workstation to work with it using RPC (as opposed to LPC),
so I know I can get my in-proc COM object to call functions in the interface
of the out-of-proc COM object, regardless of whether or not the latter is on
the local machine or some other machine. What I am not certain of is
whether or not the reverse is true?
Once I get past this, I am sure I will have more questions about deployment.
Any assistance would be greatly appreciated.
Thanks,
Ted