C / C++ / MFC

Re: I have a editbox in my toolbar and want change background color

1-May-03 5:57

I believe you'll need to derive a class from CEdit. In that class, handle the WM_CTLCOLOR message.

whofmans1-May-03 21:03

whofmans

1-May-03 21:03

Thanks!

The editbox works, but how can i add a messagehandler? The "Add Message Handler" menu is not there.

I have tried this.

BEGIN_MESSAGE_MAP(CStatusEditBox, CEdit)<br />
	ON_WM_CTLCOLOR()<br />
END_MESSAGE_MAP()

I get the following compiler error:
'GetMessageMap' : member function not declared in 'CStatusEditBox'

Re: I have a editbox in my toolbar and want change background color

David Crow2-May-03 4:15

2-May-03 4:15

Did you use ClassWizard to derive CStatusEditBox from CEdit? The error message you got about GetMessageMap() was because the DECLARE_MESSAGE_MAP macro was missing from the CStatusEditBox class. You can add it manaully, but it's usually better to let ClassWizard do this, and more, for you.

CString Bug???

levay1-May-03 4:52

1-May-03 4:52

I have a very strange bug that I have been unable to track down. I am using a CString extension class called CStringEx. I am simply looping through the string looking for \n for wrapping purposes. Once I reach a certain portion of the loop, I get a memory error and the program crashes.
Now... here is the strange part. While stepping through the code in debug mode, the error DOES NOT HAPPEN. So then I put TraceWin code in the loop so I can see what's going on. Again, in a normal run, the error happens everytime. Then, in an effort to see of the portion of the string I an working with is causeing errors, I perform a CString.Mid() within the loop and output the results. PRESTO, the error stops!! WTF?!? Nothing else in the code has changed. I then pull the trace code out and just do a Mid() to a temp var in the loop. ERROR IS GONE! The simple act of performing a Mid() on the var has stopped the error.
I could keep this hack in the code, but I would rather not. Does anyone have any ideas what could cause a Mid() to stop a memory error from occuring? Is this an allocation issue with CString?
Any insight on this would be greatly appreciated.

The code in question is below:

<br />
void WordWrap( CStringEx &String, int intWrapSize )<br />
{<br />
	FSTRACE("WordWrap(): start\n");<br />
<br />
	CString strTemp;<br />
<br />
	int intSpace = 0;<br />
	int intLineSize = intWrapSize;<br />
	int intStart = intLineSize;<br />
	int intLastStart = 0;<br />
	int intFindLF = String.Find("\n");<br />
<br />
	while ( TRUE )<br />
	{<br />
		if ( (intSpace = String.Find(" ", intStart)) != -1 )<br />
		{<br />
			FSTRACE("WordWrap(): intSpace = %d\n", intSpace);<br />
<br />
			intFindLF = String.Find("\n", intLastStart);<br />
			FSTRACE("WordWrap(): intFindLF = %d\n", intFindLF);<br />
<br />
			if (intFindLF > intSpace || intFindLF == -1)<br />
			{<br />
				String.Insert(intSpace + 1, "\r\n");<br />
				FSTRACE("WordWrap(): insert crlf @ %d\n", intSpace + 1);<br />
<br />
				intLastStart = intSpace + 4;<br />
				intStart = (intSpace + intLineSize) + 3;<br />
			}<br />
			else if (intFindLF != 0)<br />
			//else if (intFindLF != -1)<br />
			{<br />
				intLastStart = intFindLF + 2;<br />
				FSTRACE("WordWrap(): intLastStart = %d\n", intLastStart);<br />
				<br />
				intStart = intFindLF + intLineSize;<br />
				FSTRACE("WordWrap(): intStart = %d\n", intStart);<br />
<br />
			}<br />
			else<br />
			{<br />
				intStart = intFindLF + intLineSize;<br />
				FSTRACE("WordWrap(): intStart = %d\n", intStart);<br />
			}<br />
		}<br />
		else<br />
		{<br />
			FSTRACE("WordWrap(): while - break\n", intSpace);<br />
			break;<br />
		}<br />
<br />
		// Solves the error ????<br />
		// if I rem out this code, the error comes back consistantly<br />
		strTemp = String.Mid(intLastStart, intStart);<br />
		//FSTRACE("WordWrap(): [%s]\n", String.Mid(intLastStart, intStart));<br />
		FSTRACE("WordWrap(): --------------------------\n");<br />
	}<br />
	<br />
	FSTRACE("WordWrap(): returning\n");<br />
	return;<br />
}<br />
<br />

David Crow1-May-03 5:07

1-May-03 5:07

Can you provide a code snippet on how you are calling the function?

Have you tried using just a CString object to see what happens?

