Socket question

[Kenneth Brody]

Quoting Jay R. Ashworth (Fri, 11 Aug 2006 13:43:40 -0400):

> On Wed, Aug 09, 2006 at 06:49:26PM -0400, Kenneth Brody wrote:
> > Early testing showed that, if filePro were to use stdio (actually,
> > STD_INPUT_HANDLE and STD_OUTPUT_HANDLE), and you were to redirect
> > stdout to a file, nothing would show up on the screen, and nothing
> > would show up in the file, either.  Also, redirecting stdin from a
> > file would not cause filePro to read the file for input.  This is
> > because the Windows console API doesn't act like file I/O.
>
> Just the latest in a *series* of excellent reasons not to use it.
>
> (The Windows Console API, or Windows itself; take your pick.)

And reading with the console API is another headache entirely.

First, there's the nice-sounding "ReadConsole()", which reads
input from the console, and AFAIK handles redirected input.
However, it only reads the standard keys.  It will not read
F-keys, arrows, or even the ESC key.

Very well then, what about the lower-level "ReadConsoleInput()"
function instead?  This reads all console input, and can even
read mouse events as well.

Unfortunately, there are problem with this function.  For example,
if you toggle CapsLock on, then this function acts as if the shift
key were pressed, even for non-alpha keys.  For example, if you
press "1", you'll get "!".  It also doesn't support Alt+NNN to
enter keystrokes.

So, filePro has to use a combination of PeekConsoleInput() to see
if ReadConsole() can handle the input or not, and then call the
appropriate ReadConsole/ReadConsoleInput function as needed, plus
keeping track of any Alt+NNN state itself.  (It was either that,
or program filePro with knowledge of scancodes, including the
ability to add scancodes in the future, and handle the raw I/O
itself.)

Finally, there is an apparent bug in ReadConsole(), as noted in
my comments:

    /* kjb - 9/25/2001 - #499 - Workaround for bug in Windows.
     *  Sometimes, PeekConsoleInput() returns one value, but
     *  ReadConsole() returns the previous keystroke, and then
     *  returns the correct keystroke.  This appears to only
     *  happen occasionally, and only when the previous key
     *  was a space.  This causes the occasional double-space.
     */


--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com