In an Outlook COM Add-in can I use the MAPIOBJECT property without
calls to MAPIInitialize() or MAPILogin()/MAPILoginEx()?

I've actually got code which is doing this already, and it works, but
it doesn't seem right. It seems like it was too simple of a way to
avoid the security prompts.

I use OLE to get the MAPIOBJECT, then use QueryInterface to get the
IMessage interface, and I don't get any errors when using GetProps()
to access properties like PR_SENDER_NAME... Can this be correct?

Please, please, please, tell me it is fine to do this! Any answers
greatly appreciated. This would solve so many issues for me if this
works.

Thank You!

Yes, you can do that just fine, that is exactly what it was meant to be used
for. The only catch is to call MAPIInitialize before you access it from a
process other than Outlook - since your code in a COM addin and it runs in
the same address space as outlook.exe, Outlook does that for you.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool


"Eric" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In an Outlook COM Add-in can I use the MAPIOBJECT property without
> calls to MAPIInitialize() or MAPILogin()/MAPILoginEx()?
>
> I've actually got code which is doing this already, and it works, but
> it doesn't seem right. It seems like it was too simple of a way to
> avoid the security prompts.
>
> I use OLE to get the MAPIOBJECT, then use QueryInterface to get the
> IMessage interface, and I don't get any errors when using GetProps()
> to access properties like PR_SENDER_NAME... Can this be correct?
>
> Please, please, please, tell me it is fine to do this! Any answers
> greatly appreciated. This would solve so many issues for me if this
> works.
>
> Thank You!

Thanks for the info, that is great news! Do you happen to know if
there is anyway to do the equivalent of a MAPIFreeBuffer() call via
any OLE methods or any other method which doesn't require me to load
MAPI32.DLL or other MAPI dlls? I see that the OLE "Session" property
has a few functions it exposes, but no MAPIFreeBuffer.

p.s.-Your posts have been a great help to me (from searching the
newsgroups, and your Outlook Spy program is awsome (I paid for it a
couple years back), thanks again!

"Dmitry Streblechenko" <(E-Mail Removed)> wrote in message news:<#(E-Mail Removed)>...
> Yes, you can do that just fine, that is exactly what it was meant to be used
> for. The only catch is to call MAPIInitialize before you access it from a
> process other than Outlook - since your code in a COM addin and it runs in
> the same address space as outlook.exe, Outlook does that for you.
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool

No, MAPIFreeBuffer is MAPIFreeBuffer, why do you want to have it exposed
though OOM? What's wrong with loading mapi32.dll (dynamically or
statically)?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool


"Eric" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks for the info, that is great news! Do you happen to know if
> there is anyway to do the equivalent of a MAPIFreeBuffer() call via
> any OLE methods or any other method which doesn't require me to load
> MAPI32.DLL or other MAPI dlls? I see that the OLE "Session" property
> has a few functions it exposes, but no MAPIFreeBuffer.
>
> p.s.-Your posts have been a great help to me (from searching the
> newsgroups, and your Outlook Spy program is awsome (I paid for it a
> couple years back), thanks again!
>
> "Dmitry Streblechenko" <(E-Mail Removed)> wrote in message
news:<#(E-Mail Removed)>...
> > Yes, you can do that just fine, that is exactly what it was meant to be
used
> > for. The only catch is to call MAPIInitialize before you access it from
a
> > process other than Outlook - since your code in a COM addin and it runs
in
> > the same address space as outlook.exe, Outlook does that for you.
> >
> > Dmitry Streblechenko (MVP)
> > http://www.dimastr.com/
> > OutlookSpy - Outlook, CDO
> > and MAPI Developer Tool

I've seen a lot of systems where the combinations of mapi32.dll,
mapi32x.dll, and mapistub.dll are not the correct DLLs.

I think I've figured out a pretty sure fire method to make sure that
as long as Outlook can run, my calls to MAPIFreeBuffer should also
work. So if this works, I'm not so worried. Here is what I'm doing
in my COM add-in now, in my "OnConnect" event:

h = GetModuleHandle("msmapi32.dll");
GetModuleFileName(h,filename,...);
l = LoadLibrary(filename);
pMAPIFreeBuffer = GetProcAddress(l,"MAPIFreeBuffer");

I've removed a lot of code, but I think the above code is pretty clear
as to what I'm doing. I added the call to LoadLibrary(), instead of
using handle from GetModuleHandle(), to make sure the handle stays
valid until I call FreeLibrary().

It seems like this will ensure that I use the same copy of DLL that
Outlook is using, so my COM add-in should have the least chance of
having DLL issues. As long as the function name doesn't change, or
get an "@4" or something added to it in the future.

Thanks again. I got most of the ideas for the above method from
reading other messages posted by you, except I decided this route
should work better than the FGetModulePath route on MSDN, and it
should work because with the COM add-in I know Outlook is loaded.


"Dmitry Streblechenko" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> No, MAPIFreeBuffer is MAPIFreeBuffer, why do you want to have it exposed
> though OOM? What's wrong with loading mapi32.dll (dynamically or
> statically)?
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool

I never had any problems with using LoadLibrary("mapi32.dll") - by the time
your add-in is initialized, mapi32.dll is already loaded by Outlook.
You can get fancy if your code runs in an address space other than
outlook.exe, but in case of a COM add-in you are always safe.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool


"Eric" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I've seen a lot of systems where the combinations of mapi32.dll,
> mapi32x.dll, and mapistub.dll are not the correct DLLs.
>
> I think I've figured out a pretty sure fire method to make sure that
> as long as Outlook can run, my calls to MAPIFreeBuffer should also
> work. So if this works, I'm not so worried. Here is what I'm doing
> in my COM add-in now, in my "OnConnect" event:
>
> h = GetModuleHandle("msmapi32.dll");
> GetModuleFileName(h,filename,...);
> l = LoadLibrary(filename);
> pMAPIFreeBuffer = GetProcAddress(l,"MAPIFreeBuffer");
>
> I've removed a lot of code, but I think the above code is pretty clear
> as to what I'm doing. I added the call to LoadLibrary(), instead of
> using handle from GetModuleHandle(), to make sure the handle stays
> valid until I call FreeLibrary().
>
> It seems like this will ensure that I use the same copy of DLL that
> Outlook is using, so my COM add-in should have the least chance of
> having DLL issues. As long as the function name doesn't change, or
> get an "@4" or something added to it in the future.
>
> Thanks again. I got most of the ideas for the above method from
> reading other messages posted by you, except I decided this route
> should work better than the FGetModulePath route on MSDN, and it
> should work because with the COM add-in I know Outlook is loaded.
>
>
> "Dmitry Streblechenko" <(E-Mail Removed)> wrote in message
news:<(E-Mail Removed)>...
> > No, MAPIFreeBuffer is MAPIFreeBuffer, why do you want to have it exposed
> > though OOM? What's wrong with loading mapi32.dll (dynamically or
> > statically)?
> >
> > Dmitry Streblechenko (MVP)
> > http://www.dimastr.com/
> > OutlookSpy - Outlook, CDO
> > and MAPI Developer Tool