Probably, it is normal (from FileWrite's point of view) to append yet another crlf to the end of a string each time it saves it. A simple test demonstrates such behaviour (open "some.txt" in NotePad++, play Bonham's 'Moby Dick' on "Open" and "Save" buttons and see how the trail of crlfs grows):
If my code is wrong, what's the right code? Else, what's the most elegant (resource-saving) technique to trim crlf (during or after each save)?
Insofar, my workaround is as follows:
This trims a string read from some.txt each time it is FileOpened. As a result, we always have only one extra crlf at the end of some.txt (no matter how many times the save button was fired).
Any other solutions (didn't find any on the forum yet)?
B4X:
Sub cmdOpen_Click
ErrorLabel(errFO)
FileOpen(c1,"some.txt",cRead)
a = FileReadToEnd(c1)
FileClose(c1)
Return
errFO:
Msgbox("Can't open it, dude!")
End Sub
Sub cmdSave_Click
ErrorLabel(errFS)
FileOpen(c1,"some.txt",cWrite)
FileWrite(c1,a)
FileClose(c1)
Return
errFS:
Msgbox("Can't save it, dude!")
End Sub
If my code is wrong, what's the right code? Else, what's the most elegant (resource-saving) technique to trim crlf (during or after each save)?
Insofar, my workaround is as follows:
B4X:
If StrAt(a,StrLength(a)-2)=Chr(13) Then a=SubString(a,0,StrLength(a)-2)
Any other solutions (didn't find any on the forum yet)?
Last edited: