|
|
|
date: Wed, 16 Apr 2008 12:19:23 +0200,
group: microsoft.public.platformsdk.mapi
back
Need a MAPI guru with magical powers
Hi,
I am developping on pocket pc with MAPI to create/read sms and I am
experimenting a very weird behavior.
Here is a part of the method I use to list sms :
ULONG ulNbIds = 0;
LPMAPITABLE pContentsTable = NULL;
LPSRowSet pRows = NULL;
char pId[1024];
TCHAR tszPid[1024];
HRESULT hr;
LPMESSAGE pMessage = NULL;
LONGLONG llTemp;
ULONG ulBufLen = 0;
enum { ePR_ENTRYID, ePR_LAST_MODIFICATION_TIME, ePR_MESSAGE_CLASS,
NUM_COLS };
static const SizedSPropTagArray(NUM_COLS, Columns) = { NUM_COLS,
PR_ENTRYID, PR_LAST_MODIFICATION_TIME, PR_MESSAGE_CLASS };
static const SizedSSortOrderSet(1, sortOrderSet) = { 1, 0, 0, {
PR_MESSAGE_DELIVERY_TIME, TABLE_SORT_DESCEND } };
....
hr = pContentsTable->GetRowCount( 0, &ulNbIds );
EXIT_ON_FAILED( hr );
vlwTrace("CCoMessagesDb::ListIds() : Found %d items in 0x%x
FolderType\n", ulNbIds, m_eFolderType);
if( ulNbIds > 0 )
{
//m_mapIds = new coMapIds_t [ ulNbIds ]; <<<<< ?????
m_mapIds = (coMapIds_t*) malloc(ulNbIds); <<<< ????
vlwTrace("CCoMessagesDb::ListIds() : Creating map array
m_mapIds(0x%x)\n", m_mapIds);
while( !FAILED( pContentsTable->QueryRows( 1, 0, &pRows ) ) )
{
if( pRows->cRows == 0 ) { FreeProws( pRows ); break; }
//Is the message a SMS?
//Get the message : pMessage
hr = m_pSession->OpenEntry(
pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.cb,
( LPENTRYID )
pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.lpb,
NULL,
0,
NULL,
( LPUNKNOWN* ) &pMessage );
if( hr == S_OK )
{
if( hr == S_OK )
{
coMapIds_t mapData;
//char fsdfs[2048];
//This is a SMS, we add it in the ListIds
//Retrieve the ID of the message
llTemp =
pRows->aRow[0].lpProps[ePR_ENTRYID].Value.li.QuadPart;
LONG t1 = (LONG)(llTemp % (LONGLONG)1000000000);
LONG t2 = (LONG)((llTemp /
(LONGLONG)1000000000) % (LONGLONG)1000000000);
LONG t3 = (LONG)((llTemp /
(LONGLONG)1000000000) / (LONGLONG)1000000000);
sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
...
ATLTRACE( _T("INSERT Id = %s in m_mapIds[%d]\n"), tszPid, i );
}
}
}
...
In this code I am allocating an array of struct to map an pID with its
associated PR_ENTRYID value and in function of the allocation method ,
id is different!!!!!!!!!.
For instance with a malloc I get this :
INSERT Id = 0005967599359754260 in m_mapIds[0]
INSERT Id = 0005971653808881684 in m_mapIds[1]
INSERT Id = 0005974333868474388 in m_mapIds[2]
While with a new allocation :
INSERT Id = 0005967668079230996 in m_mapIds[0]
INSERT Id = 0005971722528358420 in m_mapIds[1]
INSERT Id = 0005974196429520916 in m_mapIds[2]
What is REALLY WEIRD is the fact that this allocation HAS NORMALLY
NOTHING TO DO with PR_ENTRYID. As you can see this m_mapIds is used
after OpenEntry and the latter does not depend on it .....
How can the allocation of a simple variable change the id value ?
date: Wed, 16 Apr 2008 12:19:23 +0200
author: mosfet
Re: Need a MAPI guru with magical powers
I'm not seeing in that code where you copy any data from pRows over to
m_mapIds.
"mosfet" wrote in message
news:4805d2ab$0$745$426a74cc@news.free.fr...
> Hi,
>
> I am developping on pocket pc with MAPI to create/read sms and I am
> experimenting a very weird behavior.
>
>
> Here is a part of the method I use to list sms :
>
> ULONG ulNbIds = 0;
> LPMAPITABLE pContentsTable = NULL;
> LPSRowSet pRows = NULL;
> char pId[1024];
> TCHAR tszPid[1024];
> HRESULT hr;
> LPMESSAGE pMessage = NULL;
> LONGLONG llTemp;
> ULONG ulBufLen = 0;
>
> enum { ePR_ENTRYID, ePR_LAST_MODIFICATION_TIME, ePR_MESSAGE_CLASS,
> NUM_COLS };
> static const SizedSPropTagArray(NUM_COLS, Columns) = { NUM_COLS,
> PR_ENTRYID, PR_LAST_MODIFICATION_TIME, PR_MESSAGE_CLASS };
> static const SizedSSortOrderSet(1, sortOrderSet) = { 1, 0, 0, {
> PR_MESSAGE_DELIVERY_TIME, TABLE_SORT_DESCEND } };
>
>
> ....
> hr = pContentsTable->GetRowCount( 0, &ulNbIds );
> EXIT_ON_FAILED( hr );
>
> vlwTrace("CCoMessagesDb::ListIds() : Found %d items in 0x%x
> FolderType\n", ulNbIds, m_eFolderType);
> if( ulNbIds > 0 )
> {
> //m_mapIds = new coMapIds_t [ ulNbIds ]; <<<<< ?????
>
> m_mapIds = (coMapIds_t*) malloc(ulNbIds); <<<< ????
>
> vlwTrace("CCoMessagesDb::ListIds() : Creating map array m_mapIds(0x%x)\n",
> m_mapIds);
>
> while( !FAILED( pContentsTable->QueryRows( 1, 0, &pRows ) ) )
> {
> if( pRows->cRows == 0 ) { FreeProws( pRows ); break; }
>
> //Is the message a SMS?
> //Get the message : pMessage
> hr = m_pSession->OpenEntry(
> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.cb,
> ( LPENTRYID )
> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.lpb,
> NULL,
> 0,
> NULL,
> ( LPUNKNOWN* ) &pMessage );
> if( hr == S_OK )
> {
> if( hr == S_OK )
> {
> coMapIds_t mapData;
> //char fsdfs[2048];
>
> //This is a SMS, we add it in the ListIds
> //Retrieve the ID of the message
> llTemp =
> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.li.QuadPart;
> LONG t1 = (LONG)(llTemp % (LONGLONG)1000000000);
> LONG t2 = (LONG)((llTemp / (LONGLONG)1000000000) %
> (LONGLONG)1000000000);
> LONG t3 = (LONG)((llTemp / (LONGLONG)1000000000) /
> (LONGLONG)1000000000);
> sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
> ...
>
> ATLTRACE( _T("INSERT Id = %s in m_mapIds[%d]\n"), tszPid, i );
> }
> }
> }
> ...
>
> In this code I am allocating an array of struct to map an pID with its
> associated PR_ENTRYID value and in function of the allocation method ,
> id is different!!!!!!!!!.
>
> For instance with a malloc I get this :
> INSERT Id = 0005967599359754260 in m_mapIds[0]
> INSERT Id = 0005971653808881684 in m_mapIds[1]
> INSERT Id = 0005974333868474388 in m_mapIds[2]
>
> While with a new allocation :
> INSERT Id = 0005967668079230996 in m_mapIds[0]
> INSERT Id = 0005971722528358420 in m_mapIds[1]
> INSERT Id = 0005974196429520916 in m_mapIds[2]
>
> What is REALLY WEIRD is the fact that this allocation HAS NORMALLY NOTHING
> TO DO with PR_ENTRYID. As you can see this m_mapIds is used after
> OpenEntry and the latter does not depend on it .....
>
> How can the allocation of a simple variable change the id value ?
>
>
>
>
>
>
date: Wed, 16 Apr 2008 10:23:15 -0400
author: Stephen Griffin [MSFT]
Re: Need a MAPI guru with magical powers
That's what I say I am not even copying something into m_mapids and
since id are different ....
I am just doing an allocation but after I don nothing with this array
and as I have explained it seems to change the value.
Stephen Griffin [MSFT] a écrit :
> I'm not seeing in that code where you copy any data from pRows over to
> m_mapIds.
>
> "mosfet" wrote in message
> news:4805d2ab$0$745$426a74cc@news.free.fr...
>> Hi,
>>
>> I am developping on pocket pc with MAPI to create/read sms and I am
>> experimenting a very weird behavior.
>>
>>
>> Here is a part of the method I use to list sms :
>>
>> ULONG ulNbIds = 0;
>> LPMAPITABLE pContentsTable = NULL;
>> LPSRowSet pRows = NULL;
>> char pId[1024];
>> TCHAR tszPid[1024];
>> HRESULT hr;
>> LPMESSAGE pMessage = NULL;
>> LONGLONG llTemp;
>> ULONG ulBufLen = 0;
>>
>> enum { ePR_ENTRYID, ePR_LAST_MODIFICATION_TIME, ePR_MESSAGE_CLASS,
>> NUM_COLS };
>> static const SizedSPropTagArray(NUM_COLS, Columns) = { NUM_COLS,
>> PR_ENTRYID, PR_LAST_MODIFICATION_TIME, PR_MESSAGE_CLASS };
>> static const SizedSSortOrderSet(1, sortOrderSet) = { 1, 0, 0, {
>> PR_MESSAGE_DELIVERY_TIME, TABLE_SORT_DESCEND } };
>>
>>
>> ....
>> hr = pContentsTable->GetRowCount( 0, &ulNbIds );
>> EXIT_ON_FAILED( hr );
>>
>> vlwTrace("CCoMessagesDb::ListIds() : Found %d items in 0x%x
>> FolderType\n", ulNbIds, m_eFolderType);
>> if( ulNbIds > 0 )
>> {
>> //m_mapIds = new coMapIds_t [ ulNbIds ]; <<<<< ?????
>>
>> m_mapIds = (coMapIds_t*) malloc(ulNbIds); <<<< ????
>>
>> vlwTrace("CCoMessagesDb::ListIds() : Creating map array m_mapIds(0x%x)\n",
>> m_mapIds);
>>
>> while( !FAILED( pContentsTable->QueryRows( 1, 0, &pRows ) ) )
>> {
>> if( pRows->cRows == 0 ) { FreeProws( pRows ); break; }
>>
>> //Is the message a SMS?
>> //Get the message : pMessage
>> hr = m_pSession->OpenEntry(
>> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.cb,
>> ( LPENTRYID )
>> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.lpb,
>> NULL,
>> 0,
>> NULL,
>> ( LPUNKNOWN* ) &pMessage );
>> if( hr == S_OK )
>> {
>> if( hr == S_OK )
>> {
>> coMapIds_t mapData;
>> //char fsdfs[2048];
>>
>> //This is a SMS, we add it in the ListIds
>> //Retrieve the ID of the message
>> llTemp =
>> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.li.QuadPart;
>> LONG t1 = (LONG)(llTemp % (LONGLONG)1000000000);
>> LONG t2 = (LONG)((llTemp / (LONGLONG)1000000000) %
>> (LONGLONG)1000000000);
>> LONG t3 = (LONG)((llTemp / (LONGLONG)1000000000) /
>> (LONGLONG)1000000000);
>> sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
>> ...
>>
>> ATLTRACE( _T("INSERT Id = %s in m_mapIds[%d]\n"), tszPid, i );
>> }
>> }
>> }
>> ...
>>
>> In this code I am allocating an array of struct to map an pID with its
>> associated PR_ENTRYID value and in function of the allocation method ,
>> id is different!!!!!!!!!.
>>
>> For instance with a malloc I get this :
>> INSERT Id = 0005967599359754260 in m_mapIds[0]
>> INSERT Id = 0005971653808881684 in m_mapIds[1]
>> INSERT Id = 0005974333868474388 in m_mapIds[2]
>>
>> While with a new allocation :
>> INSERT Id = 0005967668079230996 in m_mapIds[0]
>> INSERT Id = 0005971722528358420 in m_mapIds[1]
>> INSERT Id = 0005974196429520916 in m_mapIds[2]
>>
>> What is REALLY WEIRD is the fact that this allocation HAS NORMALLY NOTHING
>> TO DO with PR_ENTRYID. As you can see this m_mapIds is used after
>> OpenEntry and the latter does not depend on it .....
>>
>> How can the allocation of a simple variable change the id value ?
>>
>>
>>
>>
>>
>>
>
>
date: Wed, 16 Apr 2008 17:02:14 +0200
author: mosfet
Re: Need a MAPI guru with magical powers
I never read nor write.
Let me explain simply look very carefully at the code below :
//char * foo = new char [64];
char * foo = new char [128]; // Doing an allocation just for fun
hr = m_pSession->OpenEntry(
pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.cb,
( LPENTRYID ) pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.lpb,
NULL,
0,
NULL,
( LPUNKNOWN* ) &pMessage );
if( hr == S_OK
{
llTemp = pRows->aRow[0].lpProps[ePR_ENTRYID].Value.li.QuadPart;
LONG t1 = (LONG)(llTemp % (LONGLONG)1000000000);
LONG t2 = (LONG)((llTemp / (LONGLONG)1000000000) %
(LONGLONG)1000000000);
LONG t3 = (LONG)((llTemp / (LONGLONG)1000000000) /
(LONGLONG)1000000000);
sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
}
forget m_mapids. Let's take another example.
If I declare for instance a variable foo like this :
char* foo = new char[64]
I get a PR_ENTRYID of 0006813398679420948 for my first SMS
if I replace by this :
char* foo = new char[128]
I get a PR_ENTRYID of 0006813673557327892 for my first SMS
and I repeat I am only allocating a buffer without any purpose except to
do an allocation.
The fact that OpenEntry is differents means :
A) I get a stack corruption that's why I have a different value for
PR_ENTRYID
B) OpenEntry uses stack context to generate its PR_ENTRYID
C) I DON'T KNOW and I am waiting for you advice.
Dan Mitchell a écrit :
> mosfet wrote in
> news:480614f6$0$8101$426a74cc@news.free.fr:
>> That's what I say I am not even copying something into m_mapids and
>> since id are different ....
>> I am just doing an allocation but after I don nothing with this array
>> and as I have explained it seems to change the value.
>
> I think what Stephen's trying to get at is that in the code you posted,
> you only allocate m_mapiIDs, you don't write anything to that array.
>
> So, of course, when you read from it, it'll contain random data, because
> it will contain whatever happened to be in those bytes when malloc() used
> them.
>
> -- dan
date: Wed, 16 Apr 2008 18:00:05 +0200
author: mosfet
Re: Need a MAPI guru with magical powers
In the code/output you originally posted, your output looked like this:
INSERT Id = 0005967599359754260 in m_mapIds[0]
Looking at your code, this was printed by this statement:
ATLTRACE( _T("INSERT Id = %s in m_mapIds[%d]\n"), tszPid, i );
Which prints the contents of tszPid. I'm not seeing where you're writing
anything to tszPID either. Maybe I can assume that this sprintf:
sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
which wrote to pId, also, through the magic of omitted code, wrote to
tszPid. But still, that leaves us with a few problems:
1 - You're using the li.QuadPart member to access an entry ID property.
PR_ENTRYID is PT_BINARY, so only the .bin member is valid
2 - Assuming li.QuadPart happened to point to the same place in memory as
bin, you're trying to read the data there as if it was some large decimal
number. Which it's not. It doesn't make a lick of sense to look at it as
such. You should be looking at bin.cb to see how many bytes to print, then
print out that many bytes are the location pointed to by bin.lpb
"mosfet" wrote in message
news:48062285$0$25564$426a74cc@news.free.fr...
>I never read nor write.
>
>
> Let me explain simply look very carefully at the code below :
>
>
> //char * foo = new char [64];
> char * foo = new char [128]; // Doing an allocation just for fun
>
> hr = m_pSession->OpenEntry(
> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.cb,
> ( LPENTRYID ) pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.lpb,
> NULL,
> 0,
> NULL,
> ( LPUNKNOWN* ) &pMessage );
>
> if( hr == S_OK
> {
> llTemp = pRows->aRow[0].lpProps[ePR_ENTRYID].Value.li.QuadPart;
> LONG t1 = (LONG)(llTemp % (LONGLONG)1000000000);
> LONG t2 = (LONG)((llTemp / (LONGLONG)1000000000) % (LONGLONG)1000000000);
> LONG t3 = (LONG)((llTemp / (LONGLONG)1000000000) / (LONGLONG)1000000000);
> sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
> }
>
> forget m_mapids. Let's take another example.
> If I declare for instance a variable foo like this :
>
> char* foo = new char[64]
> I get a PR_ENTRYID of 0006813398679420948 for my first SMS
>
> if I replace by this :
> char* foo = new char[128]
> I get a PR_ENTRYID of 0006813673557327892 for my first SMS
>
>
> and I repeat I am only allocating a buffer without any purpose except to
> do an allocation.
> The fact that OpenEntry is differents means :
>
> A) I get a stack corruption that's why I have a different value for
> PR_ENTRYID
> B) OpenEntry uses stack context to generate its PR_ENTRYID
> C) I DON'T KNOW and I am waiting for you advice.
>
>
>
>
>
>
>
>
>
>
>
>
> Dan Mitchell a écrit :
>> mosfet wrote in
>> news:480614f6$0$8101$426a74cc@news.free.fr:
>>> That's what I say I am not even copying something into m_mapids and
>>> since id are different ....
>>> I am just doing an allocation but after I don nothing with this array
>>> and as I have explained it seems to change the value.
>>
>> I think what Stephen's trying to get at is that in the code you posted,
>> you only allocate m_mapiIDs, you don't write anything to that array.
>>
>> So, of course, when you read from it, it'll contain random data, because
>> it will contain whatever happened to be in those bytes when malloc() used
>> them.
>>
>> -- dan
date: Wed, 16 Apr 2008 12:25:03 -0400
author: Stephen Griffin [MSFT]
Re: Need a MAPI guru with magical powers
Your are the best!
Your answer makes sense.
I will invsestigate...
Just for information here is the missing code :
sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
wsprintf( tszPid, _T("%u%09lu%09lu"), t3, t2, t1 );
tszPid is the same string as pId but encoded in UNICODE.
Stephen Griffin [MSFT] a écrit :
> In the code/output you originally posted, your output looked like this:
> INSERT Id = 0005967599359754260 in m_mapIds[0]
>
> Looking at your code, this was printed by this statement:
> ATLTRACE( _T("INSERT Id = %s in m_mapIds[%d]\n"), tszPid, i );
>
> Which prints the contents of tszPid. I'm not seeing where you're writing
> anything to tszPID either. Maybe I can assume that this sprintf:
> sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
> which wrote to pId, also, through the magic of omitted code, wrote to
> tszPid. But still, that leaves us with a few problems:
> 1 - You're using the li.QuadPart member to access an entry ID property.
> PR_ENTRYID is PT_BINARY, so only the .bin member is valid
> 2 - Assuming li.QuadPart happened to point to the same place in memory as
> bin, you're trying to read the data there as if it was some large decimal
> number. Which it's not. It doesn't make a lick of sense to look at it as
> such. You should be looking at bin.cb to see how many bytes to print, then
> print out that many bytes are the location pointed to by bin.lpb
>
> "mosfet" wrote in message
> news:48062285$0$25564$426a74cc@news.free.fr...
>> I never read nor write.
>>
>>
>> Let me explain simply look very carefully at the code below :
>>
>>
>> //char * foo = new char [64];
>> char * foo = new char [128]; // Doing an allocation just for fun
>>
>> hr = m_pSession->OpenEntry(
>> pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.cb,
>> ( LPENTRYID ) pRows->aRow[0].lpProps[ePR_ENTRYID].Value.bin.lpb,
>> NULL,
>> 0,
>> NULL,
>> ( LPUNKNOWN* ) &pMessage );
>>
>> if( hr == S_OK
>> {
>> llTemp = pRows->aRow[0].lpProps[ePR_ENTRYID].Value.li.QuadPart;
>> LONG t1 = (LONG)(llTemp % (LONGLONG)1000000000);
>> LONG t2 = (LONG)((llTemp / (LONGLONG)1000000000) % (LONGLONG)1000000000);
>> LONG t3 = (LONG)((llTemp / (LONGLONG)1000000000) / (LONGLONG)1000000000);
>> sprintf( pId, "%u%09lu%09lu", t3, t2, t1 );
>> }
>>
>> forget m_mapids. Let's take another example.
>> If I declare for instance a variable foo like this :
>>
>> char* foo = new char[64]
>> I get a PR_ENTRYID of 0006813398679420948 for my first SMS
>>
>> if I replace by this :
>> char* foo = new char[128]
>> I get a PR_ENTRYID of 0006813673557327892 for my first SMS
>>
>>
>> and I repeat I am only allocating a buffer without any purpose except to
>> do an allocation.
>> The fact that OpenEntry is differents means :
>>
>> A) I get a stack corruption that's why I have a different value for
>> PR_ENTRYID
>> B) OpenEntry uses stack context to generate its PR_ENTRYID
>> C) I DON'T KNOW and I am waiting for you advice.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Dan Mitchell a écrit :
>>> mosfet wrote in
>>> news:480614f6$0$8101$426a74cc@news.free.fr:
>>>> That's what I say I am not even copying something into m_mapids and
>>>> since id are different ....
>>>> I am just doing an allocation but after I don nothing with this array
>>>> and as I have explained it seems to change the value.
>>> I think what Stephen's trying to get at is that in the code you posted,
>>> you only allocate m_mapiIDs, you don't write anything to that array.
>>>
>>> So, of course, when you read from it, it'll contain random data, because
>>> it will contain whatever happened to be in those bytes when malloc() used
>>> them.
>>>
>>> -- dan
>
>
date: Wed, 16 Apr 2008 19:07:10 +0200
author: mosfet
|
|
