MFC property pages don't keep title when in for loop

Question

4.00/5 (1 vote)

See more:

I am trying to create some CPropertyPages to go on a CPropertySheet as follows:

long numberOfPages;
std::vector<myproppage*> pPages;

for( long i=0; i < numberOfPages; i++ )
{
	pPages[i] = new MyPropPage();
	pPages[i]->m_psp.dwFlags |= PSP_USETITLE;
	CString title0(_T("title0"));
	pPages[i]->m_psp.pszTitle = LPCTSTR(title0);
	pPropertySheet->AddPage(pages[l]);

}

In the for loop, the title is initialised correctly. Whne the end of a loop is reached, the title that was just set is lost, and just contains garbage. If I don't have this in a loop the title is not overwritten with garbage. Please could somebody help with this as I am losing the will to live :)
is there a problem with memory that is initialised in a for loop?

Posted 14-Jun-11 1:26am

Jackie Lloyd

Updated 14-Jun-11 1:28am

v2

Add a Solution

2 solutions

Solution 1

XML

std::vector<myproppage*> pPages;

and

MIDL

pPages[i] = new MyPropPage();

are not the same thing.

Put
CString title0(_T("title0"));

above and out of your for loop. And you failed to initialize numberOfPages from else where. And its not just CString anymore.

MIDL

pPages[i]->m_psp.pszTitle = title0;

Posted 14-Jun-11 2:09am

The_Inventor

Comments

Jackie Lloyd 14-Jun-11 8:35am

Thanks for your comments.
std::vector<myproppage*> should have capitals - sorry, I didn't spot the error in my typing in here. My code does not have this mistake. I have initialised numberOfPages in my code but did not show that - sorry again.

So my code is

<pre>
long numberOfPages = 3;
std::vector<myproppage*> pPages;

for( long i=0; i < numberOfPages; i++ )
{
pPages[i] = new MyPropPage();
pPages[i]->m_psp.dwFlags |= PSP_USETITLE;
CString title0(_T("title0"));
pPages[i]->m_psp.pszTitle = LPCTSTR(title0);
pPropertySheet->AddPage(pages[l]);

}</pre>

I don't understand your comments about the CString - please could you explain. Mnay thanks

Jackie Lloyd 14-Jun-11 8:36am

why does myproppage have no capitals again - I typed it correctly? Is it because it has <>s round it?

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Albert Holguin · Accepted Answer · 2011-06-14T03:19:00

Solution 2

If you look at that loop statement, the CString is defined within it so it's probably going out of scope and getting deallocated after the loop. Try either allocating it outside of the loop or allocate the CString on the heap (just be sure to deallocate later).

Posted 14-Jun-11 3:19am

Albert Holguin

Comments

Jackie Lloyd 14-Jun-11 9:35am

Great - that works. Many thanks. I was trying to find what was going out of scope but didn't think the CString would matter becuase the string is written into the pszTitle variable before the end of the loop. Can you explain why the CString still matters at this stage?

Albert Holguin 14-Jun-11 9:37am

because you're passing the pointer to it... LPCTSTR <- first two letters, Long Pointer... if you were making a copy, it wouldn't matter

Jackie Lloyd 14-Jun-11 9:45am

ahhh - I see, thanks again :)

Albert Holguin 14-Jun-11 10:39am

no prob :)