Is it possible to do a non-blocking console read?

I would like to be able to read any and all characters that are currently in the console buffer, without knowing how many are in the buffer. If there's one character in the buffer, it should read that one character and return. If there's 100 characters in the buffer, it should read those 100 characters and return. If NO characters are in the buffer it should return immediately without reading anything. It should NEVER stop running (engage in a blocking operation) while waiting for something to read. Is it possible to do this with the console API functions?

The PeekConsoleInput function is probably what you're looking for.

Quote:

---

Originally Posted by Bonnie West

The PeekConsoleInput function is probably what you're looking for.

---

But then I have to worry about these INPUT_RECORD structures. Is there some function similar to PeekConsoleInput that ONLY checks for text characters that are currently in the buffer, and NOT check for every key-up, key-down, and mouse click event that ever was sent to the console? I JUST need to know if any TEXT CHARACTERS are in the buffer, and if there are read them out and remove them from the buffer. And if there are no text characters, return to the program's operation (no blocking) without reading any characters from the buffer. This is the behavior I'm looking for. Is there any API function I can use that will exhibit this behavior?

No reply yet my latest reply in this thread? Are you telling me that nobody, in the entire VB6 community knows how to do this without using that awful function called PeekConsoleInput?

Quote:

---

Originally Posted by Ben321

No reply yet my latest reply in this thread?

---

I don't know if you've noticed, but this API forum has a very low amount of "traffic" compared to the main forums. Therefore, the chances that the right expert on this subject will see your thread is very slim. Since you're impatient, I suggest that, next time, post your urgent threads in the VB6 and earlier forum, where many more members hang out.

Quote:

---

Originally Posted by Ben321

Are you telling me that nobody, in the entire VB6 community knows how to do this without using that awful function called PeekConsoleInput?

---

I found this working example via Google: Non-blocking read of stdin?

(and yes, it uses the "awful" PeekConsoleInput)

Here's another approach that uses SetConsoleMode() to turn line-mode off for StdIn.

Hmmm....

I didn't think you needed to, but it may make sense to call CloseHandle() on the StdIO handles on exit.

Sorry the code gets so convoluted. I tried a rewrite collapsing the ReadFile/WriteFile and their result processing into functions, but it didn't really get a lot clearer.

You still end up with a lot of extra work dealing with CR vs. CRLF and assembling pieces read into lines of text (though perhaps you don't care about that).

One issue is that true console input will have CR but no LF... but a text file redirected to StdIn will still have the LFs. So yet more special case handling code is really needed and any text file would require the "EOF Token" line at the end or else the program will hang at actual EOF.

Ugly.

Quote:

---

Originally Posted by dilettante

Sorry the code gets so convoluted. I tried a rewrite collapsing the ReadFile/WriteFile and their result processing into functions, but it didn't really get a lot clearer.

You still end up with a lot of extra work dealing with CR vs. CRLF and assembling pieces read into lines of text (though perhaps you don't care about that).

One issue is that true console input will have CR but no LF... but a text file redirected to StdIn will still have the LFs. So yet more special case handling code is really needed and any text file would require the "EOF Token" line at the end or else the program will hang at actual EOF.

Ugly.

---

What is the advantage to using ReadFile/WriteFile instead of ReadConsole/WriteConsole? I would think that using a function designed for the console would be best when working with the console.

Quote:

---

Originally Posted by Ben321

What is the advantage to using ReadFile/WriteFile instead of ReadConsole/WriteConsole?

---

Their differences are stated in High-Level Console Input and Output Functions:

Quote:

---

Originally Posted by MSDN

The ReadFile and WriteFile functions, or the ReadConsole and WriteConsole functions, enable an application to read console input and write console output as a stream of characters. ReadConsole and WriteConsole behave exactly like ReadFile and WriteFile except that they can be used either as wide-character functions (in which text arguments must use Unicode) or as ANSI functions (in which text arguments must use characters from the Windows character set). Applications that need to maintain a single set of sources to support either Unicode or the ANSI character set should use ReadConsole and WriteConsole.

ReadConsole and WriteConsole can only be used with console handles; ReadFile and WriteFile can be used with other handles (such as files or pipes). ReadConsole and WriteConsole fail if used with a standard handle that has been redirected and is no longer a console handle.

---

Quote:

---

Originally Posted by dilettante

I didn't think you needed to, but it may make sense to call CloseHandle() on the StdIO handles on exit.

---

Somebody in the Community Additions section of the GetStdHandle function's documentation thinks it may not be necessary:

Quote:

---

Originally Posted by BlueViper02

Typically, do not close the returned handle

It is not a duplicate handle, it is the real thing, so think twice before closing it :)

---

BTW, The trick has shared an undocumented .VBP section tip that enables a Standard EXE project to be compiled as a console application (or standard DLL) without requiring post-processing of the EXE or use of IDE add-ins that hook into the build process:

Code:

---

Type=Exe
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\Windows\system32\stdole2.tlb#OLE Automation
Module=Module1; Module1.bas
Startup="Sub Main"
ExeName32="ConEater.exe"
Command32=""
Name="ConEater"
HelpContextID="0"
CompatibleMode="0"
MajorVer=1
MinorVer=0
RevisionVer=0
AutoIncrementVer=0
ServerSupportFiles=0
VersionCompanyName="BVO Computing Services"
CompilationType=0
OptimizationType=0
FavorPentiumPro(tm)=0
CodeViewDebugInfo=0
NoAliasing=0
BoundsCheck=0
OverflowCheck=0
FlPointCheck=0
FDIVCheck=0
UnroundedFP=0
StartMode=0
Unattended=0
Retained=0
ThreadPerObject=0
MaxNumberOfThreads=1

[VBCompiler]
LinkSwitches=/SUBSYSTEM:CONSOLE

---

Quote:

---

Originally Posted by Bonnie West

Somebody in the Community Additions section of the GetStdHandle function's documentation thinks it may not be necessary...

---

Maybe so, but when I failed to do so the project's folder became locked so I couldn't even rename it. A reboot was needed to free it.

Quote:

---

Originally Posted by Bonnie West

The trick has shared an undocumented .VBP section tip that enables a Standard EXE project to be compiled as a console application (or standard DLL) without requiring post-processing of the EXE or use of IDE add-ins that hook into the build process...

---

That's a useful tip I keep forgetting about. I've just used add-ins that "hook" linking or post-compile EditBin/re-LINK for so long that I can always remember those.

Having all kinds of trouble today. Must be Monday!

If I'm understanding right, would using ReadFile with SetNamedPipeHandleState do the job?

This is the source code I went off of. It seems to have a timing issue, so you may not get anything right away. If you step-through the code though, it does read the console properly and non-blocking. I've used the technique in commercial software quite nicely.

http://www.planet-source-code.com/vb...61262&lngWId=1