This Function accepts only a numeral as input: The Challenge - very open ended,
just submit the same thing in an improved form.
Also keep in mind this was whipped up by someone who couldn't possibly be more 'math-deficient'.
FUNCTION NUMERAL
cxx = CSRLIN
cxy = POS(0)
DO
LOCATE cxx, cxy
ky$ = INKEY$
IF ky$ <> "" THEN
SELECT CASE ky$
CASE CHR$(8)
com$ = LEFT$(com$, LEN(com$) - 1)
CASE ELSE
com$ = com$ + ky$
END SELECT
END IF
PRINT "Number of digits :"; LEN(com$)
PRINT com$; CHR$(178); SPACE$(1)
LOOP UNTIL ky$ = CHR$(13)
NUMERAL = VAL(com$)
END FUNCTION
The problem with your version is that it doesn't meet the challenge of improving the original submission, but also, it accepts the minus sign repeatedly and in any position and the same goes for the decimal point. It also accepts alpha characters while the original only accepts numbers which is the point of the exercise.
Your program works very well 'as-is' but it doesn't prevent unacceptable numeric input from occuring. Please try again.
cxx = CSRLIN
cxy = POS(0)
DO
LOCATE cxx, cxy
ky$ = INKEY$
IF ky$ <> "" THEN
SELECT CASE ky$
CASE CHR$(8)
com$ = LEFT$(com$, LEN(com$) - 1)
CASE ELSE
IF ky$ >= CHR$(48) AND ky$ <= CHR$(57) THEN com$ = com$ + ky$
IF ky$ = "." AND INSTR(com$, ".") = 0 THEN com$ = com$ + ky$
IF ky$ = "-" AND LEN(com$) = 0 THEN com$ = com$ + ky$
END SELECT
END IF
PRINT "Number of digits :"; LEN(com$)
PRINT com$; CHR$(178); SPACE$(1)
LOOP UNTIL ky$ = CHR$(13)
NUMERAL = VAL(com$)
END FUNCTION
cxx = CSRLIN
cxy = POS(0)
DO
_limit 60
LOCATE cxx, cxy
ky$ = INKEY$
IF ky$ <> "" THEN
num = ASC(ky$)
SELECT CASE num
CASE 8
com$ = LEFT$(com$, LEN(com$) - 1)
CASE 48 TO 57
com$ = com$ + ky$
CASE 46
IF INSTR(com$, ".") = 0 THEN com$ = com$ + ky$
CASE 45
IF LEN(com$) = 0 THEN com$ = com$ + ky$
END SELECT
END IF
PRINT "Number of digits :"; LEN(com$)
PRINT com$; CHR$(178); SPACE$(1)
LOOP UNTIL ky$ = CHR$(13)
NUMERAL = VAL(com$)
END FUNCTION
Also, how can you have multiple conditions with select case?
cxx = CSRLIN
cxy = POS(0)
DO
_LIMIT 60
LOCATE cxx, cxy
ky$ = INKEY$
IF ky$ <> "" THEN
num = ASC(ky$)
SELECT CASE num
CASE 8
IF LEN(com$) > 0 THEN com$ = LEFT$(com$, LEN(com$) - 1)
CASE 48 TO 57
com$ = com$ + ky$
CASE 46
IF INSTR(com$, ".") = 0 THEN com$ = com$ + ky$
CASE 45
IF LEN(com$) = 0 THEN com$ = com$ + ky$
END SELECT
END IF
PRINT "Number of digits :"; LEN(com$)
PRINT com$; CHR$(178); SPACE$(1)
LOOP UNTIL ky$ = CHR$(13)
NUMERAL = VAL(com$)
END FUNCTION
It could be the reason - not familiar at all with QB64.
'Redo From Start' is an error message the user will get while running QBasic as they attempt to enter non-numeric input, when only numeric input is acceptable (ex: in a numeric variable). When this occurs, the Input fails and the user must re-enter his input from the beginning.
The idea here is to set up a simple Input Function that will only accept properly formatted numeric input, and will never need to display an error message; if the input is all-numeric only and properly formatted, it is correct and can be processed.
There are two situations in which I know it occurs for certain:
- Using INPUT with a string containing a comma
- Trying to INPUT a string when a numeric variable is used
The last case is one that QB64 eliminates by limiting the characters you can type when trying to store a numeric value.
The first case, however, is a bit more difficult. INPUT was designed to allow you to enter several items at once. For example, you could enter a name and age:
INPUT "Enter your name and age, separated by a comma: ", name$, age%
The problem arises when you do something like this:
INPUT "Enter your name (Last, First): ", name$
Ideally you would use the comma in the string to separate the names later. This limits the number of reads you would need to do. In QBasic, this was definitely an issue due to limited system resources, and string operations may have taken less time. However, if you try to enter the name in the last case:
Kitsune,Chrono
You would end up getting a "Redo from start" message because there are two items there, not one.
Ultimately, there is a rule: use LINE INPUT for strings and INPUT for numbers. And back in QBasic, you should have used LINE INPUT for numbers and parsed the string yourself actually. After all, how can you store 3.45 in an integer variable?