By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,652 Members | 1,460 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,652 IT Pros & Developers. It's quick & easy.

byte[] to enter key

P: n/a
I am receiving data from the stream of a socket. I am trying to
determine if the user pressed the Enter key. The buffer has 2 non-zero
bytes when the user presses enter: 13 and 10.

If i convert that to ASCII i get \r\n. I would like to have a value i
could compare to ConsoleKeys.Enter if possible.

Anyone know how to do that?

int bytesRead = ns.EndRead(ar);
string txt = Encoding.ASCII.GetString(recvBuffer, 0, bytesRead);
dan
Dec 21 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Hi Dan,
>I am receiving data from the stream of a socket. I am trying to determine
if the user pressed the Enter key. The buffer has 2 non-zero bytes when
the user presses enter: 13 and 10.
What does a socket have to do with the user pressing a key?
If i convert that to ASCII i get \r\n. I would like to have a value i
could compare to ConsoleKeys.Enter if possible.
This will get the value of ConsoleKey.Enter:

Console.WriteLine((int) ConsoleKey.Enter);

The result is 13, the value of \r.

Now, what exactly is your question?

<snip>

--
Dave Sexton
Dec 21 '06 #2

P: n/a
Dave Sexton wrote:
Hi Dan,
>I am receiving data from the stream of a socket. I am trying to determine
if the user pressed the Enter key. The buffer has 2 non-zero bytes when
the user presses enter: 13 and 10.

What does a socket have to do with the user pressing a key?
The user is entering data through a telnet client. The user presses "a"
and i echo an "a" to the terminal.

When the user presses Enter (or Esc or F1) i need to use that as an
indicator that an action needs to be take not just data was entered.
>
>If i convert that to ASCII i get \r\n. I would like to have a value i
could compare to ConsoleKeys.Enter if possible.

This will get the value of ConsoleKey.Enter:

Console.WriteLine((int) ConsoleKey.Enter);

The result is 13, the value of \r.

Now, what exactly is your question?

<snip>
The EndRead(...) puts data in a byte array. I would like to know how to
convert that data ({13 ,10} for Enter or {27, 79, 80} for F1 or ...) to
a value in ConsoleKeys without having to write a parser. Certainly this
has been done before.

dan
Dec 21 '06 #3

P: n/a
Hi Dan,

<snip>
>>If i convert that to ASCII i get \r\n. I would like to have a value i
could compare to ConsoleKeys.Enter if possible.

This will get the value of ConsoleKey.Enter:

Console.WriteLine((int) ConsoleKey.Enter);

The result is 13, the value of \r.

Now, what exactly is your question?

<snip>

The EndRead(...) puts data in a byte array. I would like to know how to
convert that data ({13 ,10} for Enter or {27, 79, 80} for F1 or ...) to a
value in ConsoleKeys without having to write a parser. Certainly this has
been done before.
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.

--
Dave Sexton
Dec 21 '06 #4

P: n/a


"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:ez**************@TK2MSFTNGP03.phx.gbl...
Hi Dan,

<snip>
>>>If i convert that to ASCII i get \r\n. I would like to have a value i
could compare to ConsoleKeys.Enter if possible.

This will get the value of ConsoleKey.Enter:

Console.WriteLine((int) ConsoleKey.Enter);

The result is 13, the value of \r.

Now, what exactly is your question?

<snip>

The EndRead(...) puts data in a byte array. I would like to know how to
convert that data ({13 ,10} for Enter or {27, 79, 80} for F1 or ...) to a
value in ConsoleKeys without having to write a parser. Certainly this
has been done before.

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.

--
Dave Sexton

I remember the good ole days of dial-up BBS's and BBS door games...<sighI
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...

:P

Mythran
Dec 21 '06 #5

P: n/a
Hello Dan,

if all you want to do is something really simple, then Dave's and Mythran's
answers should get you started. Remember that not all terminal applications
send both \r and \n, so you might need to live with only a single \r as the
Enter (like Dave pointed out).

PS. This is completely off-topic, but I also miss the old dial-in BBSes. See
this web page, for instance:

http://www.synchro.net/sbbslist.html

And also try "telnet vert.synchro.net". Pretty amusing in 2006. :-)

--
Regards,

Mr. Jani Järvinen
C# MVP
Helsinki, Finland
ja***@removethis.dystopia.fi
http://www.saunalahti.fi/janij/
Dec 21 '06 #6

P: n/a
Hi,

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:ez**************@TK2MSFTNGP03.phx.gbl...
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.
I also think that the OP is not very clear.
What I think he wants is to detect a NewLine sequence from a network stream.

If that is the case you need to compare with Environment.NewLine , PLEASE
NOTE that this only works if both client and server are the same platform.
Otherwise you will need to have a paired list of Platform/NewLine and be
able to detect the client platform somehow.
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.
As I mentioned above this will not work always.
--
Ignacio Machin
machin AT laceupsolutions com
Dec 21 '06 #7

P: n/a
Hi Ignacio,

That's a good point. If the OP requires support for multiple platforms then
the Environment.NewLine value should be split into an array of characters
and each character read from the stream should be compared to the new line
characters in the same order.

--
Dave Sexton

"Ignacio Machin ( .NET/ C# MVP )" <machin TA laceupsolutions.comwrote in
message news:u1**************@TK2MSFTNGP06.phx.gbl...
Hi,

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:ez**************@TK2MSFTNGP03.phx.gbl...
>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.

I also think that the OP is not very clear.
What I think he wants is to detect a NewLine sequence from a network
stream.

If that is the case you need to compare with Environment.NewLine , PLEASE
NOTE that this only works if both client and server are the same platform.
Otherwise you will need to have a paired list of Platform/NewLine and be
able to detect the client platform somehow.
>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.

As I mentioned above this will not work always.
--
Ignacio Machin
machin AT laceupsolutions com

Dec 21 '06 #8

P: n/a
Dave Sexton, 21.12.2006 23:03:
Hi Ignacio,

That's a good point. If the OP requires support for multiple platforms then
the Environment.NewLine value should be split into an array of characters
and each character read from the stream should be compared to the new line
characters in the same order.
If Dan is working on an TTY emulator, platform awareness is should be
only a matter if he treats the characters as they are - carriage return
and line feed in case of \r\n.
Else, if he's simply checking for \r (by means of platform
non-awareness) then a following \n can be ignored.

So an answer to the question could be:

int bytesRead = ns.EndRead(ar);
string txt = Encoding.ASCII.GetString(recvBuffer, 0, bytesRead);
if( test.IndexOf( (char)ConsoleKeys.Enter ) >= 0 ) {
/// ... full strike
}

Surely the best way would be a check on the buffer whether it contains
(byte)13 or (byte)10.
My two pennies.
Regards,
Mac
Dec 22 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.