Can I use MAPIOBJECT without MAPILogin?

[Eric]

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!

 

[Dmitry Streblechenko]

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]

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]

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]

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]

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