Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=81159 --- shadow/81159 2007-04-18 13:17:03.000000000 -0400 +++ shadow/81159.tmp.25091 2007-04-18 13:58:39.000000000 -0400 @@ -99,6 +99,35 @@ Created an attachment (id=19083) 81159.patch ------- Additional Comments From [EMAIL PROTECTED] 2007-04-18 13:17 ------- does this patch resolve the issue? + +------- Additional Comments From [EMAIL PROTECTED] 2007-04-18 13:58 ------- +No, it doesn't: + +I still get the same behavior on the 1.0 profile. The behavior of +the 2.0 profile did change but does not match MS. + +With your patch, only the first 16 characters are echoed back during +the first read (while they are all echoed on MS). + +Then, after hitting the enter key the characters that were entered +after these 16 characters are echoed at the location where the +second read is performed. On MS only the keys that were entered +after the second read are echoed there, but the returned line does +include the characters that were echoed but not read during the +first read. + +Also, on Mono the second read immediately finishes while on MS it +wait until the user presses enter. + +Note: pressing enter on Windows (atleast on MS) causes CR+LF (13 10) +to be written to the console, so checking for \n will not work. I +think you should use Environment.NewLine (and cope with the fact +that I has only one character on Linux and 2 on Windows). + +I also noticed that on Mono 2.0 profile the backspace is also +counted as a character while this works fine on the 1.0 profile. But +I'll probably submit a separate bug report for that once this one's +fixed. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
