Re: Message stays in outbox
- From: "Iv. Kozhuharov" <imi@xxxxxxxxx>
- Date: Wed, 4 Jun 2008 09:39:50 +0300
Ashutosh,
Can you do some modification inside your code?
First of all, when you call MAPIInitialize, try to pass flag
MAPI_NO_COINIT - you already have COM initialization. MAPI, by default, will
try to initialize COM with a call to CoInitialize.
This initializes COM with a single threaded apartment model. If you like to
run it inside multithreaded model, call CoInitializeEx with the
COINIT_MULTITHREADED flag, and add MAPI_MULTITHREADED_NOTIFICATIONS also.
If a MAPIINIT_0 structure is passed into MAPIInitialize
with ulFlags set to MAPI_NO_COINIT, MAPI will assume that COM has already
been initialized
and bypass the call to CoInitialize.:
hRes = CoInitialize(0);
.....
hRes = MAPIInitialize(NULL);
pseudo code
MAPI_NO_COINIT = $00000008;
MAPIINIT.ulVersion := MAPI_INIT_VERSION;
MAPIINIT.ulFlags := MAPI_NO_COINIT (* or MAPI_NT_SERVICE or
MAPI_MULTITHREADED_NOTIFICATIONS *) ;
hr := MapiInitialize( @MAPIINIT);
Second:
Remove (for tests only) flag AB_NO_DIALOG from
hRes = lpSession->OpenAddressBook
then check hRes value from
hRes = pAddrBook->ResolveName(0, 0, 0, pAddressList);
Regards,
Iv
"Ashutosh Bhawasinka" <smbs-msdn@xxxxxxxxxxxxx> wrote in message
news:uH9Si7exIHA.2188@xxxxxxxxxxxxxxxxxxxxxxx
| Hi Stephen,
| Thanks for your reply. What you mentioned was the first place I suspected.
| I had already tried what you just mentioned. Moreover, the project I am
| using has UNICODE defined and there is no way its going to run on non NT
| systems.
|
| To add to it, since UNICODE is always defined, PR_DISPLAY_NAME or
| PR_DISPLAY_NAME_W, both have the same value. Also, LPSZ is defined as
| lpszW (when unicode).
|
| Secondly, weather UNICODE is used or not both lpszA or lpszW will have
| the same effect because they are in a union and are pointer.
|
| So to summarize, even after this I am getting the same error. :(
|
| However, I checked the error codes at
| http://www.mapi33.adexsolutions.com/docs/MAPI33.Error.html
| which says that the error as/is
| BadCharWidth 0x80040103
|
| Any clue?? Can you please try to run this code?
|
| Regards,
| Ashutosh
|
| Stephen Griffin [MSFT] wrote:
| > This code:
| > WCHAR toAdd[]=L"test@xxxxxxxxxxxxxx";
| > SPropValue toProps[2];
| >
| > toProps[0].ulPropTag = PR_DISPLAY_NAME;
| > toProps[0].Value.LPSZ = toAdd;
| >
| > is broken if UNICODE isn't defined. You're using macros (PR_DISPLAY_NAME
and
| > LPSZ) that mean one thing when UNICODE isn't defined and another when it
is.
| > Without UNICODE, your code is equivalent to:
| >
| > WCHAR toAdd[]=L"test@xxxxxxxxxxxxxx";
| > SPropValue toProps[2];
| >
| > toProps[0].ulPropTag = PR_DISPLAY_NAME_A;
| > toProps[0].Value.lpszA = toAdd;
| >
| > Which is garbage code, since you're declaring that you have an ANSI
string,
| > yet you pass a unicode buffer.
| >
| > Given that you're hard coding the buffer as Unicode, you should also
| > hardcode the rest as unicode. The code should look like this:
| > WCHAR toAdd[]=L"test@xxxxxxxxxxxxxx";
| > SPropValue toProps[2];
| >
| > toProps[0].ulPropTag = PR_DISPLAY_NAME_W;
| > toProps[0].Value.lpszW = toAdd;
| >
| > You make this same error many places in the code.
| >
| > "Ashutosh Bhawasinka" <smbs-msdn@xxxxxxxxxxxxx> wrote in message
| > news:uTCxlwXxIHA.4564@xxxxxxxxxxxxxxxxxxxxxxx
| >> There is however one difference when the same code used to run over a
year
| >> back (it was just a test code). Earlier I used only ANSI strings and
now I
| >> am using Unicode strings.
| >>
| >> Stephen Griffin [MSFT] wrote:
| >>> Ok - forget about submitting the message - that's not going to work
until
| >>> you fix the issue with ResolveName. Until ResolveName is working, the
| >>> message isn't addressed, and there's no chance it could be sent.
| >>>
| >>> So - what are you passing into ResolveName? What is pAddressList? Can
you
| >>> show the code that builds it?
| >>>
| >>> Steve
| >>>
| >>> "Ashutosh Bhawasinka" <smbs-msdn@xxxxxxxxxxxxx> wrote in message
| >>> news:ewFyufUxIHA.3336@xxxxxxxxxxxxxxxxxxxxxxx
| >>>> Hi,
| >>>> I checked
| >>>> 1) with a profile having only a exchange account (NOT in cached mode)
| >>>> - The message is NOT italicized in the outbox.
| >>>> - When submitting message the return code was E_FAIL
| >>>> 2) with a profile having Just a POP account(s)/pst
| >>>> - The message is italicized
| >>>> - Submit message succeeds but it remains in outbox
| >>>>
| >>>> hRes = pAddrBook->ResolveName(0, 0, 0, pAddressList);
| >>>> always fails
| >>>>
| >>>> I even changed
| >>>> hRes = pMsg->SaveChanges(KEEP_OPEN_READWRITE)
| >>>> pMsg->SubmitMessage(FORCE_SUBMIT )
| >>>>
| >>>> to
| >>>> hRes = pMsg->SaveChanges(0)
| >>>> pMsg->SubmitMessage(0 )
| >>>>
| >>>> Even then the same result.
| >>>>
| >>>> Regards,
| >>>> Ashutosh
| >>>>
| >>>>
| >>>> Dmitry Streblechenko wrote:
| >>>>> Does it work if you switch profile to using the online mode (uncheck
| >>>>> the "use cached mode" checkbox)?
| >>>>>
| >>>
| >>
| >> --
| >> Ashutosh Bhawasinka
| >> email:expert@xxxxxxxxxxx
| >
| >
.
- Follow-Ups:
- Re: Message stays in outbox
- From: Ashutosh Bhawasinka
- Re: Message stays in outbox
- References:
- Message stays in outbox
- From: Ashutosh Bhawasinka
- Re: Message stays in outbox
- From: Dmitry Streblechenko
- Re: Message stays in outbox
- From: Ashutosh Bhawasinka
- Re: Message stays in outbox
- From: Dmitry Streblechenko
- Re: Message stays in outbox
- From: Ashutosh Bhawasinka
- Re: Message stays in outbox
- From: Stephen Griffin [MSFT]
- Re: Message stays in outbox
- From: Ashutosh Bhawasinka
- Re: Message stays in outbox
- From: Stephen Griffin [MSFT]
- Re: Message stays in outbox
- From: Ashutosh Bhawasinka
- Message stays in outbox
- Prev by Date: Re: Message stays in outbox
- Next by Date: Re: Message stays in outbox
- Previous by thread: Re: Message stays in outbox
- Next by thread: Re: Message stays in outbox
- Index(es):
Relevant Pages
|
