C / C++ / MFC

Re: String to valid XML tag

2-May-02 5:53

If you are using IXMLDOMDocument, if I remember it correctly, it's all taken care of for you.
Are you maybe just looking for a general escape function?

Braulio Dez2-May-02 6:06

Braulio Dez

2-May-02 6:06

Hi,

Yes, I´m using MsXml, but I think CreateElement throws one exception when you pass a wrong tag name, I don´t know if maybe there is one method there that converts from the string to a valid tag name

Re: String to valid XML tag

Niklas L2-May-02 6:48

2-May-02 6:48

Yes, the tag names and attribute names are different. You are not allowed to use special characters there. In attribute values and text data however you can just pass in anything you like. Calling pXMLDoc->createProcessingInstruction("xml", "version='1.0' encoding='UTF-8'"); will give a coding of your choice. (just tried it)

As for tag names and attribute names, I suspect yuo have to 'destroy' data to get where you want, i.e. replacing e.g. '>' and '<' and all other 'illegal' characters with '_'.

Memory Leaks

dazinith2-May-02 5:25

2-May-02 5:25

hrm.

i have about 8 different memory leaks, and i can't seem to track em down.. so i have some questions..

1) do memory leaks only occur when the 'new' keyword is used to create a pointer, and that pointer is never deleted (using 'delete' keyword)?

2) if my memory leaks say 'CObject' is there any way to tell what class it is?

i am using several classes i derived from CObject, and i use CObArray quite alot too.. i know that after im done with a CObArray that i have to loop through it and delete all the objects, and im doing this everywhere..

any help in general would be great.. i don't want to have any memory leaks..

thanks!

-dz

Ravi Bhavnani2-May-02 5:29

2-May-02 5:29

dazinith wrote:
do memory leaks only occur when the 'new' keyword is used to create a pointer
You can also get memory leaks when you create GDI objects such as pens and brushes and forget to unselect them out of the DC and delete them.

dazinith wrote:
i know that after im done with a CObArray that i have to loop through it and delete all the objects,
Perhaps you're forgetting to do a RemoveAll() after you delete the individual objects?

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

Tom Archer2-May-02 5:37

Tom Archer

2-May-02 5:37

Actually, you do not need to remove items from an array once they've been deleted. I do it as a sanity check so that after the delete loop I can assert if any items remain in the array. However, once you've deleted the actual item in memory, the array simply points to an invalid item for which no memory is still allocated.

Cheers,
Tom Archer
Author, Inside C#

A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Ravi Bhavnani2-May-02 5:45

2-May-02 5:45

Ah. Looks like CObArray's destructor cleans up after itself. Thanks for the tip!

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

Tom Archer2-May-02 5:55

Tom Archer

2-May-02 5:55

No problem. I've actually spent so much time in the guts of MFC that I've often thought of writing a second edtion of the MFC Internals book. Do you think such a book would sell? I think it would. I think there are stil enough people new to MFC that would get a tremendous amount out of a book that explains how their apps are working internally. The thing that I would add to such a book, however, is a section at the end of each chapter that basically says "Ok. You know how this bit works internally. Here's where you can apply this knowledge". I think that would make the book more practical instead of coming off as just trivia. What do you think?+

Cheers,
Tom Archer
Author, Inside C#

A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Ravi Bhavnani2-May-02 6:05

2-May-02 6:05

Tom, I for one would welcome (more) info on MFC's internals. And as you pointed out, real-world usage examples would come in *very* handy.

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

Paresh Solanki2-May-02 6:43

Paresh Solanki

2-May-02 6:43

Sounds like a good idea.

There's a couple of people here (including me) who'd like to know more about MFC and how to apply it.

A problem I have is that I know what I want a program to do, but not how to achieve that in a windows environment. CP has helped a lot, but sometimes a book of 'typical' applications would help too

Paresh Solanki
There is no substitute for genuine lack of preparation.

Tom Archer2-May-02 5:42

Tom Archer

2-May-02 5:42

dazinith wrote:
any help in general would be great.. i don't want to have any memory leaks..

Always a worthy goal Smile | :)

The way to track down memory leaks in an MFC application - short of spending hours and hours manually tracking down and tracing on every new and delete operation - is to use the CMemoryState class. There are actually several ways to use this class so instead of me enumerating them all, I'll just point you to the article entitled "Taking Memory Snapshots" in your MSDN online help.

Good luck! Everybody hates those *#*& things!

Cheers,
Tom Archer
Author, Inside C#

A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.

Niklas L2-May-02 5:44

2-May-02 5:44

Make sure you have no code that looks like

CObArray vec;
for (int i = 0; i < vec.GetSize(); i++)
{
	delete vec[i];
	vec.RemoveAt(i);
}

where just every other element is deleted. This one I've seen lots of times.

dazinith2-May-02 5:51

2-May-02 5:51

my deleting of CObArray's looks like this

// delete all items in the text list
if (m_oaText->GetSize() > 0)
do
{
CTextPrintObject* pObj = (CTextPrintObject*)m_oaText->GetAt(0);
delete pObj;
m_oaText->RemoveAt(0);
} while (m_oaText->GetSize() > 0);

m_oaText->RemoveAll();
delete m_oaText;

does this look right?

-dz

Niklas L2-May-02 6:00

2-May-02 6:00

Sure looks functional enough. (Even though quite inefficient calling RemoveAt(0), since the array has to do a copy of all remaining items for each turn in the loop. Maybe you should consider looping backwards.)
Does you CTextPrintObject allocate any memory, not deleted in it's destructor?

Ravi Bhavnani2-May-02 6:03

2-May-02 6:03

After having read Tom's post, I think I'd write this as:

for (long nIndex=0; (nIndex < m_oaText->GetSize()); nIndex++) {
    CTextPrintObject* pObj = (CTextPrintObject*) m_oaText->GetAt(nIndex);
    ASSERT (pObj != NULL);
    delete pObj;
    m_oaText->SetAt (nIndex, NULL);  // good coding hygiene
}
delete m_oaText;

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

dazinith2-May-02 6:05

2-May-02 6:05

welp i think i found where the leak is.. but i don't know whats wrong with the code.. if i comment out this chunk of code i only get 1 memory leak.. if i dont comment it out i get 8.. anyone have any suggestions as to whats wrong with this? basicly im just setting dates for a couple date pickers..

//Setup the date picker
m_cdPeriodEnd.SetFormat(_T("MM/dd/yyyy")); // force short date format to MM/dd/yyyy
m_cdPeriodBegin.SetFormat(_T("MM/dd/yyyy"));
COleDateTime dtMin(2002,7,31,0,0,0); // set the minimum date which can be chosen
COleDateTime dtMax(2003,6,30,0,0,0); // set the maximum date which can be chosen

// verify the min and max dates are valid, then set the range for the date picker
if ((dtMin.GetStatus() == COleDateTime::valid) && (dtMax.GetStatus() == COleDateTime::valid))
{
m_cdPeriodEnd.SetRange(&dtMin,&dtMax);
m_cdPeriodBegin.SetRange(&dtMin,&dtMax);
}
else
{
if (dtMin.GetStatus() != COleDateTime::valid)
AfxMessageBox("This program has attempted to set an invalid minimum date for selection.");
if (dtMax.GetStatus() != COleDateTime::valid)
AfxMessageBox("This program has attempted to set an invalid maximum date for selection.");
CDialog::EndDialog(IDABORT);
}

-dz

dazinith2-May-02 6:20