levay1-May-03 5:15

1-May-03 5:15

Sure. All of the code is contained within and email parsing program. The plain text body requires formating that is handled through this function (as you can see from the trace code, I traced the error as far back as I could):

<br />
BOOL FormatBodyText(CStringEx &strBodyText, CAttributes *Attrib)<br />
{<br />
	FSTRACE("Starting FormatBodyText...\n");<br />
<br />
	WordWrap(strBodyText, Attrib->m_intWrapSize);<br />
	FSTRACE("did word wrapping...\n");<br />
<br />
	ParseForLinks(strBodyText, Attrib->m_strHrefReplace, Attrib->m_strMailtoReplace);<br />
	FSTRACE("did parseForLinks...\n");<br />
<br />
	if(Attrib->m_bDoHopLinks)<br />
		ParseForHopLinks(strBodyText, Attrib);<br />
<br />
	return true;<br />
}<br />

The function is called like this:

<br />
FormatBodyText(MsgQry->m_strBodyText, Attrib);<br />

MsgQry is a pointer to a class containing the various parts of the email message.
Attrib is a pointer to a class containing the program's attributes.

Thanks again

David Crow1-May-03 5:39

1-May-03 5:39

Have you narrowed it down to a CString object formatted in a particular way? I tried it with a few "dummy" strings and it did not crash. I'm not sure if it did what it was supposed to (logic), but it did not crash.

levay1-May-03 5:49

1-May-03 5:49

It only crashes on one particular string (email body text). There is nothing unusual about the body text at all. The code works perfectly on every other string I throw at it. I'm assuming that the string itself or the code is not the problem because the Mid() stopped the error and the error doesn't occur while stepping through the code.
Are there any known allocation issues with CStrings? What kind of memory movement does a Mid perform that would stop this from happening.
Another note of interest is that in order for the Mid to stop the error, it has to pull a substring from within the string. Performing a Mid(0,str.GetLength()) still causes the error. Performing a Mid(5,20) stops the error. *shrug*

levay1-May-03 6:10

1-May-03 6:10

Here is another strange point. After making the statement above about "performing a Mid(5,20)", I tried that exact number (I was just using those numbers as an example. I had up till this point, used the vars I had available in the loop). That didn't work! In order to make the error stop, I have to pull at least 48 chars in the mid:

<br />
strTemp = String.Mid(106, 48);<br />

It doesn't matter where in the string I start. Mid(1,48), Mid(1000,48). Just as long as I pull at least 48 chars from the string. Anything less, creates the error.

*big shrug*

Nitron1-May-03 5:38

Nitron

1-May-03 5:38

Just a curiosity...

Does:

String.Replace("\n", "\r\n");

not work for some reason?

- Nitron

"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb

levay1-May-03 5:52

1-May-03 5:52

I'm not simply replacing \n with \r\n. I'm wrapping a string at specified positions. If linewrap is set at 80, then I move to that pos in the line then look for the next space (don't want to wrap in the middle of a word), and insert a \r\n.

Nitron1-May-03 5:54

Nitron

1-May-03 5:54

ahhh. i c

- Nitron

"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb

David Crow1-May-03 7:45

1-May-03 7:45

levay wrote:
If linewrap is set at 80, then I move to that pos in the line then look for the next space...

Shouldn't you be looking for the previous space? If position 80 is in the middle of a 10-letter word, you'd actually be breaking at position 85.

levay1-May-03 9:00

1-May-03 9:00

Agreed. Relative wrapping was good enough for what I was trying to accomplish at that time. I'll probably go back later and make it more accurate (ie: <= linewrap), but at this time it wasn't a priority.

Rein Hillmann1-May-03 6:30

Rein Hillmann

1-May-03 6:30

I don't know what your CStringEx extension class is or how it is defined but by the symptoms, I'd guess you have stack corruption. The fact that the bug goes away when you allocate more memory leads me to believe that something is trashing the stack if that allocation doesn't take place.

I tried to reproduce this problem using CString but couldn't (in debug and retail). Have you tried to use CString instead of CStringEx? What you could also do is debug the retail executable in the dissasembler and keep watching the stack to see if the return pointer is kept intact.

levay1-May-03 7:02

1-May-03 7:02

Your hunch was right. Not sure where the corruption is happening yet, but I was able to preempt it by doing the following:

<br />
MsgQry->m_strBodyText.GetBuffer(dwSize + 1);<br />
MsgQry->m_strBodyText.ReleaseBuffer(dwSize + 1);<br />

I have never used GetBuffer/ReleaseBuffer for pre-allocating CString memory before. Anything I should be aware of? Any performance hits by allocating in this way? Is there a better way to allocate than this?

Thanks