x++ newline CRLF vs LF

If you’re just getting started with X++, the first surprise about “newlines” is that the characters you type in a string literal aren’t always the characters that show up in a file, a label, or a UI control. On Windows you’ll bump into two common newline conventions: LF, written as \n, and CRLF, written as \r\n. LF is the lone line-feed character used by Unix and modern macOS, while CRLF is a carriage-return followed by line-feed, which many Windows tools still expect. X++ lets you embed either form in your strings, and which one you choose depends on where that string will be consumed.

When you write a literal like "Hello\nWorld" in X++, the backslash-n sequence is interpreted as a newline at compile time, so when you log it with info() or pass it to something that understands line breaks you’ll get two lines. By contrast, "Hello\\nWorld" contains a backslash character followed by the letter n—two visible characters and no line break—handy when you need to show the sequence itself in messages or documentation. If you need Windows-style newlines for a text export, concatenate "\r\n" where you want the break; if you’re targeting a Linux process or a system that prefers LF, stick to "\n". The rule of thumb: \n is the concept of “next line,” and \r\n is the Windows wire format for it.

Real life adds rendering nuances. The Dynamics client’s Info log and many dialogs happily treat \n as a new line, but HTML surfaces—like emails, some report templates, or custom web controls—don’t; they want <br> or paragraph tags. Labels can contain \n, yet whether you see an actual break depends on the control that renders the text. If a string looks “flat” on screen, it’s not that X++ forgot your newline; it’s that the presentation layer doesn’t translate the character into a visual break. In those cases, convert \n to <br> before sending the content to HTML, or use the target system’s newline token.

Working with files is where CRLF vs LF really matters. Many Windows editors and older downstream tools expect CRLF in CSVs and flat files, while Linux services and Git repos often prefer LF. You can generate or normalize endings with simple string utilities. Build your content using one style consistently, then adjust at the edge if needed: text = strReplace(text, "\n", "\r\n"); will flip LF to CRLF, and the inverse will collapse CRLF to LF. When you hop into .NET interop from X++, System.Environment::NewLine gives you the host’s natural newline, which is a convenient way to match whatever environment your code is running in without hard-coding it.

You might also hear advice like “replace the __NL__ string in the preprocessor output with newlines.” That phrase comes from the C/C++ world, where people debug macros by injecting a placeholder token during preprocessing and then post-processing it into real line breaks. While X++ doesn’t expose that exact preprocessing workflow, the idea is still useful: if some pipeline is swallowing your \n, put a unique marker like __NL__ in your text, move it through the pipeline, then swap the marker for \n or \r\n right before display or file write. It’s a practical trick when multiple layers handle escaping differently.

Finally, it helps to tie this back to a tiny warehouse-flavored example. Imagine you’re producing a plain-text pick list for an electronics line and you want Windows-friendly CRLF breaks for a legacy label printer. You might assemble it like this: build each line with strFmt("BIN:%1 ITEM:%2 QTY:%3", binId, itemId, qty), append "\r\n" after each line, and write the buffer to disk. If the same content needs to be shown in a browser-based dashboard, convert those \r\n to <br> before displaying. Once you see newline characters as data you purposely shape for the destination—LF for Unixy pipes, CRLF for Windows tools, <br> for HTML—your X++ code becomes predictable, your files open cleanly everywhere, and your users get legible output every time.