Dave Sexton said:
Hi Dan,
I'm still not sure what you mean by "convert the data" or why
ConsoleKey.Enter is required at all. Obviously if {13, 10} indicates a
new line in the stream then ConsoleKey.Enter will not be useful to you
since its value is only 13.
You don't need a parser either. Just read the stream one character at a
time, examining each character along the way. If the current character is
13 then consume the next character immediately and check if it's 10. If
so, process accordingly.
I remember the good ole days of dial-up BBS's and BBS door games...<sigh> I
miss them. Then the internet boom and the ability to telnet w/o 'dialing
into' the mud...w00t nowadays, it's World of Warcraft, Dark Age of Camelot,
Final Fantasy, and all those MMORPG's....but in any case, they all do what
you are trying to do...parse user input from a remote terminal and execute
chunks of code on the server... (and yeah, there are more than just games
that do this, but hey, I'm a programmer and gamer and still 26 years young!)
Like Dave mentioned, you can read the stream one char at a time and
determine when the user sends \r\n. Remember, as well, the user can send
'\r' + '\n' w/o pressing the enter key (depending on input methods you
provide, the user can send the values via alt-numeric pad key-combinations).
What we did in the old text-based MUD game days was reading a stream of data
from the client until we found the \r. Once found, it would process the
first 'word' of the input as a 'command' and everything else following as a
parameter. So, to make this into a point, you are going to be 'parsing' or
'converting the data' regardless of how you do it...by comparing input
against ConsoleKey.Enter, you are still converting into a format to compare
against an enumeration....
Not sure it helped much, just thought I'd bring back some old memories...
Mythran