INPUT does not assign empty string to a variable

VAR A$="Surprise!"
INPUT "Press Enter";A$
PRINT A$

If you press Enter, the program will print Surprise!.

I think this is intentional. For example:

INPUT "Set player location";X,Y

You could omit values if you don't want to change them. If you just want a single string as input, you should use LINPUT, which doesn't do this.

Yeah, I believe this was done to specify "no input" or "end of input" and allow the programmer to check. It's still a bit weird if you're not expecting it.

Yeah, I believe this was done to specify "no input" or "end of input" and allow the programmer to check.

I really don't understand what you're trying to express here. By making it impossible to distinguish between the user typing just 'Enter', and typing some value, it disallows the programmer from checking certain circumstances.

If you need to check for empty input, you could set the string to "" before the INPUT, or use LINPUT. I think the real problem here is that SmileBASIC has many undocumented features(?) because the manual isn't very good.

Mmm. In order that the programmer actually gets the user's input from INPUT, an extra step is required. Some 'feature'.

I'd have more sympathy if you posted the actual code that caused the problem.

I did.

I meant code that you were actually using, not something written as an example.

EX5BIORHYTHM

The example programs are all poorly written, so you shouldn't rely on them any more than the in game manual.

I'd have more sympathy if you posted the actual code that caused the problem.

Good thing the delivered 'sympathy' has no actual bearing on the bug report, then.

Yeah, I believe this was done to specify "no input" or "end of input" and allow the programmer to check.

I really don't understand what you're trying to express here. By making it impossible to distinguish between the user typing just 'Enter', and typing some value, it disallows the programmer from checking certain circumstances.

Oh, what I meant to articulate was, the user providing no input could be distinguished by checking against the previous input or some default, in the case of an input loop. But I realize now that it opens up some other problems, namely that you can't use the same input twice, or use the default as the first input, etc. SmileBoom decided to interpret a blank input as "cancel" and not "a blank input." I don't really get it from the perspective of strings. Blank strings exist; if you enter a blank entry, it should be an empty string, obviously. Though, how do you interpret an empty input as a number? Zero, or do we "redo from start?"

I think they made the right choice when handling empty number INPUTs (just don't change the variable) because it can be useful (like the example I gave in an earlier post). With strings this doesn't make as much sense, but handling strings differently than numbers would be strange, and INPUT already has other limitations (you can't use commas in strings), so not detecting an empty string input isn't that bad. Also, there are very few situations where you would want to INPUT strings. LINPUT is a lot better for inputting a single string, and having to input multiple strings at once is inconvenient to the user. Anyway, I don't really consider this a bug. At worst I'd call it an oversight (reusing number input code to input strings and not thinking about how empty strings are valid unlike "blank" numbers), but I'm sure that PTC worked the same way, and probably other versions of BASIC as well, so I think this is intentional. (It would be nice if they mentioned it in the manual, though.)

In summary: "The INPUT statement fails to represent the user's input in these circumstances, and the documentation has no indication of this" is a reason to call out a bug. "There are other circumstances" is not a counterargument. "It made the developer's jobs easier" is not. "I have an opinion" is not, nor is "it doesn't bother me", nor "I can't imagine it ever bothering anybody", nor "I have no sympathy", nor "there is a workaround", nor "I understand how this could happen". Perhaps you're unclear on the distinction between "It bugs me" and "It is a bug".

Perhaps I am, but you most certainly are. I think we both are. Also, what kind of "summary" is over 2/3 the length of the thing it summarizes. Oh I thought the whole thing was a summary, nevermind. The contents of the help menu are an extremely poor indicator of what is a bug and what isn't. It's *usually* safe to assume that the manual is wrong. Anyway, I think consistency is most important here, and not being able to input an empty string is a small price to pay for that.

Perhaps I am, but you most certainly are.

The distribution of such words as "I", "my", and "me" in our respective posts on this thread is objective evidence that this, too, is a poor contribution to the conversation.

Also, what kind of "summary" is over 2/3 the length of the thing it summarizes.

A bad one. Also, what kind of estimate is 'over 2/3' for about 16%? Also a bad one. Both such instances should be discouraged.

First, we should pretend that SB has good documentation, and the behavior of INPUT is well understood (so confusion isn't a problem). The manual is badly translated, and it's possible that some information was left out of the translated version. The current behavior of INPUT has these advantages: -Allows the user to leave a string unchanged -INPUTting string and number variables acts the same And this disadvantage: -Can't INPUT an empty string Whether this system is good depends on what you think is more important: the ability to input empty strings, or ability to leave a string unchanged. I don't think any amount of argument will change anyone's opinion on this, and won't change the fact that this is/isn't an intended feature. Perhaps we should ask SmileBoom...

See, your first 'advantage' does not speak to those who actually use INPUT, and have to deal with the consequences, so is of no value. The low-level details of what happens in the code are not, and should not be, the concern of the user. They are the concern of the developer. If the developer intends for user's input being negative having certain consequences, then, obviously, it is on the developer to write code after the input has been acquired to check if it is negative. If the developer intends for the user's input being blank having certain consequences, then it is on the developer to write code after the input has been acquired to check if it is blank.

You could consider the "developer" a "user" of SmileBASIC (that is what I meant). In this case, the distinction is less important, since usually the person entering data into INPUT is the same person who wrote the code. INPUT is mostly designed for debug and simple programs, and using it in a game/tool that you are releasing is a bit lazy and annoying, regardless of whether you can input an empty string.