The program only wants to run once . . .

[Pete]

I'd recommend changing _DELAY 2 to SLEEP 2. SLEEP should correctly pick up the key buffer input. Well, I actually recommend doing the whole routine in a proper loop fashion and setting a timer, as someone else, of mediocre significance, had previously mentioned.

Pete

[Jack]

the following code as suggested by Steve works most of the time but every now and then it simply prints -13

Code: (Select All)

Option _Explicit



Dim As Integer k

Dim As Double t

Print "Press a key"



t = Timer + 3.0 '<-- 2 seconds

Do

    k = _KeyHit

Loop Until k Or (Timer > t)

Print k

---

Pete
sleep doesn't work, it doesn't catch the key

[Pete]

@Jack

Good to know. SLEEP does work with INKEY$, but it has to be before the INKEY$ statement. _KEYHIT will not return a key value after either _DELAY or SLEEP.

Code: (Select All)

Print "Press a key within 2-seconds...": Print

Sleep 2 ' Allows for the key to be trapped.

b$ = InKey$

_Delay 1

Print

Print "Press a key within 2-seconds again...": Print

_Delay 2 ' _Dealy or Sleep with _KEYHIT does not return a value.

a = _KeyHit

Print "INKEY$: b$ = "; b$

Print "_KEYHIT: a = "; a$

Print

Print "Press Esc to quit"

Do: _Limit 10: Loop Until InKey$ = Chr$(27)

System

Of course putting a SLEEP statement in has its advantages/disadvantages with a timing condition, as SLEEP (anything) is disengaged the moment a key is pressed, unlike _DELAY, which waits the full coded time before proceeding.

There are just a couple of instances that I would prefer using _KEYHIT and Since I don't use SLEEP in my programs, that would never be an issue. For me it's a familiarity issue. Coding with INKEY$ is super fast, almost completely intuitive. With _KEYHIT I have to keep guessing what the hell key it is when reading the code.

Pete

- I think the Dems are trying to scare us, first with Biden now with Harris.

[DSMan195276]

Again:
I start the program, press the space bar, and it is displayed correctly. I start the program again, press the space bar again, and it displays "unknown". The same thing happens with "ESC".
After deleting the exe file, it works again, but only once. Then the game repeats itself. I just tried it again.

I might have an idea, do you start the program by hitting F5? If you hold the F5 key too long then the release event of F5 will go to the newly started program, that would trigger the behavior you're describing since the F5 release will be returned by _KeyHit first before the spacebar.

@Jack do you start the program by hitting the enter key on the 'Start' menu entry? -13 is an Enter key release event.

[RhoSigma]

I might have an idea, do you start the program by hitting F5? If you hold the F5 key too long then the release event of F5 will go to the newly started program, that would trigger the behavior you're describing since the F5 release will be returned by _KeyHit first before the spacebar.

That can't be the case as Steve added a release wait loop in PR #399 to avoid the program is started before F5 is released. That was back in v3.10.0, no idea what version KP is using though.

[Kernelpanic]

It's the F5 key! I only press the key briefly, but here it has to happen in a flash. Yes, then it works. Is there any way to change this behavior?

@RhoSigma, I always use the latest version.

[Jack]

@DSMan195276
I made the executable by pressing F11 and then opened a command window and execute the program, after the first run I used the up-arrow to show the history and then press return key

[SMcNeill]

I might have an idea, do you start the program by hitting F5? If you hold the F5 key too long then the release event of F5 will go to the newly started program, that would trigger the behavior you're describing since the F5 release will be returned by _KeyHit first before the spacebar.

That can't be the case as Steve added a release wait loop in PR #399 to avoid the program is started before F5 is released. That was back in v3.10.0, no idea what version KP is using though.

This would only trap if someone was starting the program via the IDE.  If you're starting it from the compiled EXE, then you could still carry over keypresses and such, if your keyboard has the proper repeat rates and such, and you hold whatever key you use to start it too long at start up.

The best way I know to try and avoid stray junk from previous input messing up current input, is to place a _KEYCLEAR statement in the program before you go to fetch the new buffer, such as perhaps:

Code: (Select All)

Dim As Integer x

Print "Taste"
_KEYCLEAR 'clear the old keyboard buffer of any junk in it at this point
_Delay 2 'pause the program so the user now has two seconds at this point to press a key

x = _KeyHit
If x = 32 Then
  Print "Leertaste "; x
ElseIf x = 27 Then
  Print "Esc-Taste "; x
Else
  Print "Unbekannt"; x 'go ahead and print x here to see what key it did catch.  0 if none, otherwise see what actually got picked up
End If

[DSMan195276]

That can't be the case as Steve added a release wait loop in PR #399 to avoid the program is started before F5 is released. That was back in v3.10.0, no idea what version KP is using though.

Looking at it now, are we sure Steve's code works as intended? The code is this:

Code: (Select All)

                _KeyClear

                Do: _Limit 15: Loop Until _KeyHit = 0 'wait for user to remove finger from F5 key before running

This isn't waiting for an F5 key release, it's just waiting for _KeyHit to return zero. That can happen while the F5 key is still held since _KeyHit only reports the press event once and then zero afterward (it will eventually start reporting the repeat key events but there's a delay before that happens).

It's interesting because it does still fix the original issue, F5 does not spam out copies of your program anymore. I wonder if the forced _Limit 15 is what actually fixes it, once the new program finishes starting up it gains focus and keypresses stop going to the IDE (at least on my computer), so maybe the _Limit 15 is really just acting as a short wait for the program to start.

[Kernelpanic]

SMcNeill -The best way I know to try and avoid stray junk from previous input messing up current input, is to place a _KEYCLEAR statement in the program before you go to fetch the new buffer, such as perhaps:

I just tried using _KEYCLEAR, but unfortunately there was no change; at least not for me. The F5 key has to be pressed like a lightning strike. 

Normally I have no problem pressing the F5 key. So far there have only been two problems with it: now and about a year ago. I had forgotten about it.