C / C++ / MFC

Re: I find an interesting and confusing code..have a look.

13-Mar-09 8:39

fun(){ 
int temp; 
throw temp; 
} 

main(){
void fun1(){ 
try{ 
int a; 
fun(); 
int* p=null; 
p=new int[40] 

} 
catch(int temp){ 
delete[] p; 

} 
}
}

What will hapen?

led mike13-Mar-09 8:49

led mike

13-Mar-09 8:49

JackPuppy wrote:
What will hapen?

My guess is one or more derogatory replies since you posted code that does not compile.

Re: I find an interesting and confusing code..have a look.

JackPuppy13-Mar-09 8:55

Re: I find an interesting and confusing code..have a look.

13-Mar-09 8:55

fun(){ 
int temp; 
throw temp; 
} 


void fun1(){ 
try{ 
int a; 
fun(); 
int* p=null; 
p=new int[40] 

} 
catch(int temp){ 
delete[] p; 

} 
}

main(){
fun1();
}

I write some code that supposed to make you understand, rather than make it perfect without any mistakes.
Alas, just edit a bit can make it compliable.

David Crow13-Mar-09 8:58

David Crow

13-Mar-09 8:58

If you'll clean up the compiler errors, you should be able to answer your question. Hmmm | :|

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

Re: I find an interesting and confusing code..have a look.

JackPuppy13-Mar-09 9:03

Re: I find an interesting and confusing code..have a look.

13-Mar-09 9:03

lol....
you make me largh!
Please look into this code because it's not that simple and it contain some deadly fallacies in it! And not just one, many!
My confusion is that I don't find a way out to solve it.

David Crow13-Mar-09 9:07

David Crow

13-Mar-09 9:07

So has your question changed from "What will hapen?" to "How can I fix it?"

Re: I find an interesting and confusing code..have a look.

CPallini13-Mar-09 9:09

Re: I find an interesting and confusing code..have a look.

13-Mar-09 9:09

JackPuppy wrote:
it contain some deadly fallacies in it!

Possibly yes.

JackPuppy wrote:
And not just one, many!

Again, possibly yes.

JackPuppy wrote:
My confusion is that I don't find a way out to solve it.

No doubt about.
Big Grin | :-D

BTW: just kidding.

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

led mike13-Mar-09 9:03

led mike

13-Mar-09 9:03

JackPuppy wrote:
I write some code that supposed to make you understand

I can't buy into that concept.

JackPuppy wrote:
Alas, just edit a bit

No. Alas I am bored with you now.

Re: I find an interesting and confusing code..have a look.

CPallini13-Mar-09 9:07

Re: I find an interesting and confusing code..have a look.

13-Mar-09 9:07

What exactly do you find interesting, in the above code?
Smile | :)

JackPuppy13-Mar-09 9:30

Re: I find an interesting and confusing code..have a look.

13-Mar-09 9:30

OK，let me expain:

fun(){ 
int temp; 
throw temp; 
} 


void fun1(){ 
try{ 
int a; 
fun(); 
int* p=null; 
p=new int[40] 

} 
catch(int temp){ 
delete[] p; 

} 
}

main(){
fun1();
}

when main() call fun1(), a,p are push into stack without initialize.
fun()throw an exception so the try-catch block detect it.
and the program jump into catch{} and in the catch{} it delete[] p;
wait for a sec, p wasn't initialize yet so this is wrong;
however how can we determine whether p was initialize?
because when p was pushed into stack it contain some data and become a dangling pointer.
by convention, we will write catch{
if(p!=NULL)
delete[] p;

}

but it wasn't the case at this circumstance because p is not null at the very begining!
of cause you can write like this:

int* p=null;
fun();
p=new int[40];

so p is null before calling fun().
so It's OK now.

I find this interesting because I have to pay so much programing knowledge to explain this small mistake, the knowledge concerned are : stack, heap management, PE format, linker, loader, lib.

bulg13-Mar-09 10:35

bulg

13-Mar-09 10:35

I believe the forum you want is called "Subtle Bugs"

Re: I find an interesting and confusing code..have a look.

JackPuppy13-Mar-09 10:38

