sending usigned char to listbox

[tcp1]

Got something like the following. A button that read characters from a thrid party tool and sends it to a listbox.
But the contant is not readable.

void dlg::sendtolistbox()
{
  unsigned char buf[250];
  thirdparty.GetData(buf, len);
  Sendmessage(hndl, listboxupdate,0 , (LPARAM)buf);
}
void Mydlg::UpdateListBox(wparam a,laparm b)
{
  m_listbox.AddString((LPCTSTR)b);
}

the characters show up in the list box as short unreadable characters. like it is chopped.
If i change to : Sendmessage(hndl, listboxupdate,0 , (LPARAM)&buf[15]);
Then I can see readable valid strings of up to 50 characters and then empty unreadable characters afterwards. I tried all kinds of things , including using CString, still did not work.

[2kaud]

What is len?

Does GetData() append a NULL terminator to the end of the data obtained into buf?

Have you debugged the program using the debugger and examined the contents of buf in hex to see exactly what is there?

Are you mixing Unicode from GetData() and multi-char in the program (or vice/versa)?

[tcp1]

when I write the buf to file using WriteFile, the content of file is: 15 unreadable characters followed by 50 readable characters and the rest are I'..
When I do the following, I get the 50 readable characters in the listbox.
buf[len]='\0;
Sendmessage(hndl, listboxupdate,0 , (LPARAM)&buf[14]);

[2kaud]

Have you examined the contents of the file in hex with something like HxD to see exactly what is being received? What would you expect to be received against what you are actually receiving?

[tcp1]

Good suggestion. Looked the file up under an hex editor. The first 8 bytes where the number of bytes. Then after, the bytes for the actual text that seem to be correct and the then the 2FEF bytes. Now how one can display all the bytes as readable in the listbox without subclassing the listbox?. As of now , in the list box, I can only display/read the text that comes after the number of bytes?.

[2kaud]

What you are seeing is a length-prefixed string (or sometimes called a Pascal string) as opposed to a null-terminated string as used in c/c++.
See http://en.wikipedia.org/wiki/String_...ength-prefixed

However, if the first 8 bytes is the number of bytes in the string what about the next 7 bytes before the readable characters start - as you said in post #3 that the first 15 chars were unreadable followed by 50 readable chars?

Can you attach the file?

[tcp1]

I do not have the access to the file at this moment. This is a new protocol, 8 bytes + the appended string... This is the new library ... with new protocol ... That 15 bytes is replaced with 8 bytes ... ...

[tcp1]

As I remember, with the new protocol the first 8 bytes in the file, when I used the notepad as the viewer, were extended ASCII characters and maybe these are not supported by Microsoft, VS?.
http://www.theasciicode.com.ar/

[Igor Vartanov]

As long as this is about file, the non-askii bytes are most probably BOM (http://en.m.wikipedia.org/wiki/Byte_order_mark)