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=79799 --- shadow/79799 2007-01-20 22:41:01.000000000 -0500 +++ shadow/79799.tmp.8976 2007-01-20 22:51:57.000000000 -0500 @@ -72,6 +72,30 @@ already aware of that) ------- Additional Comments From [EMAIL PROTECTED] 2007-01-20 22:41 ------- Created an attachment (id=18531) NUnit Tests of TextBox + +------- Additional Comments From [EMAIL PROTECTED] 2007-01-20 22:51 ------- +I attached a few more NUnit tests of textbox. They demonstate... + +1. Windows retains CR and LF when contained in appended text. Mono +drops CR unless followed by LF, in which case it adds an extra CR. + +2. Commentint out the first failure, it appears that Windows +recognizes CR, LF or CRLF as delimiting a new line and returns +multiple lines even if Multiline is false. Mono does the same thing +except when only a CR is used. In that case it returns a single line +and the CRs disappear. + +I tested this using .NET 1.1 on Windows and Mono 1.2.2 with the 1/13 +recharge applied. Based on what Windows does, it seems that the +existing mono behavior with respect to multiline being false is OK but +the treatment of CR is wrong. + +I'm using the 1.0 profile for most of my work, but I did notice that +the behavior was more consistent with Windows when using the 2.0 profile. + +My experience with windows controls is that CR is almost always +significant, LF sometimes, depending on the control. It's definitely a +different issue from the treatment of line end in files. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
