? Welp. CHR 13 becomes CHR 10 in files. (Page 1) ● SmileBASIC Source Forums

Sign In

Register
*Usernames are case-sensitive
Forgot my password
This website has been moved, please see this post

Welp. CHR 13 becomes CHR 10 in files.

1 2 3
  • #1 ✎ 1130 snail_ Power User QSP Contest 1 Contest Participant I participated in the first SmileBASIC Source QSP Contest! Helper Received for being very helpful around SmileBASIC Source Achievements Amazing Contributor Someone thinks I'm an awesome person who has done so much for the community! Achievements This is self-explanatory, and just plain dumb. When saving a TXT or PRG, all occurrences of CHR 13 become CHR 10. Why make this a feature? Just, why? Now if I have a 13-character entry in a save file, I have to pad it. I shouldn't have to bow to such dumb design choices. Ugh. Take this as a warning, everyone who wants to do thorough processing of TXT files. Posted
  • #2 ✎ 30 AGAaron What is CHR 13 or 10? Do they equate to some kind of character code? If so, what characters? Do you have any suspicion as to why they made this design decision? Posted
  • #3 ✎ 270 NeatNit First Week Joined in the very first week of SmileBASIC Source Website Expert Programmer Programming no longer gives me any trouble. Come to me for help, if you like! Programming Strength Night Person I like the quiet night and sleep late. Express Yourself U+000A = character 10 = Line Feed. U+000D = character 13 = Carriage Return. These both mean "line break", and they exist because historically - in typewriters - these were two separate actions that needed to be performed in order to start a new line. In computers, this no longer applies, but we still have those two characters. Because of this, different operating systems (and indeed, different software inside each OS) may use different combinations of these characters. There are 4 possibilities:
    1. LF
    2. CR
    3. LF+CR
    4. CR+LF
    You can read about it here: https://en.wikipedia.org/wiki/Newline It seems that SmileBASIC uses just a single LF (character 10), and decides quite rudely that any occurrences of CR should be replaced with LF. As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.
    Posted Edited by NeatNit
  • #4 ✎ 477 SquareFingers
    As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.
    Only if you load the text data into a program slot (intended for holding programs). Text data stored in a string variable (intended for holding text data) is fine.
    Posted
  • #5 ✎ 1882 12Me21 Syntax Highlighter Received for creating the code syntax highlighter on SBS Night Person I like the quiet night and sleep late. Express Yourself Well, at least we have DAT files. Posted
  • #6 ✎ 1130 snail_ Power User QSP Contest 1 Contest Participant I participated in the first SmileBASIC Source QSP Contest! Helper Received for being very helpful around SmileBASIC Source Achievements Amazing Contributor Someone thinks I'm an awesome person who has done so much for the community! Achievements
    As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.
    Only if you load the text data into a program slot (intended for holding programs). Text data stored in a string variable (intended for holding text data) is fine.
    Nope. SAVE "TXT:TESTSTRING",CHR$(13) S$=LOAD("TXT:TESTSTRING",#FALSE) PRINT ASC(S$[0]) Prints out 10. On save, no text is safe. EDIT: I should point out that inserting CHR 13 into a PRG slot will in fact insert a CHR 13: one of those blue arrows. It doesn't break the line either. However, on save this character is converted to a CHR 10. The editor simply displays CHR 10s as the blue arrow character (which is another, even more confusing design choice.)
    Posted Edited by snail_
  • #7 ✎ 30 AGAaron
    As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.
    Only if you load the text data into a program slot (intended for holding programs). Text data stored in a string variable (intended for holding text data) is fine.
    Nope. SAVE "TXT:TESTSTRING",CHR$(13) S$=LOAD("TXT:TESTSTRING",#FALSE) PRINT ASC(S$[0]) Prints out 10. On save, no text is safe. EDIT: I should point out that inserting CHR 13 into a PRG slot will in fact insert a CHR 13: one of those blue arrows. It doesn't break the line either. However, on save this character is converted to a CHR 10. The editor simply displays CHR 10s as the blue arrow character (which is another, even more confusing design choice.)
    Yeah, this is definitely a strange way of handling all this. Maybe you could submit it as a bug up to SmileBOOM and explain what you're using it for?
    Posted
  • #8 ✎ 477 SquareFingers Yes, please, submit a bug report: https://miiverse.nintendo.net/posts/AYMHAAACAAADVHklSy9oJg If you don't have a Miiverse account, with your permission, I will post the bug report, crediting you for discovery - one way or another, this should get reported. Posted
  • #9 ✎ 1130 snail_ Power User QSP Contest 1 Contest Participant I participated in the first SmileBASIC Source QSP Contest! Helper Received for being very helpful around SmileBASIC Source Achievements Amazing Contributor Someone thinks I'm an awesome person who has done so much for the community! Achievements
    Yes, please, submit a bug report: https://miiverse.nintendo.net/posts/AYMHAAACAAADVHklSy9oJg If you don't have a Miiverse account, with your permission, I will post the bug report, crediting you for discovery - one way or another, this should get reported.
    Really didn't feel comfortable with calling this one a bug, but I went for it. Just another bug for the tally.
    Posted
  • #10 ✎ 477 SquareFingers If it was just when you were using program slots, I understand your hesitation. But if it happens with string variables too, that is unquestionably a bug. Posted
  • #11 ✎ 1882 12Me21 Syntax Highlighter Received for creating the code syntax highlighter on SBS Night Person I like the quiet night and sleep late. Express Yourself It doesn't happen with strings. Posted
  • #12 ✎ 477 SquareFingers
    It doesn't happen with strings.
    Did you try the code posted by slackerSnail? For me, it prints 10. Do you have repeatable code that shows CHR$(13) is not always converted to CHR$(10)?
    Posted
  • #13 ✎ 1130 snail_ Power User QSP Contest 1 Contest Participant I participated in the first SmileBASIC Source QSP Contest! Helper Received for being very helpful around SmileBASIC Source Achievements Amazing Contributor Someone thinks I'm an awesome person who has done so much for the community! Achievements
    It doesn't happen with strings.
    It happens when you save a TXT or PRG. Within the contents of the file, CHR 13 is always replaced with CHR 10. The contents of the string or PRG slot you're saving aren't immediately altered, only if you loaded said file over them.
    Posted
  • #14 ✎ 41 DasEtwas So you really can print a CR arrow as a plain character? wow xD ok ;3 Posted Edited by DasEtwas
  • #15 ✎ 1130 snail_ Power User QSP Contest 1 Contest Participant I participated in the first SmileBASIC Source QSP Contest! Helper Received for being very helpful around SmileBASIC Source Achievements Amazing Contributor Someone thinks I'm an awesome person who has done so much for the community! Achievements PRINT CHR$(13) yeah Posted
  • #16 ✎ 246 Avery First Week Joined in the very first week of SmileBASIC Source Website Third Year My account is over 3 years old Website Disguised Hidden Website Well crud. I was making a file type that saves as TXT and holds integers as characters. Posted
  • #17 ✎ 1882 12Me21 Syntax Highlighter Received for creating the code syntax highlighter on SBS Night Person I like the quiet night and sleep late. Express Yourself Make custom CHR$ and ASC functions DEF _CHR$(ASCII) IF ASCII==13 THEN RETURN "(enter symbol in the symbols menu)" ELSE RETURN CHR$(ASCII) END DEF ASC(CHARACTER$) IF ASC(CHARACTER$[0])==13 then RETURN (ascii of previously mentioned symbol) ELSE RETURN ASC(CHARACTER$[0]) END Posted
  • #18 ✎ 477 SquareFingers
    Make custom CHR$ and ASC functions DEF _CHR$(ASCII) IF ASCII==13 THEN RETURN "(enter symbol in the symbols menu)" ELSE RETURN CHR$(ASCII) END DEF ASC(CHARACTER$) IF ASC(CHARACTER$[0])==13 then RETURN (ascii of previously mentioned symbol) ELSE RETURN ASC(CHARACTER$[0]) END
    This only changes the problem of CHR$(13) being transformed into CHR$(10) into the problem of CHR$(13) being transformed into some other character.
    Posted
  • #19 ✎ 477 SquareFingers This is the solution I am using: DEF TO_SAVESTRING A$ OUT RESULT$ RESULT$="" VAR I%,B$ FOR I%=0 TO LEN(A$)-1 B$=A$[I%] IF (B$=="\") THEN B$=B$*2 ELSEIF (B$==CHR$(13)) THEN B$="\D" ENDIF PUSH RESULT$,B$ NEXT I% END DEF FROM_SAVESTRING A$ OUT RESULT$ RESULT$="" VAR I%,B$ WHILE (I%<LEN(A$)) B$=A$[I%] IF (B$=="\") THEN INC I% IF (I%<LEN(A$)) THEN B$=A$[I%] IF (B$=="D") THEN B$=CHR$(13) ENDIF ENDIF ENDIF PUSH RESULT$,B$ INC I% WEND END SAVE "TXT:TXTFILE",TO_SAVESTRING(A$) A$=FROM_SAVESTRING(LOAD("TXT:TXTFILE")) Hm. Backslash "\" appears as \. Doesn't really matter as long as it's the same character in both places. Posted Edited by SquareFingers
  • #20 ✎ 1882 12Me21 Syntax Highlighter Received for creating the code syntax highlighter on SBS Night Person I like the quiet night and sleep late. Express Yourself >This only changes the problem of CHR$(13) being transformed into CHR$(10) into the problem of CHR$(13) being transformed into some other character. Well, now there won't be 2 characters that are turned into the same character. What else do you need? You can now do encryption and other stuff without worrying about your data being corrupted. Posted
1 2 3