I’ll clarify just in case that this is a function . I noticed that it skips the character to move to another line: "\n" . How to make a transition for this function?

UPDATE:

Code example:

 int main() { string PathEXE = "C:\\Projects\\tests\\Release\\"; auto file = CreateFileA((PathEXE+"logtest.txt").c_str(), GENERIC_WRITE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (file == INVALID_HANDLE_VALUE) { printf("ERROR %x \n", GetLastError()); std::cout << "\nRELOAD NEEDED. LOG ERROR";//messagebox } DWORD size = 0; std::string text = "\n1"; for (int i = 0; i < 100; ++i) { WriteFile(file, text.c_str(), (text).size(), &size, NULL); size += (text).size(); } return 0; }

UPDATE2: When I wrote the question, I opened the file with a regular notepad (Windows 7). Now opened Notepad ++ and there are transitions to another line of Oo. how so?

  • 2
    Something I do not see in the documentation on WriteFile information that some characters are skipped. It makes sense to assume that the bug is in your code. Show how exactly you write and how you check the result. (Mandatory reference: minimum reproducible example .) - VladD
  • 3
    It can not miss anything, because it works with bytes, not with text. - Qwertiy ♦
  • @VladD example added - Dmitry
  • one
    The problem is not WinAPI, but in the software with which you are watching the resulting file. INFA 146%. - Vladimir Martyanov
  • four
    For transitions in Notepad, you need to write \r\n , Notepad ++ understands both entries and windows and * nix - Grundy

1 answer 1

The problem is this.

When you write strings to a file via standard stream functions (and the file is opened as text, not binary), on-the-fly conversion of text lines ( \n ) into system-dependent (on Windows \r\n ) occurs on the fly. And the file contains the ends of lines of the form \r\n (can be checked with any hex editor).

When you write via WriteFile , it knows nothing about strings, and writes to the file as it is. That is, the file ends of the lines of the form \n . (You can check it again with any hex editor.)

As @Grundy correctly suggests in the comment, the notepad perceives only the ends of lines of the form \r\n . On the other hand, in the Unix standard, the line breaks are \n , and your file is essentially unintentionally turned out to be in this format. Because other editors understand this format, they interpret your file as Unix text and show it the way you want it.

Solution - either add \r before \n to your strings, or write through standard string functions of the language.