My project refuses working properly on a faster pc

[potato]

then how come this doesn't keep printing?

Code:

cl = 0
DO
DO: move$ = INKEY$: LOOP UNTIL move$ <> ""
  cl = cl + 1
  COLOR cl
  PRINT move$
  IF cl = 15 THEN cl = 1
LOOP UNTIL move$ = CHR$(13)

[/code]

[Sterling Christensen]

Code:

DO: move$ = INKEY$: LOOP UNTIL move$ <> ""

Because this line does not allow keystrokes to accumulate in the buffer. As soon as one arrives it's taken out of the buffer.

Look, here's how it works:
(user presses A)
"Tell program that the user pressed A" is put in sort of a TO-DO list.
(user presses X)
Like before: "Tell program that the user pressed X" is added to the same TO-DO list.
(program uses INKEY$)
A is removed from the TO-DO list, and INKEY$ gives the program "A"
(program uses INKEY$ again)
X is removed from the TO-DO list, and INKEY$ gives the program "X" - the TO-DO list is now empty
(program uses INKEY$ again)
the TO_DO list is empty (no more keystrokes to report), so INKEY$ returns ""

It's called a queue. Anyway, by doing "move$ = INKEY$" over and over again, you're catching and removing keystrokes from the buffer almost immediately.

Try the code I put in my previous post.

[na_th_an]

Sterling: He is using DirectQB, so I bet he is using DQBKey and not crappy INKEY$. DirectQB places a custom keyboard handler modifying the DOS interrupt vector. Many modern keyboard/mouse sets, specially with no cords or USB ones fail with those custom keyboard handlers as they are managed differently and Windows XP dos emulator just sucks. Real DOS under Win9X does recognize such modern keyboards and DirectQB works. Anyhow, in the loops keys are stored in the buffer, so if you:

Code:

<loop here>
k$=INKEY$

You won't lose the last keystroke.

[Sterling Christensen]

Anyhow, in the loops keys are stored in the buffer

I never said INKEY$ would lose the keystroke - I just finished explaining that it wouldn't! (see above - about how INKEY$ enqueues up to 15 keystrokes, etc...) Maybe you're confusing me with Potato - read our posts more carefully.

Sterling: He is using DirectQB, so I bet he is using DQBKey and not crappy INKEY$.

Yes, that's a key point in my diagnosis. Again you should actually read my posts before criticizing them.

I said that you would have trouble if you use some other method that doesn't enqueue keystrokes (such as DirectQB's) in combination with a delay loop within which no input checking is done. This is the most logical and general explanation for the trouble he is having, except for the rare special case of a wireless/USB keyboard that you mentioned.

Why do people misunderstand me all the time?

[relsoft]

Did you use DQB's "Frame" stuff? Typosoft had probs with it. ;*)

[na_th_an]

Why do people misunderstand me all the time?

Sorry, I misreaded. Anyhow, this:

Don't listen to these people - they're all wrong

Made me sound a lil harsh. My apologies

[red_Marvin]

Sterling Christensen said:
On a faster computer the program will spend the most of the time in the delay loop.
(Or something like that)

r_M says:
Then why not add a keytrap in the delay loop
*I hope not I just repeated what somebody already had said*

[Neo]

You did repeat something someone had already said...

[Spearor]

yes, relsoft idd (i found it out some days ago, but i hadn't acces to the internet so i couldn't update you guys =))
I was using DQB frame limiter, when i removed it, it worked again.

Phew, i was working on this project for some time now didn't want to give it up.

Anyway, thnx everyone.