Merci Julien.

> > Currently I am running test cases through a client program that I 
> > built out of exchange2mbox and the 0.8 release of exchange2ical. 
> > Right now I have two strange cases for which I would need some 
> > advice.
> 
> Further version of exchange2ical will rely on libical. However I don't
> think this will change the MAPI semantics involved in the tool.

saw that already, but I haven't followed the changes you already made
 
> > The first one was created accidentally. I sent a message with attachments
> > from OWA and then I moved the message from Sent Items to the Inbox.
> > In OWA it looks like a regular mail with names and addresses on the
> > To and CC lines. However, when I use my mapi client to download this
> > message, I don't get any PR_TRANSPORT_MESSAGE_HEADERS. That's not 
> > surprising since this message hasn't really been sent, it's a 
> > local copy.
> > But how can I get the To and CC (and BCC) information? I tried all sorts
> > of tags that have EMAIL, TO or CC in it, but they all come up 
> > empty. Since I can see this info in OWA, it must be somewhere. 
> > (Normally I rely only on the transport headers to get all the to 
> > & from info.)
> 
> These fields should normally be available in OpenMessage reply and you
> should be able to retrieve them using GetRecipientTable +
> GetABRecipientInfo if you're looking for additional information for
> Exchange organization users.

Ok, thanks, will look into this tomorrow. Already past midnight here.


> > The second case is an invitation that I sent from Thunderbird. In OWA
> > it shows up as an email with the calendar icon. It has a text line in
> > the body that was apparently generated by TB. It also has an attachment
> > called invite.ics. Now let's look at a code snippet:
> > http://www.pastebin.ca/1351665
> > The debug print statements in lines 33-38 all print some reasonable
> > information. But the OpenMessage on line 41 fails with 
> > MAP_E_INVALID_PARAMETER.
> > (exchange2ical also calls OpenMessage for each item is processes.)
> 
> OpenMessage returns MAPI_E_INVALID_PARAMETER if obj_store is invalid or

I think we can exclude that because then the contents table shouldn't
have worked either. Isn't obj_store the root, i.e. if that is invalid,
nothing will work?

> if it was unable to retrieve the session pointer from opaque obj_store.
> I don't think Exchange (but I may be wrong) actually returns
> MAPI_E_INVALID_PARAMETER on its own as a valid mapi_response retval for
> this call. Maybe enabling debug would show you whether the call is
> actually being packed and relay to Exchange or not.

not knowing what debug_level means, I set it to 5. 
Then I got a message "ndr_pull_error(2): Bad switch value 0"
Then I numbered all these ndr_pull_error and found that this one
came from ndr_pull_EcDoRpc_MAPI_REPL_UNION

> > But then I am also wondering what I can do with the table I got 
> > from QueryRows (line 29), what is the set of tags that could get 
> > at this stage, and for what operations do I need to call 
> > OpenMessage?
> 
> You don't need any other tags but PR_FID and PR_MID to call OpenMessage.
> With QueryRows you will - in the code you pasted - be able to retrieve
> any properties specified with SetColumns and available on a contents
> table.

Understood that for OpenMessage I need only FID and MID. However, after
QueryRows (and before OpenMessage) it seems that I have access to more
tags than those listed in
http://msdn.microsoft.com/en-us/library/cc842083.aspx
Is there some sort of "select * from tableX" where you get to see
all the fields that are actually available?
Anyway, just curious, if we can figure out this ndr_pull_error,
then hopefully we can get OpenMessage to work on this message
and then there's no need to fiddle around

> > Can I get the full body and the attachments after QueryRows or 
> > does that require a message object from OpenMessage?
> 
> You need to OpenMessage and GetProps on obj_message object.
> 


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel

Reply via email to