[Mono-bugs] [Bug 81153][Nor] Changed - Regression in MDI drawing.
bugzilla-daemon at bugzilla.ximian.com
bugzilla-daemon at bugzilla.ximian.com
Tue Mar 20 11:01:58 EDT 2007
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 sebastien at ximian.com.
http://bugzilla.ximian.com/show_bug.cgi?id=81153
--- shadow/81153 2007-03-20 05:24:05.000000000 -0500
+++ shadow/81153.tmp.4244 2007-03-20 10:01:58.000000000 -0500
@@ -96,6 +96,30 @@
------- Additional Comments From rolfkvinge at ya.com 2007-03-20 05:24 -------
Chris, I don't think we can track the Graphics on the SWF side, since
the application can call Graphics.FromHwnd(Control.Handle) directly
and then we're lost.
+
+------- Additional Comments From sebastien at ximian.com 2007-03-20 10:01 -------
+I don't like keeping a list a Graphics instances. It *may* fixes some
+problem if we're having a finalizer execution ordering problem but the
+issue can be duplicated (without MONO_XSYNC) outside this case.
+
+I can also duplicate the issue (at least the X errors) by doing
+
+ Graphics g = Graphics.FromHwnd (FileButton.Handle);
+ FileButton.Dispose ();
+ g.DrawLine (Pens.Red, 0, 0, 10, 10);
+ g.Dispose ();
+
+inside Paint. Of course this would fail too (but differently,
+ExternalException) under MS runtime, but Mono's
+ObjectDisposedException can only be throw if the managed code is aware
+that the X handle is freed/invalid.
+
+This also explains why moving the Dispose of the Graphics instances
+earlier "hides" the problem (the X handle is still valid at that time,
+but not later).
+
+Note: running this sample under valgrind didn't report anything useful
+(well it's useful to know it's not a memory corruption).
More information about the mono-bugs
mailing list