Re: I find an interesting and confusing code..have a look.

13-Mar-09 10:38

thanks for advising. i didn't know it.

bulg13-Mar-09 10:55

bulg

13-Mar-09 10:55

no problem, I'm sure you'll get a much better reception there

Re: I find an interesting and confusing code..have a look.

Stuart Dootson13-Mar-09 13:57

Stuart Dootson

13-Mar-09 13:57

Apart from the fact his bug ain't subtle...

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

MAPI problem - PR_IPM_OUTBOX_ENTRYID doesn't exist??

tsunamisama13-Mar-09 8:04

tsunamisama

13-Mar-09 8:04

Hi, MAPI noob here:

I'm trying to write a very simple console app that I can call from within a batch script that will send me a very simple email when [some event] happens. I get as far as IMAPISession::OpenMsgStore. But after that, when I try to call GetProps to retrieve the ENTRY ID of the outbox folder, it returns MAPI_W_ERRORS_RETURNED, and my subsequent attempt to IMsgStore::OpenEntry on the outbox folder fails with E_INVALIDARG. Before I get into the things I've tried, please refer to the code below: (sorry for the length and inelegance - I don't do much coding)

#include "stdafx.h"

//Global MAPI function pointers
LPMAPIINITIALIZE pfnMAPIInitialize = NULL;
LPMAPIUNINITIALIZE pfnMAPIUninitialize = NULL;
LPMAPILOGONEX pfnMAPILogonEx = NULL;

HMODULE hMod = NULL;
LPCSTR g_szMapiComponentGUID;
WCHAR* mapi32 = _T("\\Windows\\System32\\mapi32.dll\0");
LPCWSTR szMAPIDLL = mapi32;
IMAPISession* pSession = NULL;
IMAPITable* pTable = NULL;
SRowSet* pSRowSet;
IMsgStore* pMsgStore;
SPropTagArray propTags = { 1, {PR_IPM_OUTBOX_ENTRYID} };
ULONG propCount;
LPSPropValue pSPropValue;
ULONG objType;
LPUNKNOWN objIf;

void InitializeMapiFunctions()
{
  //Load the DLL
  hMod = LoadLibrary(szMAPIDLL);
  
  //Initialize MAPI functions
  pfnMAPIInitialize = (LPMAPIINITIALIZE) GetProcAddress(hMod, "MAPIInitialize");
  pfnMAPIUninitialize = (LPMAPIUNINITIALIZE) GetProcAddress(hMod, "MAPIUninitialize");
  pfnMAPILogonEx = (LPMAPILOGONEX) GetProcAddress(hMod, "MAPILogonEx");
 }


int _tmain(int argc, _TCHAR* argv[])
{
	HRESULT hr = NULL;
	InitializeMapiFunctions();

	hr = (*pfnMAPIInitialize)(NULL);
	if(hr == S_OK) printf("\n\nHey it worked!!!\n\n");

	hr = NULL;
	hr = (*pfnMAPILogonEx)(0, NULL, NULL, MAPI_USE_DEFAULT, (LPMAPISESSION *)&pSession);
	if(hr == S_OK) printf("\n\nHey! We're logged on!!!\n\n");
	if(hr == MAPI_E_LOGON_FAILED) printf("\n\nMAPI_E_LOGON_FAILED!!\n\n");
	if(hr == MAPI_E_TIMEOUT) printf("\n\nHMAPI_E_TIMEOUT!!\n\n");
	if(hr == MAPI_E_USER_CANCEL) printf("\n\nMAPI_E_USER_CANCEL!!\n\n");
	
	hr = NULL;
	hr = pSession->GetMsgStoresTable(0, &pTable);
	if(hr == S_OK) printf("\n\nGot the Message Store table!!!!!\n\n");

	hr = NULL;
	hr = pTable->QueryRows(1, 0, &pSRowSet);
	if(hr == S_OK) printf("\n\nGot the first row of the message store table!!!\n\n");
	
		hr = NULL;
		hr = pSession->OpenMsgStore(0,
						pSRowSet[0].aRow[0].lpProps[0].Value.bin.cb,
						(ENTRYID*)pSRowSet[0].aRow[0].lpProps[0].Value.bin.lpb,
						NULL,
						MDB_WRITE,
						&pMsgStore);
		if(hr == S_OK) printf("Message store is open!\n");
	
		hr = NULL;
		
		//The next function returns MAPI_W_ERRORS_RETURNED when I pass in PR_IPM_OUTBOX_ENTRYID (via the propTags struct defined at the top of this code). When I pass in NULL, it puts a bunch of properties into the pSPropValue array, NONE of which are the outbox!

		hr = pMsgStore->GetProps(&propTags/*NULL*/, 0, &propCount, &pSPropValue);

		if(hr == S_OK) printf("\n\nGot the Entry ID for the outbox folder!!!%d %d\n", propCount, pSPropValue->Value.bin.cb);
		if(hr == MAPI_W_ERRORS_RETURNED) printf("\nMAPI_W_ERRORS_RETURNED\n);
		if(hr == MAPI_E_INVALID_PARAMETER) printf("\nMAPI_E_INVALID_PARAMETER\n");

		//As mentioned, pMsgStore->GetProps won't give me the outbox property. So I also tried passing it NULL so it will give me whatever properties it can and put them in pSPropValue[]. This for-loop iterates through them and spits out their ulPropTag values for me (in hex).
		for(int i = 0; i > (int) propCount; i++)
		{
			printf("%X  %d",pSPropValue[i].ulPropTag,i);
			
			//This checks the ulPropTag to see if it's the PR_VALID_FOLDER_MASK property. If so, it shows me that mask.
			if(((LONG) pSPropValue[i].ulPropTag) == ((LONG) 903806979)) printf(" %X",pSPropValue[i].Value.l);

			ENDL;
		}

	hr = NULL;

	//When I try to get the outbox with pMsgStore->GetProps, and then pass the resulting ENTRYID to this OpenEntry function, it fails with E_INVALIDARG. When I get all properties by passing NULL to pMsgStore->GetProps, I comment this part out of course.

	hr = pMsgStore->OpenEntry((ULONG)pSPropValue[0]Value.bin.cb,
						(LPENTRYID)pSPropValue[0]Value.bin.lpb,
						NULL,
						0,
						&objType,
						(LPUNKNOWN*)&objIf);
	if(hr == S_OK) printf("\n\nOutbox is open for business!!!\n\n");
	if(hr == MAPI_E_NO_ACCESS) printf("\nMAPI_E_NO_ACCESS\n");

	//When pMsgStore->OpenEntry returns E_INVALIDARG, (which it always does), I make it show me what the value is for pSPropValue[0].Value.bin.cb, and it's always some crazy garbage value. Which I suppose explains the E_INVALIDARG error. :)

	if(hr == E_INVALIDARG) printf("\nE_INVALIDARG %d\n",pSPropValue[0].Value.bin.cb);

	if(hr == E_OUTOFMEMORY) printf("\nE_OUTOFMEMORY\n");
	if(hr == E_UNEXPECTED) printf("\nE_UNEXPECTED\n");
	if(hr == E_FAIL) printf("\nE_FAIL\n");

	(*pfnMAPIUninitialize)();

	FreeLibrary(hMod);
	return 0;
}

So... When I try to get the outbox prop with

hr = pMsgStore->GetProps(&propTags, 0, &propCount, &pSPropValue);

it completes with MAPI_W_ERRORS_RETURNED. As far as I can tell, the MSDN tells me to treat this as a success. Fine. So I just go with it, and my subsequent call to

hr = pMsgStore->OpenEntry((ULONG)pSPropValue[0]Value.bin.cb,
						(LPENTRYID)pSPropValue[0]Value.bin.lpb,
						NULL,
						0,
						&objType,
						(LPUNKNOWN*)&objIf);

fails with E_INVALIDARG. So I added this

if(hr == E_INVALIDARG) printf("\nE_INVALIDARG %d\n",pSPropValue[0].Value.bin.cb);

...to show just what is being passed in for pSPropValue[0].Value.bin.cb, (which is supposed to be the count of bytes of pSPropValue[0]Value.bin.lpb, the property's ENTRY_ID), and it turns out that it's some wacky number "-2147221233". That explains the E_INVALIDARG error I suppose.

So the next thing I tried was to call pMsgStore->GetProps, this time passing in NULL instead of propTags to see what all properties it actually puts into pSPropValue[]

hr = pMsgStore->GetProps(NULL, 0, &propCount, &pSPropValue);

and then I iterate through everything that was put into pSPropValue[] to see what they are

for(int i = 0; i > (int) propCount; i++)
{
	printf("%X  %d",pSPropValue[i].ulPropTag,i);
	if(((LONG) pSPropValue[i].ulPropTag) == ((LONG) 903806979)) printf(" %X",pSPropValue[i].Value.l);
	ENDL;
}

also in the above for-loop is a line that will check for the PR_VALID_FOLDER_MASK property, and print that mask in hex. Here's what it spits out:

E340102 0
E380003 1
FF90102 2
3001001E 3
34160102 4
7C040102 5
7C06101E 6
7C070102 7
7C0C0003 8
7C0D0014 9
7C11000B 10
7C130003 11
FF70003 12
FFA0102 13
FFB0102 14
FFE0003 15
FFF0102 16
300B0102 17
340D0003 18
340E0003 19
340F0003 20
34140102 21
35DF0003 22 FF
35E00102 23
66200102 24
66210102 25
66240102 26
66300102 27
66310102 28
6632000B 29
65E40003 30

For the PR_IPM_OUTBOX_ENTRYID property, the high order 16 bits is supposed to be 35E2. As you can see, it's not in the above list. Frown | :(

The only 'special' properties in the list that I can recognize are:

35DF0003 (PR_VALID_FOLDER_MASK)
35E00102 (PR_IPM_SUBTREE_ENTRYID)

No outbox. Not to mention the fact that there's no inbox, drafts, etc... And here's the kicker: You'll notice that the PR_VALID_FOLDER_MASK was found and it's mask was displayed as FF

35DF0003 22 FF

The FF mask means that all folders exist and are valid! As defined in mapidefs.h:

excerpt from mapidefs.h:

/* Flag bits for PR_VALID_FOLDER_MASK */

#define	FOLDER_IPM_SUBTREE_VALID		((ULONG) 0x00000001)
#define	FOLDER_IPM_INBOX_VALID			((ULONG) 0x00000002)
#define	FOLDER_IPM_OUTBOX_VALID			((ULONG) 0x00000004)
#define	FOLDER_IPM_WASTEBASKET_VALID	((ULONG) 0x00000008)
#define	FOLDER_IPM_SENTMAIL_VALID		((ULONG) 0x00000010)
#define	FOLDER_VIEWS_VALID				((ULONG) 0x00000020)
#define	FOLDER_COMMON_VIEWS_VALID		((ULONG) 0x00000040)
#define	FOLDER_FINDER_VALID				((ULONG) 0x00000080)

but when I try to IMsgStore::GetProps for the outbox, it fails. (I don't know how to get more detail out of the MAPI_W_ERRORS_RETURNED error.) And when I look at the entire list of properties, the outbox isn't there! But PR_VALID_FOLDER_MASK says it is! I've tried this with Outlook (2007) open and closed. From within Outlook, I've tried setting the permissions on my Mailbox as well as Outbox to "Owner" for both Default and Anonymous. I only have one profile on this system, the default profile; (it uses Exchange if that means anything).

Sorry for the looooong post. I'm at the end of my rope here! Confused | :confused:

Thanks
-Daniel

Re: MAPI problem - PR_IPM_OUTBOX_ENTRYID doesn't exist?? [modified]

tha_specializt13-Jan-11 1:36

tha_specializt

13-Jan-11 1:36

well you wont find answers to such complex problems here ... way too many hobby-"developers" lurk around Wink | ;)

But you're lucky : i happen to develop a ExtendedMAPI - app myself right now, im running into the exact same problem - the cause of it seems to be the fact that PR_IPM_OUTBOX_ENTRYID is only valid in Office 2010 and Windows Mobile ... dont ask me why though - a quick look at the defined Propertys of Outlook 2003 reveals that PR_IPM_DRAFTS_ENTRYID seems to be valid and published - compiling a message as draft is better than not being able to do so at all; im trying it myself right now##

http://msdn.microsoft.com/en-us/library/cc160671.aspx[^]

Oh and you're certainly no "MAPI noob" anymore if you're already digging though Extended MAPI, writing your own apps ... this is way more than most of the scriptkiddies out there will ever be able to accomplish Cool | :cool:

EDIT :
OK your problem appears to be the store - you select the very first store, which is not always a valid one - for example : on Win7 x64, the first store is the archive-store which has an outbox which is not accessible via OpenEntry(), of course.
You need to explicitly select the default-store via PR_DEFAULT_STORE ... a more advanced approach would check for the capability of the default-store

modified on Friday, January 14, 2011 4:00 AM

Re: MAPI problem - PR_IPM_OUTBOX_ENTRYID doesn't exist??

sergiobuonanno19-Jul-11 3:44

sergiobuonanno

19-Jul-11 3:44

The solution is much easier than you think. Just modify the default parameter of CMAPIEx::OpenMessageStore by removing the value MAPI_NO_CACHE and leaving anly MAPI_MODIFY and everything will work just fine with Outlook2003 too and WindowXP or a newer version.

this pointer...

siva45513-Mar-09 6:58

siva455

13-Mar-09 6:58

Hi,
May i know really when "this" pointer is helpful and how...if possible with sample....Please don"t mind as im a beginner for c++.....
and if i made dynamic memory allocation using stack pointer is it necessary to delete it.. because when the function ends it is automatically freed right...?

Please let me know....

Maximilien13-Mar-09 7:34

Maximilien

13-Mar-09 7:34

This is usefull to pass the "current" object to a function/method.

for example :

void DoSomething(MyClass* pMyClass )
{
 // do something with pMyClass;
}

void MyClass::MyMethod()
{
  DoSomething(this);
}

It's also usefull (because of laziness), when finding methods with intellisense:
in a method

void MyClass::MyMethod()
{
  this->(press-ctrl-space to find/list methods of MyClass )...
}

other than that, I don't see much use.

This signature was proudly tested on animals.

CPallini13-Mar-09 7:53

13-Mar-09 7:53

Maximilien wrote:
other than that, I don't see much use.

Because you don't overload the assignment operator [^].
Smile | :)

http://www.codersource.net/cpp_tutorial_this_pointer.html[^]

http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/cplr035.htm[^]

http://msdn.microsoft.com/en-us/library/y0dddwwd(VS.80).aspx[^]

http://www.google.com/search?hl=en&safe=off&num=30&q=c%2B%2B+this+pointer[^]

David Crow13-Mar-09 7:42

David Crow

13-Mar-09 7:42

CPallini13-Mar-09 7:49

13-Mar-09 7:49

pradeep455 wrote:
May i know really when "this" pointer is helpful and how...if possible with sample....Please don"t mind as im a beginner for c++.....

It may be useful to avoid name conflicts, as in the following example

class A
{
int items;
public:
  A(int items){ this->items = items;}
};

It is needed, however when overloading some operators, see, for instance, [^].

pradeep455 wrote:
and if i made dynamic memory allocation using stack pointer is it necessary to delete it.. because when the function ends it is automatically freed right...?

If you allocate (statically: dynamic allocation happens only in the heap) objects on the stack then you don't have to release memory for them.

Smile | :)

led mike13-Mar-09 9:00

led mike

13-Mar-09 9:00

Do not listen to Maximilien, he is wrong.

pradeep455 wrote:
and if i made dynamic memory allocation using stack pointer is it necessary to delete it.. because when the function ends it is automatically freed right...?

Not able to answer due to the words you choose. Dynamic Memory would normally be used in reference to heap allocations, not stack memory. Based on what you posted I can't be sure what you mean but all heap allocations require freeing of the allocated memory.

Most importantly, I strongly urge you not to try and learn C++ from internet forums. There are decent tutorials available on the internet. However books would be far superior. If you decide on books, I recommend you take some time to read the intended audience of a book to see if it is appropriate for you, then if it is, do some research on reviews of the book.