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=80756 --- shadow/80756 2007-02-07 21:07:17.000000000 -0500 +++ shadow/80756.tmp.4041 2007-02-07 21:07:17.000000000 -0500 @@ -0,0 +1,76 @@ +Bug#: 80756 +Product: Mono: Class Libraries +Version: unspecified +OS: +OS Details: +Status: NEW +Resolution: +Severity: +Priority: Normal +Component: Sys.Drawing. +AssignedTo: [EMAIL PROTECTED] +ReportedBy: [EMAIL PROTECTED] +QAContact: [EMAIL PROTECTED] +TargetMilestone: --- +URL: +Cc: +Summary: Crash in System.Drawing.Graphics.ClipBounds + +Please fill in this template when reporting a bug, unless you know what you +are doing. +Description of Problem: +I finally reproduced that bug and figured out the reason for it. + +Steps to reproduce the problem: +1. Create a custom class inheriting PrintDocument. +2. Override OnPrintPage and get the ClipBounds property from the passed +graphics object +3. Create a new instance of that class and assign to the PrintController +property a new instance of PreviewPrintController object. +4. Call Print() of the custom PrintDocument object. + +Actual Results: +"Path conversion requested 0 bytes (4194304 x 4194304). Maximum size is +8388608 bytes." + crash + +Expected Results: +not crash ... + +How often does this happen? +Always on my machine (I will explain below). + +Additional Information: + +The actualt reason for that bug is not that simple. +1. When PrintDocument's Print() method is called it creates a Graphics +object to pass to the virtual OnPrintPage method. +2. That object is created by the OnStartPage method of the PrintController +being used (in this case PreviewPrintController) +3. PreviewPrintController does something strange while creating the +Graphics object : +g.ScaleTransform (e.PageSettings.PrinterResolution.X / 100.0f, +e.PageSettings.PrinterResolution.Y / 100.0f); +Which creates a transformation matrix for the graphics object (on my +machine) like this: +2 0 +0 2 +0 0 + +Just for comaprison I tried the same code on MS.NET and the matrix was: +1 0 +0 1 +0 0 + +The printer used on both places is different (a fake one) but still I don't +think MS uses that matrix this way in taht case. + +4. This later on while calling get_ClipBounds() of the Graphics object the +matrix fails a check if it's empty (GdipGetClipBounds).This way +GdipTransformRegion is called and then gdip_region_convert_to_path. This +changes the clipping region object to type Path. + +5. GdipGetPathWorldBounds is called to determine the size of the region and +it becomes is calculated as very big. + +6. gdip_region_bitmap_from_path tries to allocate memory for a bitmap as +large as the region but failes. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
