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=80466 --- shadow/80466 2007-01-05 23:37:57.000000000 -0500 +++ shadow/80466.tmp.2636 2007-01-06 05:03:25.000000000 -0500 @@ -2,13 +2,13 @@ Product: Mono: Class Libraries Version: 1.2 OS: All OS Details: Status: NEW Resolution: -Severity: +Severity: Unknown Priority: Normal Component: Windows.Forms AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] TargetMilestone: --- @@ -26,6 +26,25 @@ l.Height = Height; if (l.Height != Height) throw new Exception(); } } } + +------- Additional Comments From [EMAIL PROTECTED] 2007-01-06 05:03 ------- +The height seems to be changed in ListBox.SetBoundsCore. +The valued reported by Height is generally expected to do what it +does on .NET framework (return the value that was set), like in bug +80394. On the other hand, rendering is supposed to use the adjusted +height in order not to display partial items. Furthermore, the real +height of the control seems to be the adjusted one (GetChildAtPoint +could be used to verify this). +Here is an idea. Since on Microsoft .NET Framework the layout is done +in managed code, but the rendering for ListBox is done in native +code, there are probably two heights: one cached as a private +variable in the class library (used for layout), and another on in +native code, used for rendering. +MWF could do the same. Control could have another variable that +stores the equivalent of the native size, which would be passed to +XplatUI.SetWindowPos. It could be set to the normal size in +SetBoundsCore, and controls that change it should use it for +rendering. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
