Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Code fix
#11
(11-06-2022, 01:42 PM)Dimster Wrote: I'm with Old Moses - that Input is one I'm not familiar with. Has it been around a long time? Is there a reason why it only deals with string values (ie Input(4) would/might be useful for non string values). I have a lot of data stored in numeric values, does Input$ automatically convert the values to strings or do they need to be stored as string values to work with Input$. It's amazing how rich QB64pe language is getting.

It's been around forever and ever and ever...  Here's where I can find the keyword all the back in GWBASIC: GWBASIC User's Manual (antonis.de)

Here's our wiki entry on it: INPUT$ - QB64 Phoenix Edition Wiki

It's definitely not a new keyword.  Smile
Reply
#12
"INPUT$(1)" maybe it's real useful.

"INPUT$(n)" where n > 1, well, watch out.

And "INPUT$(n, filenum)", I'm not even going to comment on.

That's why this is one of the statements I intensely dislike and never used. Sorry, it sucks. There have been many attempts to ditch "INKEY$" and it cannot even be used in a "serious" game project. Imagine having to use "INPUT$()" for any extensive project? Is it even employed in the BASIC portion of the QB64 source code? Probably for the "Press any key to continue" prompt LOL.
Reply
#13
It seems it's best use is in communications coding.
Reply
#14
(11-06-2022, 02:46 PM)mnrvovrfc Wrote: "INPUT$(1)" maybe it's real useful.

"INPUT$(n)" where n > 1, well, watch out.

And "INPUT$(n, filenum)", I'm not even going to comment on.

That's why this is one of the statements I intensely dislike and never used. Sorry, it sucks. There have been many attempts to ditch "INKEY$" and it cannot even be used in a "serious" game project. Imagine having to use "INPUT$()" for any extensive project? Is it even employed in the BASIC portion of the QB64 source code? Probably for the "Press any key to continue" prompt LOL.

I tend to use INPUT$ a ton.  Where I've found it especially useful is when the user needs to make a choice, and I don't need an ENTER keypress for their entry.

PRINT "Which option (from 1 to 9)?"
DO
   a$ = INPUT$(1)
LOOP UNTIL a$ > "0" and a$ <= "9"

There's no need for _LIMIT, _DELAY, or anything else with the process.  INPUT$ pauses program execution until the correct number of keypresses are entered, keeping CPU usage down and not wasting machine resources.

It's also good for passcodes, without showing the text on the screen:

PRINT "Enter your four digit passcode =>";
a$ = INPUT$(4)

As long as pausing program execution isn't an issue, I find INPUT$ to be better to use than INKEY$ any time.  Wink
Reply
#15
I can't imagine all the small code snippets examples I've posted, which I'd have to have added my custom keyboard routine to if INPUT$() did not exist. I mean folks it's great to post example code here that is small and self contained rather than snippets that are library reliant, INCLUDE file reliant, or littered with support SUBs and FUNCTIONs just so they can be demonstrated.

There are also the practical reasons Steve mentioned. The to improve the functionality of INPUT$() over the years should also be very appreciated. It is not nearly as limited as your gran pappy's INPUT$().

Pete

I'm not really old. I'm really, really old!
Reply
#16
That's a useful feature. Whether one are now asking for a number, a letter, or a word.

Code: (Select All)
Option _Explicit

Dim As String a

Print "Which option (from 1 to 9)?"
Do
  a = Input$(1)
Loop Until a > "0" And a <= "9"

If a = "7" Then
  Print: Print "They come never back!"
ElseIf a <> "7" Then
  Beep: Print: Print "Go down!"
End If

End
Reply




Users browsing this thread: 3 Guest(s)