comparing two single char

[deck42]

Hello,

I want to compare two single char, to be more exact I want to know if one is a newline char. So I do:

if(strcmp(tmp, "\n")==0) dosomething

The crazy thing is, it won't work. To Be more exact, although tmp is clearly a pointer to a single newline, strcmp will not give back 0.
It's a bit more complicated though: tmp contains a newline from a textbox. Can that be the problem?

[Paul McKenzie]

Hello,

I want to compare two single char, to be more exact I want to know if one is a newline char. So I do:

if(strcmp(tmp, "\n")==0) dosomething

The crazy thing is, it won't work. To Be more exact, although tmp is clearly a pointer to a single newline, strcmp will not give back 0.
It's a bit more complicated though: tmp contains a newline from a textbox. Can that be the problem?

Is tmp NULL terminated? If not, strcmp() will not work, as both arguments must be null terminated strings.

Regards,

Paul McKenzie

[0xC0000005]

The problem is most likely with getting the string from the text box. A 'text box' is typically used to refer to an edit control but edit controls generally only hold a single line of text and I am not sure how you would get a "\n" out of an edit control. Can you explain further? i.e. Is the 'text box' and edit control? Are you using MFC's CEdit? DDX? GetWindowText()...

[Red Squirrel]

if its a single char just do

if(char=='\n')

If you expect to get strings just make tmp a std string then you can use == as wel.

if(tmp=="\n")

[deck42]

Hello,

Thanks so far!

@Paul McKenzie: Yes it is NULL terminated.

@Red Squirrel: I would like not to use string object. And I thought that "if(char=='\n')" will not work on every machine since '\n' will mean diff. codes partly?

@0xC0000005: I am using an edit control, but not MFC, just WINAPI. I am furthermore using GetWindowText() to obtain the text. Now the edit control DOES have a multiline option. With that on, it will allow you to press enter to insert a new line.
But I suspect that this new line is a different one than "\n". Is that possible?

[0xC0000005]

I still don't understand how you get a single '\n' in an edit control which is usually single-line control. You aren't talking about a literal "\n" are you? A string containing a slash and an 'n'.

My advice would be to learn to use the debugger. Put a breakpoint on the strcmp() line and examine the byte contents of the text buffer.

[souldog]

I am using an edit control, but not MFC, just WINAPI. I am furthermore using GetWindowText() to obtain the text. Now the edit control DOES have a multiline option. With that on, it will allow you to press enter to insert a new line.
But I suspect that this new line is a different one than "\n". Is that possible?

Yes, it is possible.

Microsoft uses "\r\n" when a return is pressed. Carriage return followed by linefeed.

Some executive over at Microsoft gets all sentimental when thinking about the days of typewriters and so insisted that return be implemented this way.

[deck42]

As I said, the edit box does have a multiline option. It is NOT just single lined. With the multiline option on, it has as many lines as you want. Each time you press enter it will insert a new line. The option is called "Multiline", just set it to true.
I did of course use the debugger, just I had not compared the byte values by hand yet - but I did so now and my suspicion was correct: The edit box does have a different new line character. It does have a different value than "\n". Both newline characters are recognized by any text editor though and invoke a line break.
Can someone please explain?

This gets even crazier: although I did introduce a new single char variable called tmp2 which contains just the value 13, which is the same as the newline char from the edit box, strcmp still wont return 0. ???

Here is the whole code now:

			char tmpBuffer[MY_MAX_PATH];
			char* next_token; //Used by strtok_s to store some pointer, see msdn.
			char* next_filter; //Pointer returned by strtok_s.
			int i = 0;
			bool stop = false;

			GetWindowText(GetDlgItem(hDlg, ID_EDITBOX), tmpBuffer, sizeof(tmpBuffer));
			strcpy_s(Filters[0], sizeof(Filters[0]), strtok_s(tmpBuffer, "\n", &next_token));
			while(!stop)
			{
				i++;
				next_filter = strtok_s(NULL, "\n", &next_token);
				if(next_filter!=0) strcpy_s(Filters[i], sizeof(Filters[i]), next_filter);
				else stop = true;
				char* tmp;
				char tmp2 = 13;
				tmp=&Filters[i][strlen(Filters[i])-1];
				if(strcmp(tmp, &tmp2)==0) 
				{
					Filters[i][strlen(Filters[i])-1] = 0;
				}
                       }

[souldog]

see my previous post

If you want to know more about this see http://en.wikipedia.org/wiki/Newline


This is just one of those annoying things we all have to deal with

[deck42]

Thanks!

I am just puzzled by the behavior of strcmp now...
tmp* is clearly pointing to a char of value 13 (checked by debugger), which is also the value of tmp2.
Still strcmp will return -1, meaning that tmp<tmp2...

[deck42]

Well anyways, thanks for your help again.

I solved the problem by also comparing to "\r" now which works. I guess that it did not work with char = 13 had to do with missing 0 terminator.

[Lindley]

The "right" way to do it would be to compare against "\r", "\r\n", and "\n", and accept if any of those is 0.