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=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 [EMAIL PROTECTED]  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 [EMAIL PROTECTED]  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).
_______________________________________________
mono-bugs maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-bugs

Reply via email to