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=82642 --- shadow/82642 2007-08-31 16:01:27.000000000 -0400 +++ shadow/82642.tmp.4410 2007-08-31 16:57:17.000000000 -0400 @@ -27,6 +27,51 @@ for bug #81570). ------- Additional Comments From [EMAIL PROTECTED] 2007-08-30 17:17 ------- Created an attachment (id=19933) Repro + +------- Additional Comments From [EMAIL PROTECTED] 2007-08-31 16:57 ------- +When running the repro I noticed that the last row has the text from +the second column render over the one from the first. Here is a +simpler test: + +using System; +using System.Windows.Forms; +static class Test +{ + static void Main () + { + Application.Run (new TestForm ()); + } +} + +class TestForm : Form +{ + ListView list_view = new ListView (); + public TestForm () + { + list_view.Dock = DockStyle.Fill; + list_view.View = View.Details; + Controls.Add (list_view); + } + protected override void OnLoad (EventArgs e) + { + base.OnLoad (e); + list_view.Columns.Add ("1"); + list_view.Columns.Add ("2"); + + list_view.Items.Add ("1").SubItems.Add ("2"); + list_view.Items.Add ("3").SubItems.Add ("4"); + } +} + +The "4" subitem is painted in the wrong place because its bounds are +not computed. It seems to me that this is currently done in +ListViewItem.Layout. The problem is that Layout does not get called +for the second item after its subitem has been added. A solution to +this would be either to compute the subitem bounds before painting or +compute them when anything that can affect them is changed. The +following patch shows how the second option could work. Of course, +many of the ListViewSubItemCollection members will need calls to +Layout. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
