[Mono-dev] Patches for mono-winforms

Stifu stifu at free.fr
Tue Jun 5 05:49:34 UTC 2012

About backporting to Mono 2.10, I'm not sure it's worth it. These bugs are
not critical, and besides, the 2.10 branch is at the end of its life (to the
point I'm not sure it'll see a new release, but I don't know for sure).

"And what differences did you notice?  I'll at least put them on my list of
things to consider."

If you run the tests as a Windows app rather than with NUnit, then tests
1-14 and 1-15 fail with .NET.
With Mono, 1-15 and 2-14 (I think? From memory) failed before applying your
patch. After your patch, nothing fails when running the tests this way. This
shows we do not do the exact same thing as .NET, or least not at the same
time / in the same location. If you're interested in these oddities, I can
attach my solution for this, so you don't have to remake it yourself.

Steven Boswell II wrote
> Thank you!
> Is there any chance of getting my previous two bug fixes pushed into the
> 2.10 release branch?
> I figure that's the fastest way to get them into the versions found in yum
> repositories.
> And what differences did you notice?  I'll at least put them on my list of
> things to consider.
> I just tried to run your DgwTest project, both with latest mono, and with
> my patched 2.10.5 installation, under Fedora Core 16.  I compiled it with
> 2.10.5, and it ran fine with both versions of mono.  I then compiled it
> with latest mono, and it ran fine with latest mono.  So I don't know what
> to tell you.
> BTW, enclosed is an updated version of patch 2.  I noticed the problem
> while debugging my own application today.
>  DataGridView.EndEdit(DataGridViewDataErrorContexts context) calls
> Focus(); there are no source-code comments to explain why, but my best
> guess is that it's to force the current editing-control to unfocus, since
> there is no explicit method to unfocus a control in WinForms.
>  Unfortunately, that's not the sort of thing you want to happen while
> processing a Leave event.  In addition,
> DataGridView.EndEdit(DataGridViewDataErrorContexts context) doesn't yet do
> anything with the passed-in DataGridViewDataErrorContexts parameter.  So
> my new patch keeps the call to EndEdit() that I added to
> DataGridView.OnLeave(), but with a parameter
> of DataGridViewDataErrorContexts.LeaveControl, and in EndEdit(), I guard
> the call to Focus() with "if (context !=
> DataGridViewDataErrorContexts.LeaveControl)".  That seems a lot more
> sensible, and the problem I
>  was having with my application went away. It's still not suitable for
> check-in, what with missing a unit test and all, but I wanted to keep all
> interested parties up to date on my progress.
> Finally, in case anyone is interested, here are two more mono-winforms
> bugs I noticed today, that I'll probably try to fix at some point:
> 1) Modifying DataGridViewComboBoxColumn.Items doesn't propagate the
> changes to its cells, like it does in .NET.  Mono will propagate changes
> made to DataGridViewComboBoxCell.Items to its owning column, though.
> 2) The value of the Control.Focused property isn't consistent during an
> OnLeave event.  Under .NET, it appears to always be false.  Under Mono,
> I've seen both true and false.
> Thanks to all for putting up with me. :-)
> Steven Boswell
> ________________________________
>  From: Stifu <stifu@>
> To: mono-devel-list at .ximian 
> Sent: Monday, June 4, 2012 2:57 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
> I've just pushed patch 3
> (https://github.com/mono/mono/commit/bcb49c60cdb9e9797fa91473955fe71828805643).
> Thanks.
> By the way, I have noticed a few remaining subtle differences with .NET,
> but
> I guess we have enough on our hands as is...
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at .ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

View this message in context: http://mono.1490590.n4.nabble.com/Patches-for-mono-winforms-tp4649620p4649715.html
Sent from the Mono - Dev mailing list archive at Nabble.com.

More information about the Mono-devel-list mailing list