Using %rs and get_wkey1@() in same program

I just noticed an odd behavior. I'm using a %rs call followed by a %tx call that uses get_wkey1@() to process user input.

I created a single line edit box using %rs to capture user input. I then call my ANSI emulator which uses get_wkey1@() calls to get the user keystrokes.

What I am seeing is that the keystrokes from the user field just previously entered are being 'captured' by the get_wkey1@() call. In other words, what I had previously typed is now showing up in my next created window. However, the keystrokes only show when I type something else when presented with my ANSI emulator.

It is almost as if the keyboard buffer is still being 'tapped' for inputs. A character will show up every time I type something, and what is captured is the previous input.

I found that FLUSH_WKEYBOARD@() will flush the keyboard buffer, but shouldn't the buffer already be emptied after I close the %rs window?

get_wkey1@() is an old function that predates ClearWin+. It is rarely (if ever) needed in the context of ClearWin+ where keyboard input is either handled directly or the keyboard monitor is used.

It is not surprising that there are unexpected interactions like the one that you describe. I hope that you can find a way to overcome the problem.

Thanks, Paul. Yes, FLUSH_WKEYBOARD@() does the job, so it is invoked at the start of the ANSI screen display. Which is good thing anyway; the user sometimes pokes the wrong key when transitioning between the dialogs!

Took a while to find out what was happening, but the fix was simple (once I found the proper function call), and solved the 'stray keystroke' problem that occasionally shows up in real-life.

I tried using the keyboard monitor but wasn't successful in integrating it into the calling code. I may have to revisit this now that I have more familiarity with the whole product.

Again, thanks for the information! Bill