Maybe a dumb question about Console I/O

[Stuart McLachlan]

Inkey$ is not a blocking statement.
Things can be done between keystrokes like display closest record.
Characters are validated before being displayed.

Correct. It's only blocking if you use it in a loop with no other instructions.

"INKEY$ will return immediately, even if there are no character or mouse events to retrieve."

[Michael Mattias]

Isn't that how buttons, textboxes, menu bars etc works in a standard Windows GUI application (PBWin anyone?

Yes... BUT... if you try to do too much whilst processing a Windows message, you are blocking the thread yourself.

In this case I am more interested in the "English language" description of the application requirement "non-blocking" than any code snippets. If the only reason is to validate the input... you can always do that character-by-character using INKEY$ ("CON.INKEY$.. although CON.LINE.INPUT might be more suitable (depends on what's being requested from the user).

[Mike Doty]

Michael,
Please see post #12.
Line Input is not an option since it waits for input and the enter key.
We are referring to this as blocking which may not be the correct word.

[Michael Mattias]

I DID say "depends." If the valid inputs are "STOP" and "GO" I'm certainly not going to validate character by character and CON.LINE.INPUT seems like the best choice.

Description of application is still unclear (at least to me). Maybe this application needs a mix of techniques.

We are referring to this as blocking which may not be the correct word.

I've said here before, certain words and phrases in the context of the Windows programming environment need to be carefully chosen. "Blocking" is certainly one of those words.

[Stuart McLachlan]

Michael,
Please see post #12.
Line Input is not an option since it waits for input and the enter key.
We are referring to this as blocking which may not be the correct word.

"blocking" is absolutely the correct word for the behaviour of an instruction whichih does not return (or allow any processing to continue) until some specific event occurs. In the case of Line Input - it waits for the Enter key to be pressed.

[Stuart McLachlan]

Yes... BUT... if you try to do too much whilst processing a Windows message, you are blocking the thread yourself.

Irrelevant. No one is talking about doing "too much while processing". The discussion is about the ability to perform other functions while waiting for the user to press a key.

In this case I am more interested in the "English language" description of the application requirement "non-blocking" than any code snippets.

"non-blocking" has a very clear meaning.See for example https://en.wikipedia.org/wiki/Blocking_(computing)
"A process that is blocked is one that is waiting for some event, such as a resource becoming available or the completion of an I/O operation."

If the only reason is to validate the input... you can always do that character-by-character using INKEY$ ("CON.INKEY$.. although CON.LINE.INPUT might be more suitable (depends on what's being requested from the user).

Sigh! Have you read the previous posts in the thread?

[Steve Hutchesson]

It may not happen often but I agree with Stuart in this instance, just because the original question made assumptions that were not valid, does not make it a viable assumption, to get input data requires at least some form of input processing and with a simple single thread (non multi-threaded app), it has to be done somewhere.

Multi-threading is the way to go to do it properly but depending on the input required, a polling loop with a "yield" in the loop so it does not lock the core/thread up, is probably the simplest way to do it in a single thread. The "yield" in this context would be a SleepEx() or the PB version of sleep which hands the thread back to the OS.

[Michael Mattias]

Sigh! Have you read the previous posts in the thread?

Yes. I've also been "burned" by members meaning one thing but writing something else (please note my posts on the subject of "words and phrases having a certain meaning in the context of the Windows programming environment").

Now, did you read MY posts? When you say, "The discussion is about the ability to perform other functions while waiting for the user to press a key." are you not saying what I said in post 17 this thread, " Methinks perhaps whatever is going on outside your user input needs to be running in a separate thread of execution?"

True, I often do not draw the same inferences from posts as do yourself and others. But I do read them!

[Adam J. Drake]

I believe this thread has run its course. If needed, please start another thread.