#1✎ 1130snail_Power UserQSP Contest 1 Contest ParticipantI participated in the first SmileBASIC Source QSP Contest!HelperReceived for being very helpful around SmileBASIC SourceAchievementsAmazing ContributorSomeone thinks I'm an awesome person who has done so much for the community!AchievementsThis 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✎ 30AGAaronWhat 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✎ 270NeatNitFirst WeekJoined in the very first week of SmileBASIC SourceWebsiteExpert ProgrammerProgramming no longer gives me any trouble. Come to me for help, if you like!Programming StrengthNight PersonI like the quiet night and sleep late.Express YourselfU+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:
LF
CR
LF+CR
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
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✎ 188212Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfWell, at least we have DAT files.
Posted
#6✎ 1130snail_Power UserQSP Contest 1 Contest ParticipantI participated in the first SmileBASIC Source QSP Contest!HelperReceived for being very helpful around SmileBASIC SourceAchievementsAmazing ContributorSomeone 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_
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
#9✎ 1130snail_Power UserQSP Contest 1 Contest ParticipantI participated in the first SmileBASIC Source QSP Contest!HelperReceived for being very helpful around SmileBASIC SourceAchievementsAmazing ContributorSomeone 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.
#10✎ 477SquareFingersIf 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✎ 188212Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfIt doesn't happen with strings.
Posted
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✎ 1130snail_Power UserQSP Contest 1 Contest ParticipantI participated in the first SmileBASIC Source QSP Contest!HelperReceived for being very helpful around SmileBASIC SourceAchievementsAmazing ContributorSomeone 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✎ 41DasEtwasSo you really can print a CR arrow as a plain character? wow xD
ok ;3
Posted
Edited
by DasEtwas
#15✎ 1130snail_Power UserQSP Contest 1 Contest ParticipantI participated in the first SmileBASIC Source QSP Contest!HelperReceived for being very helpful around SmileBASIC SourceAchievementsAmazing ContributorSomeone thinks I'm an awesome person who has done so much for the community!AchievementsPRINT CHR$(13) yeah
Posted
#16✎ 246AveryFirst WeekJoined in the very first week of SmileBASIC SourceWebsiteThird YearMy account is over 3 years oldWebsiteDisguisedHiddenWebsiteWell crud. I was making a file type that saves as TXT and holds integers as characters.
Posted
#17✎ 188212Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfMake 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
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✎ 477SquareFingersThis 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✎ 188212Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI 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
