INPUT$() issue: possible bug?

[Mark0]

I found that the INPUT$() function work strangely, or different than used to work in QBX.

Here's a snippet to try:

Code: Select all

Do
    Print "Input: "
    A$ = Input$(1)
    Print "[" + A$ + "]"
Loop

Typing the keys A, B, C and pressing [ENTER], QBX show this:

Code: Select all

Input:
[A]
Input:
[B]
Input:
[C]
Input:
[
]
Input:

While with FreeBASIC 0.14 I obtain this:

Code: Select all

Input:
ABC        <<-----
[A]
Input:
[B]
Input:
[C]
Input:
[
]
Input:

FB show the 3 alpha keys while they were being pressed, and return the control to the next statement only after pressing [ENTER].

I'm sorry if this is already knowed / worked on.

Bye!

[SotSvart]

Seems like another qb quirk:
INPUT$(n[,[#]filenumber])
* n, a numeric expression, is the number of characters to read from
the file
* If the optional filenumber argument is not used, characters are read
from the DOS standard input device (see Details)
* If used, filenumber must be the number of an open file

[DrV]

SotSvart, that functionality is already implemented, but the question Mark0 has is whether or not the characters should be echoed to the screen... If they aren't in QB, I guess they shouldn't be in FB.

[Mark0]

Yes, one strange thing is that the keys are echoed on the screen.
Also INPUT$(1) in QBX wait for one key/char and return it, while in the sample I posted above it doesn't seem to do this.

Bye!

[SotSvart]

Ok, I did'nt know you could use Input$ like that. Tested the code with QB4.5 and it had the same behavior as with QBX

[mjs]

This is a known issue and fixed in my local copy. I'll update the repository in the next few days.

Regards,
Mark

[Mark0]

Thanks!

Bye!