Using Input$(1)

[Dimster]

Just wanted to clarify using Input$, in particular Input$(1). I was thinking Input$(1) would accept 1 input from the keyboard so in this case I have a Menu with 3 choices, my code reads 

_Keyclear
Abort$=Input$(1) 
ABrt = val(Abort$)

Select Case ABrt
etc

however no matter which number from the menu I chose the Abort$ was "" and ABrt = 0. I did use _Keyclear before the Input$(1) but came up with the same result. Eventually I found the correct entry for Input$(1) was 01, or 02, or 03. Using these two digits and the program flow moved on.

Interestly, IF I used Input$(2), which would not take a single digit, if I entered 01, or 02, or 03 the program flow would NOT move on unless I pressed ENTER.

The screens I'm using are graph screens (ie 1900,900,32) and the examples in the WIKI appear to be for a text screen or Pete's screen. Not sure if that may alter Input$(1) from accepting a single digit input from the keyboard or not.

Also, I am using Input$(2) in other subroutines of the same program where the inputs are mostly 2 digits and it works fine in terms of entering a two digit number and the program flow moves onto the next task without using ENTER. But there I don't use the _Keyclear before the inputs, could it be once you establish Input$ as (2) it must remain a (2)?

[SMcNeill]

INPUT$(1) only accepts a single key input and it pauses the program until it gets it.

Code: (Select All)

Do

    _KeyClear

    a$ = Input$(1)

    a = Val(a$)

    Print a, a$

Loop Until a$ = Chr$(27)

Without your actual code to look at, is there some selection in place before the menu that you're not accounting for ?

Perhaps try a _DELAY of a small amount before that _KEYCLEAR?  Is there any chance of a keyup event or a repeat press event occurring after that _KEYCLEAR?

Hold <LEFT ARROW> for previous input
Goto menu routine
_KEYCLEAR
Release <LEFT ARROW> fractional second after the _keyclear call
INPUT$(1)  <-- get 0 for input value instantly.

With INPUT$(number), you must hit that number of keys before the input is accepted, and it will only accept that number of keys.

So foo$ = INPUT$(2) would mean 2 keypresses... 01, 02, 03 should work fine.  The fact that you have to hit ENTER after...   Makes me wonder if 0 is sticking on your keyboard or some other issue.

Can you share the problem code directly?  I'd love to see the problem and dig into this further for you.

[Dimster]

So, Steve, I have deleted a lot of the print statements that I was using to try and track down the issue.  Because I have used Input$ a lot before (while not Input$(1)) without any problems for some reason, after deleting the print statements Input$(1) has worked properly.

You know I have recently been burning the midnight oil programing and it seems I keep experiencing odd things that I'm having a devil of a time tracking down. Not sure is its a tired brain or if its just this program has become so large that there are way too many places to look in for problem solving. Maybe its both. 

Lot of football to watch now, tomorrow the plan is to slim down this program.

Thanks for looking at this issue, )))))))))))))))000000000000 my 0 key doesn't appear to be sticking.

[Pete]

Well unless there is something crazy wrong with INPUT$() I'd suspect some loop situation, similar to this is going on.

Code: (Select All)

Do

    a$ = Input$(1)

    Do

        a$ = Input$(1)

        x = Val(a$)

        Print a$, Asc(a$), x

    Loop Until Len(a$)

Loop

That first INPUT$() would be the reason why 01 works, but 1 doesn't. _KEYCLEAR will not affect the outcome.

On a side note, I always thought it would have been nice if INPUT$() monitored the keyboard and did not allow for keys held down to act the same as keys hot during a loop.

Oh, and on a final note... GO CHARGERS!!!

Pete

[SMcNeill]

@Pete sounds like it's more a print issue.  Maybe something like:


DO
    PRINT debug_info;  'somewhere up higher in the code
    'more stuff
    a$ = INPUT$(1)
    a = VAL(a$)
    PRINT a$, a
    _DISPLAY
LOOP

debug_info might be 0.  a$ might be 1.   Printing you'd have "01        1".  The 0 and 1 would be together due to the semicolon, which could be a simply typo of where you'd expect a comma to go.

The prints are gone, the issue is gone, so I'd imagine the issue was probably with the print statements somewhere.  

And I still wonder if Dimster was eating cheetos at the keyboard again.  Got a crumb stuck under the "0" so it wasn't working, and sometime overnight his cat hopped up on the keyboard and cleaned it out for him with its tongue so it works properly now on the forums.