win32 File I/O question
March 28, 2000 08:03 PM
Hi..
When I use the win32 file I/O function to output text(using WriteFile), the newline const (\n) gets displayed as a square block (in the text file) instead of moving to a new line.
Anyone knows how to make it write a new line instead of the block??
Thanks..
March 28, 2000 10:57 PM
Try using \r\n instead of just \n. (Or it might be \n\r, but I''m pretty sure it''s one of the two.) DOS text files like have a carriage return-new line pair instead of just a new line character. It''s a legacy from the days of teletype output.
2,082
March 28, 2000 11:32 PM
A better solution is to just use the standard I/O functions (ie streams) if you''re doing text files. That way, the native line termination characters are automatically used when you use std::endl.
-Brian
-Brian
March 28, 2000 11:46 PM
Sometimes you need to use the API functions. It''s still important to know in the (admittedly contrived) case of writing a text file to a remote resource. ex: \\othercomputer\textfile.txt. Last I checked the file iostreams weren''t too happy about Windows style remote resources. (you can''t specify necessary security parameters.)
March 29, 2000 12:14 AM
I see..thanks
I''m using the _crtMem debug library to test for memory leaks and the output file must take a HFILE handle (one created by CreateFile) rather than a FILE pointer (C file stream)
but with the HFILE pointer, the supposingly newlines are converted to square characters and everything is in 1 one line, even the output from the library.
Any idea plz.
I''m using the _crtMem debug library to test for memory leaks and the output file must take a HFILE handle (one created by CreateFile) rather than a FILE pointer (C file stream)
but with the HFILE pointer, the supposingly newlines are converted to square characters and everything is in 1 one line, even the output from the library.
Any idea plz.
289
March 29, 2000 07:15 AM
I never had that problem before -- first time I tried it, my strings were being written on separate lines, and I viewed the file in Notepad. I think it might have been because I was writing the terminating NULL character ''\0''? It''s a "hidden" character at the end of a character array (string) that many C functions use. It could also be the program you are using to view it. I really don''t know much about this though -- just an idea. 
Sabre Multimedia
- null_pointer
Sabre Multimedia
- null_pointer
March 29, 2000 07:29 AM
They''re not being converted as such. Those square characters are your newlines. Notepad just displays them that way to show that there is something there. The newline in C \n is not sufficient for DOS/WINDOWS apps which often need \r\n (or \n\r, they seem to function equivalently) to recognise a newline. Unix machines just use the \n, and I am not at all sure but I think Macs just use \r. So you may have to write a parsing routine which takes your \n and converts it to \r\n in the output.
March 29, 2000 07:51 PM
null_pointer:
Interesting. I use Notepad to view the files too but there are all square blocks..
May I know how you created the file handle?? I use the windoz function CreateFile
I have tried this and \r is enough to give a newline. \n always give a square block, even with \r\n
Interesting. I use Notepad to view the files too but there are all square blocks..
May I know how you created the file handle?? I use the windoz function CreateFile
I have tried this and \r is enough to give a newline. \n always give a square block, even with \r\n
289
March 30, 2000 06:10 AM
Oops! it wasn''t Notepad -- it was MSVC''s text file viewer. You could do something like the following to make your code more readable, though:
I think that''s right -- the parameters might be a little mixed up because I haven''t used it in a while. I think \r and \n are counted as 1 character each. If not, you''ll have to adjust LineReturn[] and the WriteFile statements that use it.
Good Luck!
- null_pointer
Sabre Multimedia
const char LineReturn[3] = "\r\n";
// start on line 3
WriteFile(hFile, LineReturn, sizeof(char) * 2);
WriteFile(hFile, LineReturn, sizeof(char) * 2);
// write some more data
WriteFile(hFile, MapArray, 500);
// end the line
WriteFile(hFile, LineReturn, sizeof(char) * 2);
// continue writing more data...
I think that''s right -- the parameters might be a little mixed up because I haven''t used it in a while. I think \r and \n are counted as 1 character each. If not, you''ll have to adjust LineReturn[] and the WriteFile statements that use it.
Good Luck!
- null_pointer
Sabre Multimedia
March 30, 2000 07:32 PM
The sad thing is it''s not my functions that are writing to the file.
It''s the VC++ version of C debug library functions (the _CrtMemory checking functions) that is spitting out the text, and I can''t find a way to make WriteFile spit out the correct newline character.
Guess I have to post process the file..8(..
It''s the VC++ version of C debug library functions (the _CrtMemory checking functions) that is spitting out the text, and I can''t find a way to make WriteFile spit out the correct newline character.
Guess I have to post process the file..8(..
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement