[Solved] Linux BlitzMax text lines have ^M

BlitzMax Forums/MaxGUI Module/[Solved] Linux BlitzMax text lines have ^M

Vanessa(Posted 2015) [#1]
I'm not quite sure why, but whenever I add a LFCR at the end of a line in a text area on Linux, it adds a ^M to the end. Is there a way to start a new line without the ^M?

SetGadgetText(Label,GadgetText(Label)+Chr(13)+Chr(10)+inf$)


Screenshot:



Vanessa(Posted 2015) [#2]
Of note, this doesn't happen when the same program is compiled and run under Windows. It's only happening on Linux. I assume I'm just missing something obvious, but I can't for the life of me figure it out.


RustyKristi(Posted 2015) [#3]
Windows-based text editors put special characters at the end of lines to denote a line return or newline. Normally harmless, some applications on a Linux server cannot understand these characters and can cause the service to not respond correctly. This can result in unforeseen complications. This is because the file is created or perhaps even edited on a machine running Windows and then uploaded to a Linux server.


Source: https://www.novell.com/support/kb/doc.php?id=7014821

Is this related to your problem? If you did edit that code using the linux MaxIDE version by that screenshot then something is definitely wrong.. Try saving it on a different editor like vi or nano and see if you still have that issue.


xlsior(Posted 2015) [#4]
^M = CR = CHR$(13)

Have you tried to use just the LF (CHR$(10)) and see what happens?


RustyKristi(Posted 2015) [#5]
Ah yes as xlsior pointed out, you're using Windows CRLF that's why :)


Matty(Posted 2015) [#6]
some linux boxes have a command 'dos2unix' which should fix this.....


Brucey(Posted 2015) [#7]
some linux boxes have a command 'dos2unix' which should fix this.....

Probably more of an issue with the FLTK MaxGUI than anything else.


TomToad(Posted 2015) [#8]
wouldn't it be better to use
SetGadgetText(Label,GadgetText(Label)+"~n"+inf$)
instead?

I believe that ~n will translate to the proper "next line" sequence for the platform you are using.


Vanessa(Posted 2015) [#9]
That worked! Awesome!

Changed the code to:
?Win32
	SetGadgetText(Label,GadgetText(Label)+Chr(13)+Chr(10)+inf$)
?
?Linux
	SetGadgetText(Label,GadgetText(Label)+"~n"+inf$)
?

and now it's working!


TomToad(Posted 2015) [#10]
I would have sworn that ~n would've put the platform specific EOL, 13-10 on windows and just 10 on Linux, but testing shows that it only places 10 on both. However, MaxGUI behaves properly on windows with both methods so the ?Win32 and ?Linux directives are not needed. Just using the Linux EOL will work on both. The 13-10 pair would only matter if you are writing to a file and opening on another program.

If you do need both for any reason, then you can use "~r~n" instead of Chr(13)+Chr(10) and save yourself some typing.

Also, in the home tab on the IDE, under Help/Language/Literals, there is a list of other escape sequences available.


skidracer(Posted 2015) [#11]
It would be tidier if you just use ~n on all platforms.

Or better still ~n~n for word wrapped views where a separating blank line is the norm between text blocks.

CHR(n) | ASCII name | BlitzMax shorcut

10 | LF | ~n
13 | CR | ~r

Also, the combination of CR LF is not only Windows, HTTP 1.0 and 2.0 both use it as line endings in their protocols.

MaxGUI ignores 13 so yes, the FLTK driver is at fault here and this issue is not really [SOLVED] IMHO.