1

I am reading text from a file and showing in an edit control. The file has multiple lines. But whenever a line ends, the edit control is showing a '|' symbol and then goes to the new line.

For example, if the content of the file is

First
Second
Third

The edit control shows

First|
Second|
Third

Note that, the edit control shows the pipe symbol, and then goes to a new line. I think that symbol represents either \n or \r which it couldn't show properly. But when I display the same text inside the loop using a MessageBox() function, I don't get the pipe symbol at the end each line.

Here is the relevent portion of my code:

TCHAR buffer[256];
TCHAR file[256] = L"C:\\Documents and Settings\\Dil\\Desktop\\Test.txt";
FILE* fp;

_wfopen_s(&fp, file, L"rt");
while(fgetws(buffer, sizeof(buffer), fp) != NULL)
{
  int len = GetWindowTextLength(hDestEdit);
  SendMessage(hDestEdit, EM_SETSEL, (WPARAM)len, (LPARAM)len);
  SendMessage(hDestEdit, EM_REPLACESEL, 0, reinterpret_cast<LPARAM>(buffer));
}
fclose(fp);

Code used to create the edit control:

hDestEdit = CreateWindowEx(
    WS_EX_CLIENTEDGE, L"EDIT", L"",
    ES_MULTILINE|ES_AUTOVSCROLL|ES_AUTOHSCROLL|WS_TABSTOP|WS_VISIBLE|WS_CHILD,
    100,100,400,300, hWnd, (HMENU)IDC_DEST_EDIT, GetModuleHandle(NULL), NULL);

How can I stop that weird character from showing up inside the edit control?

Edit

I checked using debugger. For each line that is read into buffer, the final character before the null terminator is 0x000a - the line feed. The carriage return 0x000D is not present.

Edit 2

I tried the following code; the pipes are not there at end of each line, but I get 8 or 9 continuous pipes at the end of the last line. I am unable to inspect ndividual characters of buffer in the debugger.

TCHAR * buffer;
int length;
wifstream is;
is.open (file, ios::binary );

// get length of file:
is.seekg (0, ios::end);
length = is.tellg();
is.seekg (0, ios::beg);

// allocate memory:
buffer = new TCHAR [length];

// read data as a block:
is.read (buffer,length);
is.close();

// send message to edit control
int len = GetWindowTextLength(hDestEdit);
SendMessage(hDestEdit, EM_SETSEL, (WPARAM)len, (LPARAM)len);
SendMessage(hDestEdit, EM_REPLACESEL, 0, reinterpret_cast<LPARAM>(buffer));
  • 1
    It might be useful to check your `Test.txt` file to make sure it uses "\r\n" for newlines. – Nate Kohl Aug 29 '12 at 18:58
  • That's novel. You shouldn't get any line breaks at all. Better debug it and at least look at *buffer*. It should contain \r\n, it won't. – Hans Passant Aug 29 '12 at 18:59
  • @HansPassant Yes, it contains only \n. Is that what is causing the problem? How can I fix it? –  Aug 29 '12 at 19:19
  • I don't know, it's novel. But you know it is already wrong so fix that first and replace \n with \r\n. – Hans Passant Aug 29 '12 at 19:26
  • If you're reading the file with fgetws, then seeing only \n is expected: \n is how C treats newlines, and the CRT converts between \n and whatever the platform uses (\r\n) as it reads/writes. (BTW, note that the size arg to [fgetws](http://msdn.microsoft.com/en-us/library/c37dh6kf(v=vs.80).aspx) is a character count, not byte size, so you shouldn't be using sizeof here unless you want a potential buffer overrun) I just tried this on Win7 x64 with a .txt file created in notepad, and am not seeing the pipe chars... – BrendanMcK Aug 29 '12 at 22:48

1 Answers1

1

Why don't you try with:

_wfopen_s(&fp, file, L"rb");

I think the edit control actually needs the \r\n sequence, but fgetws() will no longer preserve them.

NonNumeric
  • 1,079
  • 7
  • 19
  • The OP's code appears to be compiled as UNICODE (given the use of L"..." constants); and if the original file is ANSI, then it's relying on "t" mode to convert the ansi to unicode as it reads. If you instead open as binary, you'll just end up packing the input ANSI right into a UNICODE buffer, ending up with a nonsense string in memory. – BrendanMcK Aug 29 '12 at 22:51