Re: [Mono-dev] Socket.IsBound wrong behavior

[Stifu]

Yeah, sometimes classes are in unexpected folders.
Socket isn't under System.Net, but just System, for some reason.

https://github.com/mono/mono/blob/master/mcs/class/System/System.Net.Sockets/Socket.cs


Marcelo Zabani wrote
> Hi all, I've found something strange with the Socket.IsBound property. It
> returns false on a connected TCP socket, while in Microsoft .NET it
> returns
> true. According to the docs, it seems that it should indeed return true.
> 
> Is this a known issue (I didn't find anything in the bug DB) or should I
> file a bug report? Also, where is the Socket class implemented in Mono? I
> can't find the source for it.
> 
> I'm running Mono 3.2.3 on Linux 3.8.
> Thank you,
> Marcelo.
> 
> ___
> Mono-devel-list mailing list

> Mono-devel-list@.ximian

> http://lists.ximian.com/mailman/listinfo/mono-devel-list





--
View this message in context: 
http://mono.1490590.n4.nabble.com/Socket-IsBound-wrong-behavior-tp4661296p4661298.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] why does DateTime.Now.IsDaylightSavingTime() returns false when it should be true.

[Stifu]

I'm in no position to accept or review your patch, but I wanted to thank you
for taking the time and putting in the efforts needed to make Mono better
for everyone.

I hope this pull request gets attention soon.


Alistair Bush wrote
> Hi guys,
> 
> Please note that I have cleaned this up and bit and submitted a pull
> request
> 
> https://github.com/mono/mono/pull/800
> 
> Feedback welcome.
> 
> On Wed, Oct 30, 2013 at 11:51 PM, Alistair Bush <

> alistair.bush@

> > wrote:
>> Ok so firstly this is like the MOST C ive ever written in my life..
>> and it looks ugly and ive only vagely checked that it doesn't break
>> the northern hemisphere.
>>
>> But isn't this a better patch of the method?
>> (https://github.com/alistair/mono/commit/6912202aab5a424e98bc44d7b988c2791f91)
>>
>> Any help turning this into an acceptable pull request would be really
>> appreciated.
>>
>> diff --git a/mono/metadata/icall.c b/mono/metadata/icall.c
>> index 618e4da..7f47624 100644
>> --- a/mono/metadata/icall.c
>> +++ b/mono/metadata/icall.c
>> @@ -5930,10 +5930,12 @@
>> ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
>> MonoArray
>>   struct tm start, tt;
>>   time_t t;
>>
>> - long int gmtoff;
>> - int is_daylight = 0, day;
>> + long int gmtoff, gmtoff_st, gmtoff_ds;
>> + int day, transitioned;
>>   char tzone [64];
>>
>> + gmtoff_st = gmtoff_ds = transitioned = 0;
>> +
>>   MONO_ARCH_SAVE_REGS;
>>
>>   MONO_CHECK_ARG_NULL (data);
>> @@ -5974,8 +5976,10 @@
>> ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
>> MonoArray
>>   t += 3600*24;
>>   tt = *localtime (&t);
>>
>> +long int gmtoff_after = gmt_offset(&tt, t);
>> +
>>   /* Daylight saving starts or ends here. */
>> - if (gmt_offset (&tt, t) != gmtoff) {
>> + if (gmtoff_after != gmtoff) {
>>   struct tm tt1;
>>   time_t t1;
>>
>> @@ -5995,36 +5999,37 @@
>> ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
>> MonoArray
>>   strftime (tzone, sizeof (tzone), "%Z", &tt);
>>
>>   /* Write data, if we're already in daylight saving, we're done. */
>> - if (is_daylight) {
>> - mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
>> - mono_array_set ((*data), gint64, 1, ((gint64)t1 + EPOCH_ADJUST) *
>> 1000L);
>> - return 1;
>> + if (tt.tm_isdst) {
>> + mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
>> + mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) *
>> 1000L);
>> + if (gmtoff_ds == 0) {
>> + gmtoff_st = gmtoff;
>> + gmtoff_ds = gmtoff_after;
>> + }
>> + transitioned++;
>>   } else {
>> - struct tm end;
>>   time_t te;
>> + te = mktime (&tt);
>>
>> - memset (&end, 0, sizeof (end));
>> - end.tm_year = year-1900 + 1;
>> - end.tm_mday = 1;
>> -
>> - te = mktime (&end);
>> -
>> - mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
>> - mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) *
>> 1000L);
>>   mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
>>   mono_array_set ((*data), gint64, 1, ((gint64)te + EPOCH_ADJUST) *
>> 1000L);
>> - is_daylight = 1;
>> + if (gmtoff_ds == 0) {
>> + gmtoff_st = gmtoff_after;
>> + gmtoff_ds = gmtoff;
>> + }
>> + transitioned++;
>>   }
>>
>>   /* This is only set once when we enter daylight saving. */
>> - mono_array_set ((*data), gint64, 2, (gint64)gmtoff * 1000L);
>> - mono_array_set ((*data), gint64, 3, (gint64)(gmt_offset (&tt, t) -
>> gmtoff) * 1000L);
>> -
>> + if (tt1.tm_isdst) {
>> + mono_array_set ((*data), gint64, 2, (gint64)gmtoff_st * 1000L);
>> + mono_array_set ((*data), gint64, 3, (gint64)(gmtoff_ds - gmtoff_st)
>> * 1000L);
>> + }
>>   gmtoff = gmt_offset (&tt, t);
>>   }
>>   }
>>
>> - if (!is_daylight) {
>> + if (transitioned < 2) {
>>   strftime (tzone, sizeof (tzone), "%Z", &tt);
>>   mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
>>   mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
>>
>> On Tue, Oct 29, 2013 at 9:13 AM, Alistair Bush <

> alistair.bush@

> > wrote:
>>> Well that certainly sucks.
>>>
>>>
>>> On Tue, Oct 29, 2013 at 3:03 AM, Robert Jordan <

> robertj@

> > wrote:

 On 28.10.2013 07:35, Alistair Bush wrote:
>
> I am trying to figure out why exactly running
> DateTime.Now.IsDaylightSavingTIme() returns false.
> I live in the Auckland/Pacific timezone and pretty much everywhere I
> look it confirms that yes it is daylight saving time.


 Unfortunately, I don't remember the details, but I'm pretty
 sure that ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData
 has a bug w/ respect to the Southern Hemisphere.

 The code assumes that a year always begins outside a DST zone,
 and this is obviously incorrect for the Southern Hemisphere.

 To fix this, the local var "is_daylight" must be properly
 initialized. Currently, it's always 0 at start, but it must
 be initialized with 1 when January, 1st is inside a DST
>

Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition

[Stifu]

If I'm not mistaken, the last 2 tests are redundant. You're basically doing
the same test twice.
So I guess this could be simplified to something like:

public static bool ReferenceMatchesDefinition (AssemblyName 
reference,
AssemblyName definition)
{
if (reference == null)
throw new ArgumentNullException ("reference");
if (definition == null)
throw new ArgumentNullException ("definition");
return reference.Name == definition.Name;
}


mlgo wrote
> According to
> http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.referencematchesdefinition.aspx
> 
> The following is what is expected to be returned from
> ReferenceMatchesDefinition.
>  
> Returns a value indicating whether two assembly names are the same. The
> comparison is based on the simple assembly names. 
> 
> This seems naïve but below is a tentative implementation of that. Any
> ideas?
> 
> public static bool ReferenceMatchesDefinition (AssemblyName reference,
> AssemblyName definition)
>   {
>   if (reference == null)
>   throw new ArgumentNullException ("reference");
>   if (definition == null)
>   throw new ArgumentNullException ("definition");
>   if (reference.Name != definition.Name)
>   return false;
>   
>   return reference.Name.Equals(definition.Name);
>   }





--
View this message in context: 
http://mono.1490590.n4.nabble.com/A-possible-implementation-for-AssemblyName-ReferenceMatchesDefinition-tp4660683p4660686.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] S.W.F.DataVisualization.Charting

[Stifu]

Hi,

Thanks for your work! Although I've never used WinForms charting, it's good
to see WinForms get some attention. :)

I hope someone can review this soon.


Francis Fisher wrote
> Hi,
> 
> I've recently done some work on
> System.Windows.Forms.DataVisualization.Charting. It was originally
> motivated by trying to build some OSS software called EVEMon under Mono,
> but then I went a bit deeper and I also made all of Microsoft's Charting
> code samples (http:// archive.msdn.microsoft.com/mschart?) compile on
> Mono as well - 16000 compiler errors fixed! I haven't submitted any code
> to Mono before, but I have followed the Coding Guidelines as closely as
> possible and licensed my contributions under the MIT license.
> 
> Could someone have a glance at my work and let me know if there is
> anything else I need to do to make it acceptable to Mono? The github
> pull request is https://github.com/mono/mono/pull/729
> 
> Thanks,
> Francis Fisher
> 
> ___
> Mono-devel-list mailing list

> Mono-devel-list@.ximian

> http://lists.ximian.com/mailman/listinfo/mono-devel-list





--
View this message in context: 
http://mono.1490590.n4.nabble.com/S-W-F-DataVisualization-Charting-tp4660508p4660509.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Absolute beginner

[Stifu]

Hi,

1. Up to you, you can use any .NET IDE if you're on Windows (Visual Studio,
SharpDevelop), otherwise, MonoDevelop is there for Windows, Linux and Mac.
2. Indeed. Well, just create your .NET app, then test it with Mono. I
believe there is an addon to run an app with Mono from VS (not free though,
I think), otherwise you can simply install Mono for Windows and run your app
through a command line. And test on other OSes too, as results can vary.
3. The only real way to know is by testing it. But you can check out the
class status page to see what's implemented: http://go-mono.com/status/ or
the more general http://mono-project.com/Compatibility page.
4. It's .NET code, really, so you should be able to use most .NET code that
doesn't call native code (otherwise it's a bug or unimplemented feature).
You can use MSDN as a reference.


Shashvat wrote
> Hello Everyone!
> 
> I am a COMPLETE newbie to this open-source-environment. I have a good base
> of C++ language and am interested in working in MONO because of its
> ultimate objective.
> I would appreciate if someone could help me start.  I have some very basic
> questions:
> 1. Where do we code exactly, in MONO? (sorry for such noob question)
> 2. I've read that Visual studio can be used as IDE...How do I do that?
> 3. How do I know "what" to code?
> 4. I tried going through the archives...but it's quite cluttered, or maybe
> I just too new to all this. How do I find sample code and some help
> material?
> 
> Thanks a lot!
> 
> ___
> Mono-devel-list mailing list

> Mono-devel-list@.ximian

> http://lists.ximian.com/mailman/listinfo/mono-devel-list





--
View this message in context: 
http://mono.1490590.n4.nabble.com/Absolute-beginner-tp4657909p4657910.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Rob told me off list that this test should just be removed (along with some
other patches he did, but he's not sure which ones...). That said, I could
confirm your patch (18a) fixes the test, Steven.

So, what do you think? Is there a value in keeping and fixing it, or should
I just remove it?


Stifu wrote
> 
> The OneIdlePerThread test does not seem to run on Windows, for some
> reason. It doesn't fail, but it doesn't run... Therefore, maybe it
> shouldn't pass on Linux.
> 
> 
> Steven Boswell II wrote
>> 
>> https://github.com/mono/mono/commit/38bdbad5071487a11f4330077c383375dce39840
>> 
>> 
>> This change introduced a OneIdlePerThread unit test that has never worked
>> for me.  All I get is the following exception:
>> 
>> System.InvalidOperationException : Cannot call Invoke or BeginInvoke on a
>> control until the window handle is created
>> 
>> 
>> Patch #18 fixes that by creating a Form type that calls CreateHandle() in
>> its constructor.  But now the unit test hangs hard in Mono!
>> 
>> I created a project with the unit-test, and when run in Mono, it hangs
>> hard; selecting "Run -> Pause" in MonoDevelop hangs MonoDevelop, and the
>> debugged process chews up 100% of the CPU time
>> 
>> I ran the project in .NET, and instead of a hang, I get this exception:
>> 
>> System.InvalidOperationException: Cross-threaded operation not valid:
>> Control '' accessed from a thread other than the thread it was created
>> on.
>> 
>> Patch #18a fixes that by moving the creation of form2 into the right
>> thread.  Now the unit test passes.
>> 
>> So patch #18a can be checked in, but note that patch #18 demonstrates
>> that Mono hangs in a situation where .NET throws an exception.
>> 
>> Steven Boswell
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4650627p4656315.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

The OneIdlePerThread test does not seem to run on Windows, for some reason.
It doesn't fail, but it doesn't run... Therefore, maybe it shouldn't pass on
Linux.


Steven Boswell II wrote
> 
> https://github.com/mono/mono/commit/38bdbad5071487a11f4330077c383375dce39840
> 
> 
> This change introduced a OneIdlePerThread unit test that has never worked
> for me.  All I get is the following exception:
> 
> System.InvalidOperationException : Cannot call Invoke or BeginInvoke on a
> control until the window handle is created
> 
> 
> Patch #18 fixes that by creating a Form type that calls CreateHandle() in
> its constructor.  But now the unit test hangs hard in Mono!
> 
> I created a project with the unit-test, and when run in Mono, it hangs
> hard; selecting "Run -> Pause" in MonoDevelop hangs MonoDevelop, and the
> debugged process chews up 100% of the CPU time
> 
> I ran the project in .NET, and instead of a hang, I get this exception:
> 
> System.InvalidOperationException: Cross-threaded operation not valid:
> Control '' accessed from a thread other than the thread it was created on.
> 
> Patch #18a fixes that by moving the creation of form2 into the right
> thread.  Now the unit test passes.
> 
> So patch #18a can be checked in, but note that patch #18 demonstrates that
> Mono hangs in a situation where .NET throws an exception.
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650627p4656311.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Steven, just FYI: this is either a disturbing coincidence, or someone
committed patch 10 without crediting you.

https://github.com/mono/mono/commit/427f608ef6c93f9f3f4d63c9d48f014f635ae181


Steven Boswell II wrote
> 
> Enclosed is a new patch, mostly for discussion purposes, since there's no
> unit test & I don't know how I would write one for this.
> 
> Today, after using my application in a particular way, I got it to crash,
> putting up an "Exception caught" window.  I can't reproduce the problem
> outside of running it in the MonoDevelop debugger, and there appears to be
> no way to copy the contents of the stack-trace tab in the exception-caught
> window (really? how the heck did THIS get missed?), so I can't post the
> full details.  But it starts at System.ComponentModel.Finalize() with a
> tool-strip-item (the one I selected seconds before the crash), and ends in
> System.Drawing.GDIPlus.CheckStatus(Status), where it reports "A null
> reference or invalid value was found [GDI+ status: InvalidParameter]".
> 
> I have no idea why a copy of my menu-item is getting finalized; I
> certainly didn't make a copy of it.  The good news is, this crash is
> consistently repeatable, if I just use my application in the same certain
> order.
> 
> Digging through the stack trace, I arrived at
> System.Windows.Forms.ToolStripItem.set_InternalOwner, where the owner was
> being set to null, and right afterwards, CalculateAutoSize() was being
> called.  Why would anyone need to calculate the size of a menu-item that
> isn't even connected to a menu any more?  So, for me, the bug fix was
> obvious: check if the owner isn't null before calling CalculateAutoSize().
>  That's what the enclosed patch does.
> 
> With this patch, the bug doesn't reproduce, and the menu-item I selected
> is still there and doing fine.
> 
> Any thoughts on the correctness of this bug fix?  Or how one would write a
> unit test for it?  Or how to copy the contents of the stack-trace tab in
> MonoDevelop's exception-caught window?
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4652002.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I had a look at the unit test for patch 20. The
EditingControlShowingTest_Unbound test method fails with .NET
(ArgumentOutOfRangeException). Something must be wrong with it.


Stifu wrote
> 
> Let's not take bad habits. :)
> Thanks for the test.
> 
> I did make the unit test for ermshiperete's patch, since he doesn't seem
> to be active anymore. It was that one with the Assert.Throws. :\ I just
> committed it separately, since the author was different.
> Anyway... I missed patch 19 somehow, but it doesn't come with a test
> either.
> 
> I saw patch 18a, but thought I'd leave it to the people who've been
> following / pushing Rob's patches. But if nobody's going to handle it,
> I'll do it. Eventually.
> 
> PS: patch 10 never got committed either, in case you overlooked that.
> 
> 
> Steven Boswell II wrote
>> 
>> So ermshiperete gets to check in changes with no unit tests that break
>> stuff, and I have to submit unit tests to prove I fixed those bugs?
>> 
>> I'm just jealous, is all ;-)
>> 
>> Enclosed is the desired unit test for patch #20.
>> 
>> Any thoughts on checking in patches #18a and #19?
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Steven Boswell II <ulatekh@>
>> To: "mono-devel-list@.ximian" <mono-devel-list@.ximian> 
>> Sent: Monday, August 6, 2012 6:32 PM
>> Subject: [Mono-dev] Patches for mono-winforms
>>  
>> 
>> https://github.com/mono/mono/commit/ecef298bcaf571a3d50e022318b20117f9d0388c
>> introduced another bug that I found today.  Enclosed is the fix.
>> 
>> 
>> [...]
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4650777p4650891.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Let's not take bad habits. :)
Thanks for the test.

I did make the unit test for ermshiperete's patch, since he doesn't seem to
be active anymore. It was that one with the Assert.Throws. :\ I just
committed it separately, since the author was different.
Anyway... I missed patch 19 somehow, but it doesn't come with a test either.

I saw patch 18a, but thought I'd leave it to the people who've been
following / pushing Rob's patches. But if nobody's going to handle it, I'll
do it. Eventually.

PS: patch 10 never got committed either, in case you overlooked that.


Steven Boswell II wrote
> 
> So ermshiperete gets to check in changes with no unit tests that break
> stuff, and I have to submit unit tests to prove I fixed those bugs?
> 
> I'm just jealous, is all ;-)
> 
> Enclosed is the desired unit test for patch #20.
> 
> Any thoughts on checking in patches #18a and #19?
> 
> Steven Boswell
> 
> 
> 
>  From: Steven Boswell II 
> To: "mono-devel-list@.ximian"  
> Sent: Monday, August 6, 2012 6:32 PM
> Subject: [Mono-dev] Patches for mono-winforms
>  
> 
> https://github.com/mono/mono/commit/ecef298bcaf571a3d50e022318b20117f9d0388c
> introduced another bug that I found today.  Enclosed is the fix.
> 
> 
> [...]
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650777p4650809.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Sounds good. But you can probably tell what's on my mind... Is it testable?


Steven Boswell II wrote
> 
> https://github.com/mono/mono/commit/ecef298bcaf571a3d50e022318b20117f9d0388c
> introduced another bug that I found today.  Enclosed is the fix.
> 
> 
> DataGridViewTextBoxCell was creating a single (as in static) instance
> of DataGridViewTextBoxEditingControl to do all editing.  This fails if one
> edits two text-box cells, because ending the first edit calls Dispose() on
> the static instance, and the second attempt to edit throws an
> ObjectDisposedException.
> 
> The solution is to use the control created by DataGridView, instead of
> maintaining a single static control.
> 
> Incidentally, this also fixes a bug that I hadn't yet taken the time to
> track down.
>  http://msdn.microsoft.com/en-us/library/system.windows.forms.datagridview.editingcontrolshowing.aspx mentions
> that DataGridView reuses the editing control whenever the cell type does
> not change between edits, and so any event-handlers placed on the control
> during the EditingControlShowing event should be removed.  For this to
> work, control reuse could not be across multiple instances of DataGridView
> -- the event-handlers put onto editing-controls by other DataGridView
> instances would be unknowable.  The previous static-instance code had this
> flaw; I noticed that event-handlers seemed to accumulate on text-box
> editing controls across data-grid-views when using Mono, even though I was
> following the recommended procedure, and that it wasn't happening under
> .NET and MS Windows.  But no one would have noticed this
> 
> until https://github.com/mono/mono/commit/f9bea537f1ac41753f2204b8528a6292bb547111
> (about 2 months ago), when the EditingControlShowing event was posted for
> the first time. :-)
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650777p4650792.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] 6198, Opinion? (not a fix)

[Stifu]

Although you ask, you probably already know the answer: correctness is
preferable to speed. Sure, if we can have both, that'd be great, but if we
had to choose, let's be correct.


Rob Wilkens wrote
> 
> 1) My original fix for 2663 i knew would be slower than the original
> without it because it had to do more to handle all possibilties for ors
> introduced with bug 2663's report.  For those unfamiliar -- (A|AB|ABC)
> if you tried to match that against ABC it would first match with "A"
> (which is valid) and move on without matching "AB" or "ABC" which are
> both also valid, so now we have to try all possibilities -- and all
> combinations of possibilities of matches.).
> 
> 2) The report in 6198 found a way where there were 70 or conditions
> matched which had to be tried in all various combinations to see if this
> would work.  This ran slow, very slow.  Unfortuantely, the old fast way
> just didn't work right at all, so slow and correct is probably better
> than fast and incorrect.  Still, there should be a better way.
> 
> 3) The report in 6198 appears to have code which fails to find matches
> both with and without this 2663 patch, i don't remember now - it was on
> another os install that i did the testing and don't have the code in
> front of me.  That may be another problem, but unrelated to my patch.
> 
> 4) I realize a quick fix to make this work fast would be to look at the
> source to other open source reg ex parsers and see how they do it, but i
> don't know how compatible that would be with the license that we are
> using with Mono (MIT/X11?).  i.e. taking gpl'd code and inserting it
> here might be unacceptable - which is why i did it without looking at
> other working code.
> 
> 5) If someone else wants to take a shot at this, feel free.  I made it
> work right with 2663, but if it's slow do we want right?  Is speed
> better than correctness?
> 
> I can probably come up with a better fix.  I think the list of
> JumpTestLists's we've tried could probably be sorted by something better
> than it is now by using something like a tree search (different storage
> and compare) rather than just a list of lists to manually check against
> (possibly with duplicates), that might give some speed improvements. 
> I'm not sure right now if i have the patience to do this at least not at
> 8:30am.  it's probably worth a shot, though.
> 
> I won't give up on this yet, i'd like to think i can make it faster than
> it is, please just keep 6198 open until i get a chance.  And don't apply
> any of the fixes i submitted on the mailing list, they're probably
> incorrect and were rushed without thinking through -- the original 2663
> fix was more thought out, though more focused on functionality than
> optimization.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 




--
View this message in context: 
http://mono.1490590.n4.nabble.com/6198-Opinion-not-a-fix-tp4650679p4650682.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Ah, thanks for the fix. It's in. I overlooked these regressions as I was
solely focused on the new test.
Out of curiosity, do you also see 5 remaining failing WinForms tests?


Steven Boswell II wrote
> 
> The following patch fixes the two recently-broken WinForms unit tests.
> Stifu?  You checked in ermshiperete's change without running unit tests?
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650626p4650628.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Newly broken WinForms unit tests

[Stifu]

My mistake: MenuTest used to have an Assert.Throws, but it's been changed.
https://github.com/mono/mono/commit/b827712d7615bbbc919dc4e0f6ae0697279d6477

I'll do the same to DataGridViewTest.TestDispose(), then.


Steven Boswell II wrote
> 
> My copy of Mono only has NUnit 2.4, i.e. the mcs/nunit24 directory.
> My copy of mcs/nunit24/NUnitFramework/framework/Assert.cs does not have
> any Throws() methods.
> My copy of MenuTest doesn't call Throws().
> 
> "git pull" says "Already up-to-date."
> nunit.framework.dll seems to be installed on my machine via MonoDevelop.
> In the mono source directory, all I could find
> was external/cecil//Test/libs/nunit-2.5.10/nunit.framework.dll, and that
> doesn't appear to be built from source.
> 
> Am I in an evil parallel universe again? :-)
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, July 28, 2012 3:10 PM
> Subject: Re: [Mono-dev] Newly broken WinForms unit tests
>  
> Hmm, Assert.Throws() has been introduced in NUnit 2.5. It's also used in
> MenuTest, by the way.
> Not sure what's wrong.
> 
> 
> Steven Boswell II wrote
>> 
>> Some time after 7pm MST last night, changes were checked in that broke
>> three WinForms unit tests.
>> 
>> 1) MonoTests.System.Windows.Forms.DataGridViewTestTestDispose() refers to
>> NUnit.Framework.Assert.Throws(), which used to be there, but doesn't seem
>> to be any more.  (I know that Assert.Throws() was in NUnit.Framework as
>> of
>> July 22, the last time I built an RPM package for latest Mono.)
>> 2) MonoTests.System.Windows.Forms.DataGridViewTest.SelectedColumnsTest
>> crashes in Dispose().
>> 3) MonoTests.System.Windows.Forms.DataGridViewClipboardTest.Test also
>> crashes in Dispose().
>> 
>> Could the responsible party please look into this?
>> 
>> Steven Boswell
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> 
> 
> 
> 
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Newly-broken-WinForms-unit-tests-tp4650620p4650621.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 



--
View this message in context: 
http://mono.1490590.n4.nabble.com/Newly-broken-WinForms-unit-tests-tp4650620p4650624.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Newly broken WinForms unit tests

[Stifu]

Hmm, Assert.Throws() has been introduced in NUnit 2.5. It's also used in
MenuTest, by the way.
Not sure what's wrong.


Steven Boswell II wrote
> 
> Some time after 7pm MST last night, changes were checked in that broke
> three WinForms unit tests.
> 
> 1) MonoTests.System.Windows.Forms.DataGridViewTestTestDispose() refers to
> NUnit.Framework.Assert.Throws(), which used to be there, but doesn't seem
> to be any more.  (I know that Assert.Throws() was in NUnit.Framework as of
> July 22, the last time I built an RPM package for latest Mono.)
> 2) MonoTests.System.Windows.Forms.DataGridViewTest.SelectedColumnsTest
> crashes in Dispose().
> 3) MonoTests.System.Windows.Forms.DataGridViewClipboardTest.Test also
> crashes in Dispose().
> 
> Could the responsible party please look into this?
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 



--
View this message in context: 
http://mono.1490590.n4.nabble.com/Newly-broken-WinForms-unit-tests-tp4650620p4650621.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

By the way, Steven, you might want to check out this bug, as it's related to
some of your contributions:
https://bugzilla.novell.com/show_bug.cgi?id=683213

Before your patch(es), the DataGridView SelectionChanged event wasn't fired
with the test case attached to this report. Now, it seems it's fire twice
rather than once (despite the fact I said in the bug comments that the bug
seemed fixed). If you can't think of a way to fix this, it's alright. Just
thought I'd bring that up.


Stifu wrote
> 
> It's in
> (https://github.com/mono/mono/commit/75714e424afd2ee458e1288d756c914a4df2554f),
> thanks again.
> 
> 
> Steven Boswell II wrote
>> 
>> Enclosed is the third patch for TableLayoutPanel.  Our application has a
>> table-layout with column-spanning controls, and no control started in one
>> particular column.  Mono set that column width to zero; .NET didn't.
>> 
>> I solved it by generating row/column sizes in N passes, where N is the
>> largest row/column span of any control.  Each pass only increases the
>> width/height of the rightmost/bottommost column/row.
>> 
>> This gets Mono's behavior VERY close to .NET -- the unit test allows for
>> 3 pixels of difference.  I don't know what the source of that is, but
>> it's a heck of a lot better than what the previous code did.
>> 
>> I had to include the substance of patch #2 in this one, or else three
>> other existing unit-tests failed.  I guess my two bugs fixes couldn't be
>> separated after all :-)
>> 
>> As usual, apply the unit-test patch, watch it fail, apply the patch,
>> watch it succeed, and use the project to verify behavior under .NET and
>> MS Windows.
>> 
>> Steven Boswell
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4650606p4650614.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

It's in
(https://github.com/mono/mono/commit/75714e424afd2ee458e1288d756c914a4df2554f),
thanks again.


Steven Boswell II wrote
> 
> Enclosed is the third patch for TableLayoutPanel.  Our application has a
> table-layout with column-spanning controls, and no control started in one
> particular column.  Mono set that column width to zero; .NET didn't.
> 
> I solved it by generating row/column sizes in N passes, where N is the
> largest row/column span of any control.  Each pass only increases the
> width/height of the rightmost/bottommost column/row.
> 
> This gets Mono's behavior VERY close to .NET -- the unit test allows for 3
> pixels of difference.  I don't know what the source of that is, but it's a
> heck of a lot better than what the previous code did.
> 
> I had to include the substance of patch #2 in this one, or else three
> other existing unit-tests failed.  I guess my two bugs fixes couldn't be
> separated after all :-)
> 
> As usual, apply the unit-test patch, watch it fail, apply the patch, watch
> it succeed, and use the project to verify behavior under .NET and MS
> Windows.
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650606p4650610.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patch for bug 6198/2263(Revision)

[Stifu]

You got me confused for a second. You mean bug 2663, not 2263.


Rob Wilkens wrote
> 
> I'm attaching a patch to bug2263 fix which was reported in bug6198.
> 
> I am unable to submit it via git right now due to connection issues
> and a corrupt linux install.  Please review/comment or just apply if
> that's ok.
> 
> I tested it against the code in 6198 as well as the unit tests which
> were already there for example for bug 2263.
> 
> In the bug 6198 there is a significant performance improvement found
> (on the order of minutes or hours) with this patch in place.
> 
> -Rob
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 




--
View this message in context: 
http://mono.1490590.n4.nabble.com/Patch-for-bug-6198-2263-Revision-tp4650589p4650595.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch 15 has been pushed
(https://github.com/mono/mono/commit/2f9c820c7ee1063d9fabcb2410b57843c17cb926).
Thanks!


Steven Boswell II wrote
> 
> Wow...that is totally bizarre.  I swear that working for me yesterday.  I
> can't get it to work now.
> Either I was in an evil parallel universe yesterday...or I am now.
> Oh well.  I'll let you know if I figure it out.
> 
> In the meantime, here's a fix for a bug I just noticed today.  If the
> currently-selected item of a drop-down-list-style ComboBox is modified,
> and the text selection is anything but the entire item, the combo-box's
> text box is updated improperly.  Enclosed is the unit test, patch, and
> project, as usual.
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Tuesday, July 24, 2012 10:53 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> The TableLayoutPanelTest2 project works properly without patching Mono. No
> errors, same rendering as .NET.
> 
> http://mono.1490590.n4.nabble.com/file/n4650550/mono_tablelayout2.png
> mono_tablelayout2.png 
> 
> 
> Steven Boswell II wrote
>> 
>> Enclosed is bug fix #2 of 3 for TableLayoutPanel.
>> 
>> http://msdn.microsoft.com/en-us/library/ms171690.aspx says that, when the
>> panel's AutoSize property is set to true, that Percent-style columns get
>> treated like AutoSize-style columns with regard to the widest child
>> control in the column.  Mono didn't do that; it does now.
>> 
>> 
>> Enclosed is a zip archive with a patch, a unit test, and a project.  As
>> usual, apply the unit test, watch it fail, apply the patch, watch the
>> unit
>> test succeed, and use the project to verify equivalent behavior under
>> .NET
>> and MS Windows.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650546p4650588.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

The TableLayoutPanelTest2 project works properly without patching Mono. No
errors, same rendering as .NET.

http://mono.1490590.n4.nabble.com/file/n4650550/mono_tablelayout2.png
mono_tablelayout2.png 


Steven Boswell II wrote
> 
> Enclosed is bug fix #2 of 3 for TableLayoutPanel.
> 
> http://msdn.microsoft.com/en-us/library/ms171690.aspx says that, when the
> panel's AutoSize property is set to true, that Percent-style columns get
> treated like AutoSize-style columns with regard to the widest child
> control in the column.  Mono didn't do that; it does now.
> 
> 
> Enclosed is a zip archive with a patch, a unit test, and a project.  As
> usual, apply the unit test, watch it fail, apply the patch, watch the unit
> test succeed, and use the project to verify equivalent behavior under .NET
> and MS Windows.
> 
> Coming next...a fix for table-layout panels when no control starts in a
> particular row/column.  Mono makes those rows/columns have zero extent,
> but .NET doesn't.  This is the bug fix that'll make the TableLayoutPanel1
> project display properly under Mono.
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650546p4650550.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono and Microsoft open sourced Entity Framework

[Stifu]

I somehow missed that news.
Great stuff!


Marek Safar-2 wrote
> 
> Hi,
> 
> Yes, we are working on EF integration.
> 
> Marek
> 
> On Tue, Jul 24, 2012 at 9:09 PM, Daniel Morgan wrote:
> 
>> Since Microsoft has open sourced the Entity Framework, is anyone working
>> on getting it to work on Mono?
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 




--
View this message in context: 
http://mono.1490590.n4.nabble.com/Mono-and-Microsoft-open-sourced-Entity-Framework-tp4650539p4650541.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch applied, thanks!

https://github.com/mono/mono/commit/a1e7e4ebf7737572e349c69fc0ae56bd28517891


Steven Boswell II wrote
> 
> OK, here's a much simpler patch.
> It draws a mixed-mode checkbox with a grey checkmark.
> Let me know if there's any problems.
> 
> Steven Boswell
> 
> 
> 
>  From: Steven Boswell II 
> To: "mono-devel-list@.ximian"  
> Sent: Sunday, July 22, 2012 5:22 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> 
> Ah...without EnableVisualStyles(), an indeterminate checkbox is a _grey_
> check mark in .NET under MS Windows.
> How about if I redo my change to draw the checkmark in grey?  Would you
> accept that patch?
> 
> 
> 
> 
>  From: Steven Boswell II 
> To: "mono-devel-list@.ximian"  
> Sent: Sunday, July 22, 2012 5:03 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> 
> Do you mean Application.EnableVisualStyles()?  Our application calls that
> in its Main() method.
> 
> I know I wasn't seeing the indeterminate checkbox when running Mono under
> Linux, which is why I thought to attempt this change in the first place. 
> Are you saying the indeterminate checkbox looks like the checked checkbox
> when Application.EnableVisualStyles() isn't called?
> 
> 
> I use Mono under Linux to write code that's shipped running .NET under MS
> Windows, but Mono lets me use a development environment (Fedora Core 16)
> that doesn't drive me up the wall.  So my experience with Mono is somewhat
> limited to that.
> 
> 
> Steven Boswell
> 
> 
> 
> 
>  From: Jonathan Pobst 
> To: Steven Boswell II  
> Cc: "mono-devel-list@.ximian"  
> Sent: Sunday, July 22, 2012 4:50 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Please note that this is controlled by Application.EnableVisualThemes.
> 
> Mono mimics the Win32 Classic look that the .NET Framework produces when 
> you do not call EnableVisualThemes.  (Note that if you created a project 
> in VS or something, this call was automatically added in your Program.cs.)
> 
> When EnableVisualThemes is called, the rendering should be controlled by 
> the OS, so you will see the filled square on Windows 7, but XP is 
> probably different.
> 
> I think Visual Styles work when Mono runs on Windows.  There were some 
> attempts to write it for GNOME and maybe Mac, but they were never
> completed.
> 
> On 7/22/2012 1:57 PM, Steven Boswell II wrote:
>> Enclosed is a patch that implements the drawing of mixed-mode
>> checkboxes.  Before, Mono just drew the indeterminate state with a check
>> mark.  Now, it's a blue box, which is closer to what .NET does.
>>   (Technically,
>  the patch uses the "highlight" color, which is a good
>> choice until a more exact idea comes along).
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650500p4650538.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Indeed, it is one fix per patch. I was just making sure, since this bug fix
altered that other Mono bug as a side effect, and I cannot tell whether it's
for better or worse. But if it's going to be fixed soon, then it doesn't
matter.

The patch has been pushed
(https://github.com/mono/mono/commit/55848244bb5b071250d42ace90864f9947e03e35).
Thanks.

PS: looks like TableLayoutTest.cs should be moved under
Test/System.Windows.Forms.Layout...


Steven Boswell II wrote
> 
> Yes, I do know why, and I haven't submitted that fix yet.
> It was my understanding that you wanted one bug fix per patch.
> I have two more table-layout bug fixes to submit after this one.
> 
> 
> 
> ________
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Monday, July 23, 2012 11:49 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Hmm, so the patch is exactly the same, only the test has changed. This
> means
> there is still a difference between .NET and Mono somewhere. I take it you
> don't know why?
> 
> I'll get to the other bug when time allows it.
> 
> Steven Boswell II wrote
>> I found the problem...I was working with two bug fixes I hadn't sent you
>> yet.  Enclosed is a new version of the unit test that works around the
>> visual artifact by adding another button to the layout.
>> 
>> Any thoughts on my fix for mixed-mode checkboxes?
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, July 22, 2012 11:24 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Weird. I just tried building WinForms master on Linux, and I get the same
>> result I get on Windows. Not sure what's wrong. But the tests still pass,
>> it's just the displayed controls that are wrong.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650494p4650537.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Hmm, so the patch is exactly the same, only the test has changed. This means
there is still a difference between .NET and Mono somewhere. I take it you
don't know why?

I'll get to the other bug when time allows it.


Steven Boswell II wrote
> 
> I found the problem...I was working with two bug fixes I hadn't sent you
> yet.  Enclosed is a new version of the unit test that works around the
> visual artifact by adding another button to the layout.
> 
> Any thoughts on my fix for mixed-mode checkboxes?
> 
> Steven Boswell
> 
> 
> 
> ____
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, July 22, 2012 11:24 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Weird. I just tried building WinForms master on Linux, and I get the same
> result I get on Windows. Not sure what's wrong. But the tests still pass,
> it's just the displayed controls that are wrong.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650494p4650530.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Weird. I just tried building WinForms master on Linux, and I get the same
result I get on Windows. Not sure what's wrong. But the tests still pass,
it's just the displayed controls that are wrong.


Steven Boswell II wrote
> 
> No idea...enclosed is the window generated on my system by the test
> project, superimposed over your screenshot.  As you can see, the layout is
> the same as the .NET one in your screenshot.
> 
> Thanks for looking at my patches.
> 
> 
> Steven Boswell
> 
> 
> 
> ____
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, July 22, 2012 2:38 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Any ideas why your test case looks different depending on the framework?
> http://mono.1490590.n4.nabble.com/file/n4650502/mono_patch12.png
> mono_patch12.png 
> 
> From left to right: Mono unpatched, Mono patched, .NET.
> 
> 
> Steven Boswell II wrote
>> 
>> Here's the first of what I hope will be several submitted patches this
>> weekend.  I fixed the bugs a while ago; the really time-consuming part is
>> coming up with unit tests.
>> 
>> Before, when TableLayoutPanel got a control whose row-span and
>> column-span
>> were both greater than one, it would only lay out "dummy" controls along
>> the top row and left column; it wouldn't fill in the rest of the area.
>>  (The bug is kinda obvious when you look at the code. :-)
>> 
>> Enclosed is a bug-fix patch, a unit-test patch, and a project to verify
>> behavior under .NET.  As usual, apply the unit-test patch, watch it fail,
>> then apply the bug-fix patch, and watch it succeed.
>> 
>> Steven Boswell
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650494p4650509.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Any ideas why your test case looks different depending on the framework?
http://mono.1490590.n4.nabble.com/file/n4650502/mono_patch12.png
mono_patch12.png 

From left to right: Mono unpatched, Mono patched, .NET.


Steven Boswell II wrote
> 
> Here's the first of what I hope will be several submitted patches this
> weekend.  I fixed the bugs a while ago; the really time-consuming part is
> coming up with unit tests.
> 
> Before, when TableLayoutPanel got a control whose row-span and column-span
> were both greater than one, it would only lay out "dummy" controls along
> the top row and left column; it wouldn't fill in the rest of the area.
>  (The bug is kinda obvious when you look at the code. :-)
> 
> Enclosed is a bug-fix patch, a unit-test patch, and a project to verify
> behavior under .NET.  As usual, apply the unit-test patch, watch it fail,
> then apply the bug-fix patch, and watch it succeed.
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4650494p4650502.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Sorry, I was wrong: bug 5834 *is* caused by patch 6, too. (I messed up my
tests as I'm juggling between .NET 2.0 or 4.0 depending on the application
I'm testing, which have separate WinForms DLLs.)

I'll go ahead and commit my fix, then.


Stifu wrote
> 
> The thought crossed my mind, but I'm not sure about that. Because with
> VisualStyles enabled, ToolStrips do not have a solid background color, but
> a gradient, that's why I thought we should only paint the background if
> there is a non-default one specified. I've seen other such cases like that
> in .NET, with other controls.
> 
> By the way, my proposed patch had a little problem:
> 
> "if (e.Item.Parent.BackColor != Control.DefaultBackColor) {"
> 
> The ".Parent" part should be removed.
> 
> 
> Steven Boswell II wrote
>> 
>> It seems to me that patch 6 revealed another bug, it didn't cause one.
>>  The problem seems to be that the default background color of
>> tool-strip-items is set wrong, i.e. bug 5834 describes the general
>> problem.  Your proposed patch seems, to me, to be too specific to the
>> example.
>> 
>> I would start by checking the default background colors in .NET and
>> making sure Mono is using the same colors.
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Saturday, June 23, 2012 4:19 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> I just noticed patch 6
>> (https://github.com/mono/mono/commit/3d04a14a278d6160e33c16b52b86d68fe45d80b1)
>> caused a regression.
>> 
>> See the attached screenshot (top: before patch, bottom: after patch).
>> http://mono.1490590.n4.nabble.com/file/n4650149/toolstripitems.png
>> toolstripitems.png 
>> 
>> The application this screenshot is from:
>> http://epicedit.stifu.fr/download/EpicEdit_2.5.zip
>> 
>> By the way, I just reported bug 5834
>> (https://bugzilla.xamarin.com/show_bug.cgi?id=5834), which may be
>> related,
>> except that one isn't a regression. Maybe we can kill two birds with one
>> stone.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4650153.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

The thought crossed my mind, but I'm not sure about that. Because with
VisualStyles enabled, ToolStrips do not have a solid background color, but a
gradient, that's why I thought we should only paint the background if there
is a non-default one specified. I've seen other such cases like that in
.NET, with other controls.

By the way, my proposed patch had a little problem:

"if (e.Item.Parent.BackColor != Control.DefaultBackColor) {"

The ".Parent" part should be removed.


Steven Boswell II wrote
> 
> It seems to me that patch 6 revealed another bug, it didn't cause one.
>  The problem seems to be that the default background color of
> tool-strip-items is set wrong, i.e. bug 5834 describes the general
> problem.  Your proposed patch seems, to me, to be too specific to the
> example.
> 
> I would start by checking the default background colors in .NET and making
> sure Mono is using the same colors.
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 23, 2012 4:19 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> I just noticed patch 6
> (https://github.com/mono/mono/commit/3d04a14a278d6160e33c16b52b86d68fe45d80b1)
> caused a regression.
> 
> See the attached screenshot (top: before patch, bottom: after patch).
> http://mono.1490590.n4.nabble.com/file/n4650149/toolstripitems.png
> toolstripitems.png 
> 
> The application this screenshot is from:
> http://epicedit.stifu.fr/download/EpicEdit_2.5.zip
> 
> By the way, I just reported bug 5834
> (https://bugzilla.xamarin.com/show_bug.cgi?id=5834), which may be related,
> except that one isn't a regression. Maybe we can kill two birds with one
> stone.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4650152.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Steven, what do you think we should do?
This seems to fix the regression:

protected virtual void OnRenderItemBackground
(ToolStripItemRenderEventArgs e)
{
if (e.Item.Parent.BackColor != Control.DefaultBackColor) {
Rectangle item_bounds = new Rectangle (0, 0, 
e.Item.Width,
e.Item.Height);
e.Graphics.FillRectangle 
(ThemeEngine.Current.ResPool.GetSolidBrush
(e.Item.BackColor), item_bounds);
}

if (e.Item.BackgroundImage != null) {
Rectangle item_bounds = new Rectangle (0, 0, 
e.Item.Width,
e.Item.Height);
DrawBackground (e.Graphics, item_bounds, 
e.Item.BackgroundImage,
e.Item.BackgroundImageLayout);
}

ToolStripItemRenderEventHandler eh =
(ToolStripItemRenderEventHandler)Events [RenderItemBackgroundEvent];
if (eh != null)
eh (this, e);
}

Do you have a better idea?


Stifu wrote
> 
> I just noticed patch 6
> (https://github.com/mono/mono/commit/3d04a14a278d6160e33c16b52b86d68fe45d80b1)
> caused a regression.
> 
> See the attached screenshot (top: before patch, bottom: after patch).
>  http://mono.1490590.n4.nabble.com/file/n4650149/toolstripitems.png
> toolstripitems.png 
> 
> The application this screenshot is from:
> http://epicedit.stifu.fr/download/EpicEdit_2.5.zip
> 
> By the way, I just reported bug 5834
> (https://bugzilla.xamarin.com/show_bug.cgi?id=5834), which may be related,
> except that one isn't a regression. Maybe we can kill two birds with one
> stone.
> 
> 
> Stifu wrote
>> 
>> PS: there's this one you can close, too:
>> https://bugzilla.xamarin.com/show_bug.cgi?id=5420
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Enclosed is a bug fix for another issue I ran into with Mono's ComboBox,
>>> where its behavior deviated from what .NET does.  You can apply the
>>> unit-test patch, watch it fail, then apply the patch, and watch the unit
>>> test succeed.  You can also run the enclosed project to see it succeed
>>> under .NET, fail with unpatched Mono, and succeed with patched Mono.
>>> 
>>> There doesn't seem to be any existing bug reports on this issue.
>>> 
>>> Hopefully this patch is a slam dunk, and Stifu doesn't have to waste his
>>> time pointing out my screwups. I really hate wasting his time like that.
>>> ;-)
>>> 
>>> Steven Boswell
>>> 
>>> P.S. https://bugzilla.xamarin.com/show_bug.cgi?id=5419 and https://bugzilla.xamarin.com/show_bug.cgi?id=5595 can
>>> be closed, since the patches were pushed.
>>> 
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.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-tp4649620p4650150.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I just noticed patch 6
(https://github.com/mono/mono/commit/3d04a14a278d6160e33c16b52b86d68fe45d80b1)
caused a regression.

See the attached screenshot (top: before patch, bottom: after patch).
http://mono.1490590.n4.nabble.com/file/n4650149/toolstripitems.png
toolstripitems.png 

The application this screenshot is from:
http://epicedit.stifu.fr/download/EpicEdit_2.5.zip

By the way, I just reported bug 5834
(https://bugzilla.xamarin.com/show_bug.cgi?id=5834), which may be related,
except that one isn't a regression. Maybe we can kill two birds with one
stone.


Stifu wrote
> 
> PS: there's this one you can close, too:
> https://bugzilla.xamarin.com/show_bug.cgi?id=5420
> 
> 
> Steven Boswell II wrote
>> 
>> Enclosed is a bug fix for another issue I ran into with Mono's ComboBox,
>> where its behavior deviated from what .NET does.  You can apply the
>> unit-test patch, watch it fail, then apply the patch, and watch the unit
>> test succeed.  You can also run the enclosed project to see it succeed
>> under .NET, fail with unpatched Mono, and succeed with patched Mono.
>> 
>> There doesn't seem to be any existing bug reports on this issue.
>> 
>> Hopefully this patch is a slam dunk, and Stifu doesn't have to waste his
>> time pointing out my screwups. I really hate wasting his time like that.
>> ;-)
>> 
>> Steven Boswell
>> 
>> P.S. https://bugzilla.xamarin.com/show_bug.cgi?id=5419 and https://bugzilla.xamarin.com/show_bug.cgi?id=5595 can
>> be closed, since the patches were pushed.
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4650149.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

PS: there's this one you can close, too:
https://bugzilla.xamarin.com/show_bug.cgi?id=5420


Steven Boswell II wrote
> 
> Enclosed is a bug fix for another issue I ran into with Mono's ComboBox,
> where its behavior deviated from what .NET does.  You can apply the
> unit-test patch, watch it fail, then apply the patch, and watch the unit
> test succeed.  You can also run the enclosed project to see it succeed
> under .NET, fail with unpatched Mono, and succeed with patched Mono.
> 
> There doesn't seem to be any existing bug reports on this issue.
> 
> Hopefully this patch is a slam dunk, and Stifu doesn't have to waste his
> time pointing out my screwups. I really hate wasting his time like that.
> ;-)
> 
> Steven Boswell
> 
> P.S. https://bugzilla.xamarin.com/show_bug.cgi?id=5419 and https://bugzilla.xamarin.com/show_bug.cgi?id=5595 can
> be closed, since the patches were pushed.
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4650134.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Assigned bug reports policy?

[Stifu]

I don't know if there are any written, official rules on this subject, but...

1- You may just contact the assignee and ask him/her what's up (you should
be able to grab his/her e-mail address from the bug report)
2- If the bug has been assigned to someone for months or years, it's
probably safe to steal the job... If in doubt, again, just contact him/her

And lastly, yes, you can contribute to any part of Mono. Again, don't
hesitate to contact the concerned people first, to make sure you're not
wasting your time or stepping on someone else's toes.


Rob Wilkens wrote
> 
> I have a general question, and it is a matter of etiquette for me (am I
> violating it) when I do something:
> 
> I recently, within the last few weeks when i was new to this stuff (still
> am, i know), took on a problem report that was marked as assigned to
> someone else.  I submitted a fix, though, and it was accepted.
> 
> But I have to ask: In general when something is assigned, should i try to
> avoid (or should i ask?) before working on it?
> 
> It is too late for me to start on a problem tonight, and i may or may not
> have time tomorrow, but I was looking at something that looked
> interesting, but i saw it was assigned.  I just want to know the general
> rule for assigned issues.  I know it should be harmless to look into
> problems without necessarily submitting a fix, and/or making an
> observation or suggestion.  At least in theory.
> 
> -Rob
> p.s. I know WinForm is a community supported part of mono, but i have
> interests in using mono beyond that, in the future, so I want to know if
> it is acceptable for me to attempt to contribute to other portions.  i do
> not want to accept any assignments on bug reports, because at this stage i
> cannot be responsible to necessarily get something done in a timely
> manner, i can't even guarantee i won't lose interest altogether and go do
> something else with my spare time.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

--
View this message in context: 
http://mono.1490590.n4.nabble.com/Assigned-bug-reports-policy-tp4650112p4650115.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Alright, patch 11 is in
(https://github.com/mono/mono/commit/b6a687dfd9c88cb2b05fe6313ccbcae8051f6555).
The hardest part was trying to come up with a commit message. :p
Thanks.

"I've encountered no failures with the OneClickComboBoxCell test in the form
that it exists in the git repo."
I'm guessing this is .NET only, due to the hacky P/Invokes...

"P.S. https://bugzilla.xamarin.com/show_bug.cgi?id=5419 and
https://bugzilla.xamarin.com/show_bug.cgi?id=5595 can be closed, since the
patches were pushed."
I would if I could, but unlike on Novell's bugzilla, I don't have the needed
rights to close these reports. But as the reporter, you should be able to.


Steven Boswell II wrote
> 
> Enclosed is a bug fix for another issue I ran into with Mono's ComboBox,
> where its behavior deviated from what .NET does.  You can apply the
> unit-test patch, watch it fail, then apply the patch, and watch the unit
> test succeed.  You can also run the enclosed project to see it succeed
> under .NET, fail with unpatched Mono, and succeed with patched Mono.
> 
> There doesn't seem to be any existing bug reports on this issue.
> 
> Hopefully this patch is a slam dunk, and Stifu doesn't have to waste his
> time pointing out my screwups. I really hate wasting his time like that.
> ;-)
> 
> Steven Boswell
> 
> P.S. https://bugzilla.xamarin.com/show_bug.cgi?id=5419 and https://bugzilla.xamarin.com/show_bug.cgi?id=5595 can
> be closed, since the patches were pushed.
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4650114.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Steven, about the strange test issues you mentioned, were you talking about
the OneClickComboBoxCell method, or not? Because I just realized this test
passes when run individually, but fails when run along with others.


Steven Boswell II wrote
> 
> I just ran into a puzzler...I was trying to write a unit test for patch
> #10, even though I've only seem the bug manifest when running my
> application under MonoDevelop.  It doesn't manifest outside of
> MonoDevelop, so it shouldn't manifest during NUnit, but I was trying
> anyway.
> 
> Enclosed is a patch for one of the ToolStripItem unit tests.  It
> succeeds...but it causes another unit test to fail!  I thought these tests
> ran independently of each other?  How could changes to one unit test cause
> a different one to fail?
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4650109.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Should i submit my Winforms queued patches here or github?

[Stifu]

"whether it's stifu or someone else if he genuinely
does decide to quit because of me :-( ."

You're being paranoid here. I'm not going anywhere, I was just cracking some
kind of joke. All is good.


Rob Wilkens wrote
> 
> Now that I have all of the Winforms patches (for Datagrid and Idle)
> extracted into individual patches -- which i did for the earlier e-mail,
> I can clean them up and submit them one at a time, to github, if that
> would be preferred?  OR I could submit them, one at a time (i.e. as we
> get to them), to this mailing list, if that would be preferred?  I
> suggest one at a time, because i noticed earlier that a change in one
> commit will break the application of the other patches to the same
> file(s).  When i say one at a time, i mean one datagrid patch at a time,
> and one idle patch at a time (if not just one idle patch altogether,
> since they are essentially one patch).
> 
> There is absolutely no rush either way, these patches in most cases have
> been in the problem report database for years.  I just want to make the
> job as easy as possible for whomever winds up reviewing them, whenever
> they get to them, whether it's stifu or someone else if he genuinely
> does decide to quit because of me :-( .
> 
> -Rob
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

--
View this message in context: 
http://mono.1490590.n4.nabble.com/Should-i-submit-my-Winforms-queued-patches-here-or-github-tp4650095p4650105.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

Rather than including the XML in the cs file, I was thinking not relying on
XML at all.
By the way, make sure to fix the coding style.

OnMouseDown(me); -> OnMouseDown (me);
if( disposing ) -> if (disposing)
base.Dispose( disposing ); -> base.Dispose (disposing);

etc


Rob Wilkens wrote
> 
> I think so, i think we can read xml from a string using  a
> stringreader.. I just wasn't thinking it through.
> 
> Give me some time today to get that done, it's 5:40am and i haven't had
> coffee yet.
> 
> 
> 
> -Rob
> 
> On 06/19/2012 01:56 AM, Stifu wrote:
>> Can't we simplify the test to avoid having to include that XML file?
>>
>>
>> Rob Wilkens wrote
>>> I've attached the unit test, and tested it.  It consistently fails,
>>> though not always with the same exception, when run on unpatched
>>> version.  It seems to consistently pass with the patched version.  Again
>>> this was with patch 2 which i submitted a revised version earlier
>>> tonight which took out a white space change which no longer applies.
>>>
>>> This tests
>>> Bug 5487
>>> and
>>> Bug 5511
>>> and possibly even
>>> Bug 5510 (which was a random crash which i believe was related to 5511)
>>>
>>> Patch 2 is designed to fix 5511.  The 5487 testing is a bonus because
>>> its part of the test, and 5510 was one that i only reported once and
>>> never happened after i put this patch on.
>>>
>>> -Rob
>>>
>>>
>>> On 06/18/2012 05:35 PM, Stifu wrote:
>>>> If you could just write the unit test, that should be all I need.
>>>>
>>>>
>>>> Rob Wilkens wrote
>>>>> In an automatable way, yes.
>>>>>
>>>>> By hand, not that hard.
>>>>>
>>>>> I can try to describe how to test it if you need.
>>>>>
>>>>> -Rob
>>>>> On 06/18/2012 05:27 PM, Stifu wrote:
>>>>>> If it took me 3 tries to get such a simple patch in, I think I'd
>>>>>> rather
>>>>>> resign. :)
>>>>>>
>>>>>> Anyway, I'll check out the other patches another day. Is patch 2 hard
>>>>>> to
>>>>>> test? I haven't looked at it yet.
>>>>>>
>>>>>>
>>>>>> Rob Wilkens wrote
>>>>>>> Thanks for not blindly trusting me :-)
>>>>>>>
>>>>>>>
>>>>>>> On 06/18/2012 05:20 PM, Stifu wrote:
>>>>>>>> No, it's fine.
>>>>>>>>
>>>>>>>>
>>>>>>>> Rob Wilkens wrote
>>>>>>>>> Whoops a second problem with the one you posted in the commit you
>>>>>>>>> mentioned, I think if we're checking >= then we want the results
>>>>>>>>> reversed...
>>>>>>>>>
>>>>>>>>> -Rob
>>>>>>>>>
>>>>>>>>> On 06/18/2012 05:06 PM, Rob Wilkens wrote:
>>>>>>>>>> I couldn't see it before you pushed it, and may have done it
>>>>>>>>>> wrong
>>>>>>>>>> myself (I don't recall now)..  :-)
>>>>>>>>>>
>>>>>>>>>> I'm sure in the case where this version you wrote would result in
>>>>>>>>>> a
>>>>>>>>>> zero
>>>>>>>>>> result, the zero result is probably OK.
>>>>>>>>>>
>>>>>>>>>> The version below is probably good if you're ok with it.
>>>>>>>>>>
>>>>>>>>>> -Rob
>>>>>>>>>>
>>>>>>>>>> On 06/18/2012 04:58 PM, Stifu wrote:
>>>>>>>>>>> Hah, that thought did cross my mind.
>>>>>>>>>>> Did you just wait for me to push it before saying that? :p
>>>>>>>>>>>
>>>>>>>>>>> We could go for:
>>>>>>>>>>>
>>>>>>>>>>> int next_pixel_offset = pixel_offset;
>>>>>>>>>>>
>>>>>>>>>>> if (CurrentColumn < 
>>>>>>>>>>> Cur

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

Can't we simplify the test to avoid having to include that XML file?


Rob Wilkens wrote
> 
> I've attached the unit test, and tested it.  It consistently fails,
> though not always with the same exception, when run on unpatched
> version.  It seems to consistently pass with the patched version.  Again
> this was with patch 2 which i submitted a revised version earlier
> tonight which took out a white space change which no longer applies.
> 
> This tests
> Bug 5487
> and
> Bug 5511
> and possibly even
> Bug 5510 (which was a random crash which i believe was related to 5511)
> 
> Patch 2 is designed to fix 5511.  The 5487 testing is a bonus because
> its part of the test, and 5510 was one that i only reported once and
> never happened after i put this patch on.
> 
> -Rob
> 
> 
> On 06/18/2012 05:35 PM, Stifu wrote:
>> If you could just write the unit test, that should be all I need.
>>
>>
>> Rob Wilkens wrote
>>> In an automatable way, yes.
>>>
>>> By hand, not that hard.
>>>
>>> I can try to describe how to test it if you need.
>>>
>>> -Rob
>>> On 06/18/2012 05:27 PM, Stifu wrote:
>>>> If it took me 3 tries to get such a simple patch in, I think I'd rather
>>>> resign. :)
>>>>
>>>> Anyway, I'll check out the other patches another day. Is patch 2 hard
>>>> to
>>>> test? I haven't looked at it yet.
>>>>
>>>>
>>>> Rob Wilkens wrote
>>>>> Thanks for not blindly trusting me :-)
>>>>>
>>>>>
>>>>> On 06/18/2012 05:20 PM, Stifu wrote:
>>>>>> No, it's fine.
>>>>>>
>>>>>>
>>>>>> Rob Wilkens wrote
>>>>>>> Whoops a second problem with the one you posted in the commit you
>>>>>>> mentioned, I think if we're checking >= then we want the results
>>>>>>> reversed...
>>>>>>>
>>>>>>> -Rob
>>>>>>>
>>>>>>> On 06/18/2012 05:06 PM, Rob Wilkens wrote:
>>>>>>>> I couldn't see it before you pushed it, and may have done it wrong
>>>>>>>> myself (I don't recall now)..  :-)
>>>>>>>>
>>>>>>>> I'm sure in the case where this version you wrote would result in a
>>>>>>>> zero
>>>>>>>> result, the zero result is probably OK.
>>>>>>>>
>>>>>>>> The version below is probably good if you're ok with it.
>>>>>>>>
>>>>>>>> -Rob
>>>>>>>>
>>>>>>>> On 06/18/2012 04:58 PM, Stifu wrote:
>>>>>>>>> Hah, that thought did cross my mind.
>>>>>>>>> Did you just wait for me to push it before saying that? :p
>>>>>>>>>
>>>>>>>>> We could go for:
>>>>>>>>>
>>>>>>>>>   int next_pixel_offset = pixel_offset;
>>>>>>>>>
>>>>>>>>>       if (CurrentColumn < 
>>>>>>>>> CurrentTableStyle.GridColumnStyles.Count)   
>>>>>>>>>   {
>>>>>>>>>   next_pixel_offset +=
>>>>>>>>> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width;
>>>>>>>>>   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rob Wilkens wrote
>>>>>>>>>> Slight issue which probably will never be a problem:
>>>>>>>>>>
>>>>>>>>>> I'd replace the "0" with "pixel_offset" since the normal
>>>>>>>>>> condition
>>>>>>>>>> for
>>>>>>>>>> that is pixel_offset PLUS the current column (which may be
>>>>>>>>>> invalid)
>>>>>>>>>> width.. 
>>>>>>>>>>
>>>>>>>>>> I don't think it'll be a problem though and can probably stand
>>>>>>>>>> as-is.
>>>>>>>>>>
>>>>>>>>>> -Rob
>>>>>>>>>>
&

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

If you could just write the unit test, that should be all I need.


Rob Wilkens wrote
> 
> In an automatable way, yes.
> 
> By hand, not that hard.
> 
> I can try to describe how to test it if you need.
> 
> -Rob
> On 06/18/2012 05:27 PM, Stifu wrote:
>> If it took me 3 tries to get such a simple patch in, I think I'd rather
>> resign. :)
>>
>> Anyway, I'll check out the other patches another day. Is patch 2 hard to
>> test? I haven't looked at it yet.
>>
>>
>> Rob Wilkens wrote
>>> Thanks for not blindly trusting me :-)
>>>
>>>
>>> On 06/18/2012 05:20 PM, Stifu wrote:
>>>> No, it's fine.
>>>>
>>>>
>>>> Rob Wilkens wrote
>>>>> Whoops a second problem with the one you posted in the commit you
>>>>> mentioned, I think if we're checking >= then we want the results
>>>>> reversed...
>>>>>
>>>>> -Rob
>>>>>
>>>>> On 06/18/2012 05:06 PM, Rob Wilkens wrote:
>>>>>> I couldn't see it before you pushed it, and may have done it wrong
>>>>>> myself (I don't recall now)..  :-)
>>>>>>
>>>>>> I'm sure in the case where this version you wrote would result in a
>>>>>> zero
>>>>>> result, the zero result is probably OK.
>>>>>>
>>>>>> The version below is probably good if you're ok with it.
>>>>>>
>>>>>> -Rob
>>>>>>
>>>>>> On 06/18/2012 04:58 PM, Stifu wrote:
>>>>>>> Hah, that thought did cross my mind.
>>>>>>> Did you just wait for me to push it before saying that? :p
>>>>>>>
>>>>>>> We could go for:
>>>>>>>
>>>>>>> int next_pixel_offset = pixel_offset;
>>>>>>>
>>>>>>> if (CurrentColumn < 
>>>>>>> CurrentTableStyle.GridColumnStyles.Count)   
>>>>>>> {
>>>>>>> next_pixel_offset +=
>>>>>>> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Rob Wilkens wrote
>>>>>>>> Slight issue which probably will never be a problem:
>>>>>>>>
>>>>>>>> I'd replace the "0" with "pixel_offset" since the normal condition
>>>>>>>> for
>>>>>>>> that is pixel_offset PLUS the current column (which may be invalid)
>>>>>>>> width.. 
>>>>>>>>
>>>>>>>> I don't think it'll be a problem though and can probably stand
>>>>>>>> as-is.
>>>>>>>>
>>>>>>>> -Rob
>>>>>>>>
>>>>>>>> On 06/18/2012 04:39 PM, Stifu wrote:
>>>>>>>>> Alright, the first patch is in
>>>>>>>>> (https://github.com/mono/mono/commit/42ebb31fc143a171a6a5930bc647627c557842ee).
>>>>>>>>> I took the liberty to change the coding style.
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rob Wilkens wrote
>>>>>>>>>> This is for Stifu:
>>>>>>>>>>
>>>>>>>>>> Please follow this sequence when applying or testing the patches
>>>>>>>>>> listed
>>>>>>>>>> below.  Doing in other order may break things.  If you want me to
>>>>>>>>>> create
>>>>>>>>>> a unit test for something you don't see a unit test for, let me
>>>>>>>>>> know,
>>>>>>>>>> but in some cases, clicks are required with a mouse and i'm not
>>>>>>>>>> necessarily sure how to create a patch to do that.
>>>>>>>>>>
>>>>>>>>>> Ok, I've attached the patches i had queued as separate individual
>>>>>>>>>> patches, i hope i did this right..  These are from ranges of git
>>>>>>>>>> diffs..

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

If it took me 3 tries to get such a simple patch in, I think I'd rather
resign. :)

Anyway, I'll check out the other patches another day. Is patch 2 hard to
test? I haven't looked at it yet.


Rob Wilkens wrote
> 
> Thanks for not blindly trusting me :-)
> 
> 
> On 06/18/2012 05:20 PM, Stifu wrote:
>> No, it's fine.
>>
>>
>> Rob Wilkens wrote
>>> Whoops a second problem with the one you posted in the commit you
>>> mentioned, I think if we're checking >= then we want the results
>>> reversed...
>>>
>>> -Rob
>>>
>>> On 06/18/2012 05:06 PM, Rob Wilkens wrote:
>>>> I couldn't see it before you pushed it, and may have done it wrong
>>>> myself (I don't recall now)..  :-)
>>>>
>>>> I'm sure in the case where this version you wrote would result in a
>>>> zero
>>>> result, the zero result is probably OK.
>>>>
>>>> The version below is probably good if you're ok with it.
>>>>
>>>> -Rob
>>>>
>>>> On 06/18/2012 04:58 PM, Stifu wrote:
>>>>> Hah, that thought did cross my mind.
>>>>> Did you just wait for me to push it before saying that? :p
>>>>>
>>>>> We could go for:
>>>>>
>>>>>   int next_pixel_offset = pixel_offset;
>>>>>
>>>>>   if (CurrentColumn < 
>>>>> CurrentTableStyle.GridColumnStyles.Count)   
>>>>>   {
>>>>>   next_pixel_offset +=
>>>>> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width;
>>>>>   }
>>>>>
>>>>>
>>>>> Rob Wilkens wrote
>>>>>> Slight issue which probably will never be a problem:
>>>>>>
>>>>>> I'd replace the "0" with "pixel_offset" since the normal condition
>>>>>> for
>>>>>> that is pixel_offset PLUS the current column (which may be invalid)
>>>>>> width.. 
>>>>>>
>>>>>> I don't think it'll be a problem though and can probably stand as-is.
>>>>>>
>>>>>> -Rob
>>>>>>
>>>>>> On 06/18/2012 04:39 PM, Stifu wrote:
>>>>>>> Alright, the first patch is in
>>>>>>> (https://github.com/mono/mono/commit/42ebb31fc143a171a6a5930bc647627c557842ee).
>>>>>>> I took the liberty to change the coding style.
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>> Rob Wilkens wrote
>>>>>>>> This is for Stifu:
>>>>>>>>
>>>>>>>> Please follow this sequence when applying or testing the patches
>>>>>>>> listed
>>>>>>>> below.  Doing in other order may break things.  If you want me to
>>>>>>>> create
>>>>>>>> a unit test for something you don't see a unit test for, let me
>>>>>>>> know,
>>>>>>>> but in some cases, clicks are required with a mouse and i'm not
>>>>>>>> necessarily sure how to create a patch to do that.
>>>>>>>>
>>>>>>>> Ok, I've attached the patches i had queued as separate individual
>>>>>>>> patches, i hope i did this right..  These are from ranges of git
>>>>>>>> diffs..  Please let me know if there are issues, my feelings won't
>>>>>>>> be
>>>>>>>> hurt, i'd rather do this right than do it fast.
>>>>>>>>
>>>>>>>> The order to apply them in (then i'll get into what it fixes
>>>>>>>> after):
>>>>>>>>
>>>>>>>> I'd suggest the DataGrid patches first because they are in the
>>>>>>>> middle
>>>>>>>> of
>>>>>>>> everything and get in the way -- except don't apply the
>>>>>>>> IdleAndDataGrid.Whitespace.Jun10.patch until you've applied ALL the
>>>>>>>> patches prior to Jun 10 (including idle patches), those patches in
>>>>>>>> the
>>>>>>>> Whitespace patch don't fix anything other the prettying up the

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

No, it's fine.


Rob Wilkens wrote
> 
> Whoops a second problem with the one you posted in the commit you
> mentioned, I think if we're checking >= then we want the results
> reversed...
> 
> -Rob
> 
> On 06/18/2012 05:06 PM, Rob Wilkens wrote:
>> I couldn't see it before you pushed it, and may have done it wrong
>> myself (I don't recall now)..  :-)
>>
>> I'm sure in the case where this version you wrote would result in a zero
>> result, the zero result is probably OK.
>>
>> The version below is probably good if you're ok with it.
>>
>> -Rob
>>
>> On 06/18/2012 04:58 PM, Stifu wrote:
>>> Hah, that thought did cross my mind.
>>> Did you just wait for me to push it before saying that? :p
>>>
>>> We could go for:
>>>
>>> int next_pixel_offset = pixel_offset;
>>>
>>> if (CurrentColumn < 
>>> CurrentTableStyle.GridColumnStyles.Count)   
>>> {
>>> next_pixel_offset +=
>>> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width;
>>> }
>>>
>>>
>>> Rob Wilkens wrote
>>>> Slight issue which probably will never be a problem:
>>>>
>>>> I'd replace the "0" with "pixel_offset" since the normal condition for
>>>> that is pixel_offset PLUS the current column (which may be invalid)
>>>> width.. 
>>>>
>>>> I don't think it'll be a problem though and can probably stand as-is.
>>>>
>>>> -Rob
>>>>
>>>> On 06/18/2012 04:39 PM, Stifu wrote:
>>>>> Alright, the first patch is in
>>>>> (https://github.com/mono/mono/commit/42ebb31fc143a171a6a5930bc647627c557842ee).
>>>>> I took the liberty to change the coding style.
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Rob Wilkens wrote
>>>>>> This is for Stifu:
>>>>>>
>>>>>> Please follow this sequence when applying or testing the patches
>>>>>> listed
>>>>>> below.  Doing in other order may break things.  If you want me to
>>>>>> create
>>>>>> a unit test for something you don't see a unit test for, let me know,
>>>>>> but in some cases, clicks are required with a mouse and i'm not
>>>>>> necessarily sure how to create a patch to do that.
>>>>>>
>>>>>> Ok, I've attached the patches i had queued as separate individual
>>>>>> patches, i hope i did this right..  These are from ranges of git
>>>>>> diffs..  Please let me know if there are issues, my feelings won't be
>>>>>> hurt, i'd rather do this right than do it fast.
>>>>>>
>>>>>> The order to apply them in (then i'll get into what it fixes after):
>>>>>>
>>>>>> I'd suggest the DataGrid patches first because they are in the middle
>>>>>> of
>>>>>> everything and get in the way -- except don't apply the
>>>>>> IdleAndDataGrid.Whitespace.Jun10.patch until you've applied ALL the
>>>>>> patches prior to Jun 10 (including idle patches), those patches in
>>>>>> the
>>>>>> Whitespace patch don't fix anything other the prettying up the code,
>>>>>> but
>>>>>> they depend on both set of patches in sequence..
>>>>>>
>>>>>> So the sequence i'm suggesting they must be applied in if they are
>>>>>> applied at all are:
>>>>>> (1) DataGrid1.Jun3.patch first
>>>>>> (2) DataGrid2.Jun4.patch second
>>>>>> (3) DataGrid3.Novell322563.jun4.patch third
>>>>>> (4) DataGrid4.Novell322154.jun6.patch
>>>>>> -- but don't do the other one i said not to do at this point --
>>>>>> now to the idle fixes, these next ones (5-9) are meant to all be
>>>>>> applied
>>>>>> as part of essentially one patch for it to work, but is broken up so
>>>>>> you
>>>>>> can see progression.
>>>>>> (5) Idle1-3.Jun2 (sorry for forgetting patch extension), This
>>>>>> contains 3
>>>>>> commits in one but they were all related, and makes life easier by
>>

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

"I couldn't see it before you pushed it, and may have done it wrong
myself (I don't recall now)..  :-)"

Well yeah, I only reformatted your patch, but didn't add in the zero, it was
there in the first place. You said it yourself, actually: "It is probably
perfectly acceptable if we're beyond the bounds to just leave this value at
zero for the offset."

Anyway, I'm pushing the modified version, as I agree it makes more sense and
is more readable, even if it makes no difference.

I know you sometimes only realize things afterward, but I'd like to think
things through to avoid creating noise as much as possible in the future. I
just feel bad polluting the version history.


Rob Wilkens wrote
> 
> I couldn't see it before you pushed it, and may have done it wrong
> myself (I don't recall now)..  :-)
> 
> I'm sure in the case where this version you wrote would result in a zero
> result, the zero result is probably OK.
> 
> The version below is probably good if you're ok with it.
> 
> -Rob
> 
> On 06/18/2012 04:58 PM, Stifu wrote:
>> Hah, that thought did cross my mind.
>> Did you just wait for me to push it before saying that? :p
>>
>> We could go for:
>>
>>  int next_pixel_offset = pixel_offset;
>>
>>  if (CurrentColumn < 
>> CurrentTableStyle.GridColumnStyles.Count)   
>>  {
>>  next_pixel_offset +=
>> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width;
>>  }
>>
>>
>> Rob Wilkens wrote
>>> Slight issue which probably will never be a problem:
>>>
>>> I'd replace the "0" with "pixel_offset" since the normal condition for
>>> that is pixel_offset PLUS the current column (which may be invalid)
>>> width.. 
>>>
>>> I don't think it'll be a problem though and can probably stand as-is.
>>>
>>> -Rob
>>>
>>> On 06/18/2012 04:39 PM, Stifu wrote:
>>>> Alright, the first patch is in
>>>> (https://github.com/mono/mono/commit/42ebb31fc143a171a6a5930bc647627c557842ee).
>>>> I took the liberty to change the coding style.
>>>> Thanks.
>>>>
>>>>
>>>> Rob Wilkens wrote
>>>>> This is for Stifu:
>>>>>
>>>>> Please follow this sequence when applying or testing the patches
>>>>> listed
>>>>> below.  Doing in other order may break things.  If you want me to
>>>>> create
>>>>> a unit test for something you don't see a unit test for, let me know,
>>>>> but in some cases, clicks are required with a mouse and i'm not
>>>>> necessarily sure how to create a patch to do that.
>>>>>
>>>>> Ok, I've attached the patches i had queued as separate individual
>>>>> patches, i hope i did this right..  These are from ranges of git
>>>>> diffs..  Please let me know if there are issues, my feelings won't be
>>>>> hurt, i'd rather do this right than do it fast.
>>>>>
>>>>> The order to apply them in (then i'll get into what it fixes after):
>>>>>
>>>>> I'd suggest the DataGrid patches first because they are in the middle
>>>>> of
>>>>> everything and get in the way -- except don't apply the
>>>>> IdleAndDataGrid.Whitespace.Jun10.patch until you've applied ALL the
>>>>> patches prior to Jun 10 (including idle patches), those patches in the
>>>>> Whitespace patch don't fix anything other the prettying up the code,
>>>>> but
>>>>> they depend on both set of patches in sequence..
>>>>>
>>>>> So the sequence i'm suggesting they must be applied in if they are
>>>>> applied at all are:
>>>>> (1) DataGrid1.Jun3.patch first
>>>>> (2) DataGrid2.Jun4.patch second
>>>>> (3) DataGrid3.Novell322563.jun4.patch third
>>>>> (4) DataGrid4.Novell322154.jun6.patch
>>>>> -- but don't do the other one i said not to do at this point --
>>>>> now to the idle fixes, these next ones (5-9) are meant to all be
>>>>> applied
>>>>> as part of essentially one patch for it to work, but is broken up so
>>>>> you
>>>>> can see progression.
>>>>> (5) Idle1-3.Jun2 (sorry for forgetting patch extension), This contains
>>

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

Hah, that thought did cross my mind.
Did you just wait for me to push it before saying that? :p

We could go for:

int next_pixel_offset = pixel_offset;

if (CurrentColumn < 
CurrentTableStyle.GridColumnStyles.Count)   
{
next_pixel_offset +=
CurrentTableStyle.GridColumnStyles[CurrentColumn].Width;
}


Rob Wilkens wrote
> 
> Slight issue which probably will never be a problem:
> 
> I'd replace the "0" with "pixel_offset" since the normal condition for
> that is pixel_offset PLUS the current column (which may be invalid)
> width.. 
> 
> I don't think it'll be a problem though and can probably stand as-is.
> 
> -Rob
> 
> On 06/18/2012 04:39 PM, Stifu wrote:
>> Alright, the first patch is in
>> (https://github.com/mono/mono/commit/42ebb31fc143a171a6a5930bc647627c557842ee).
>> I took the liberty to change the coding style.
>> Thanks.
>>
>>
>> Rob Wilkens wrote
>>> This is for Stifu:
>>>
>>> Please follow this sequence when applying or testing the patches listed
>>> below.  Doing in other order may break things.  If you want me to create
>>> a unit test for something you don't see a unit test for, let me know,
>>> but in some cases, clicks are required with a mouse and i'm not
>>> necessarily sure how to create a patch to do that.
>>>
>>> Ok, I've attached the patches i had queued as separate individual
>>> patches, i hope i did this right..  These are from ranges of git
>>> diffs..  Please let me know if there are issues, my feelings won't be
>>> hurt, i'd rather do this right than do it fast.
>>>
>>> The order to apply them in (then i'll get into what it fixes after):
>>>
>>> I'd suggest the DataGrid patches first because they are in the middle of
>>> everything and get in the way -- except don't apply the
>>> IdleAndDataGrid.Whitespace.Jun10.patch until you've applied ALL the
>>> patches prior to Jun 10 (including idle patches), those patches in the
>>> Whitespace patch don't fix anything other the prettying up the code, but
>>> they depend on both set of patches in sequence..
>>>
>>> So the sequence i'm suggesting they must be applied in if they are
>>> applied at all are:
>>> (1) DataGrid1.Jun3.patch first
>>> (2) DataGrid2.Jun4.patch second
>>> (3) DataGrid3.Novell322563.jun4.patch third
>>> (4) DataGrid4.Novell322154.jun6.patch
>>> -- but don't do the other one i said not to do at this point --
>>> now to the idle fixes, these next ones (5-9) are meant to all be applied
>>> as part of essentially one patch for it to work, but is broken up so you
>>> can see progression.
>>> (5) Idle1-3.Jun2 (sorry for forgetting patch extension), This contains 3
>>> commits in one but they were all related, and makes life easier by being
>>> summarized into one like this.
>>> (6) Now you should do IdleAndDataGrid.Whitespace.Jun10.patch
>>> (7) Next, do Idle-Win32IdleEnable.jun11.patch
>>> (8) Idle-RaceConditionFix-Jun12.patch is next
>>> (9) Idle-TestFixForIdle.jun12.patch is last
>>>
>>> There, I have 9 attachments, and above is the sequence to apply them in.
>>>
>>> The below numbering system matches the above patch order
>>>
>>> #1: from the commit message:
>>> The sample code in
>>> https://bugzilla.novell.com/show_bug.cgi?id=MONO79788 was crashing on me
>>> if I clicked on a row header (where the + was). I investigated and found
>>> that it was because, when the table had no data to display yet, and if
>>> you clicked on a row header (that's the area to the left of what would
>>> be the data), as part of assigning the current cell, it would call
>>> ensure cell visibility function, which would call ScrollToColumnInPixels
>>> which would try to get the next pixel offset by looking at
>>> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width, but when no
>>> data was being displayed there were no columns. So while current column
>>> had a value of zero, there were no items in the GridColumnStyles
>>> Array/List, even at zero index. The fix for this was before indexing
>>> into GridColumnStyles to Check The Length to make sure we're not going
>>> beyond its bounds. It is probably perfectly acceptable if we're beyond
>>> the bounds to just leave this value at zero for the o

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

You can still submit a test later if you feel like it, and if you can find an
elegant-enough one. But considering it's a tricky part to test, I don't
require it.


Rob Wilkens wrote
> 
> Beautiful..
> 
> I was working on a unit test for this one, but i guess that is not needed
> 
> Here it is standalone test for that bug if you want it (attached)...
> 
> -Rob
> 
> On 06/18/2012 04:39 PM, Stifu wrote:
>> Alright, the first patch is in
>> (https://github.com/mono/mono/commit/42ebb31fc143a171a6a5930bc647627c557842ee).
>> I took the liberty to change the coding style.
>> Thanks.
>>
>>
>> Rob Wilkens wrote
>>> This is for Stifu:
>>>
>>> Please follow this sequence when applying or testing the patches listed
>>> below.  Doing in other order may break things.  If you want me to create
>>> a unit test for something you don't see a unit test for, let me know,
>>> but in some cases, clicks are required with a mouse and i'm not
>>> necessarily sure how to create a patch to do that.
>>>
>>> Ok, I've attached the patches i had queued as separate individual
>>> patches, i hope i did this right..  These are from ranges of git
>>> diffs..  Please let me know if there are issues, my feelings won't be
>>> hurt, i'd rather do this right than do it fast.
>>>
>>> The order to apply them in (then i'll get into what it fixes after):
>>>
>>> I'd suggest the DataGrid patches first because they are in the middle of
>>> everything and get in the way -- except don't apply the
>>> IdleAndDataGrid.Whitespace.Jun10.patch until you've applied ALL the
>>> patches prior to Jun 10 (including idle patches), those patches in the
>>> Whitespace patch don't fix anything other the prettying up the code, but
>>> they depend on both set of patches in sequence..
>>>
>>> So the sequence i'm suggesting they must be applied in if they are
>>> applied at all are:
>>> (1) DataGrid1.Jun3.patch first
>>> (2) DataGrid2.Jun4.patch second
>>> (3) DataGrid3.Novell322563.jun4.patch third
>>> (4) DataGrid4.Novell322154.jun6.patch
>>> -- but don't do the other one i said not to do at this point --
>>> now to the idle fixes, these next ones (5-9) are meant to all be applied
>>> as part of essentially one patch for it to work, but is broken up so you
>>> can see progression.
>>> (5) Idle1-3.Jun2 (sorry for forgetting patch extension), This contains 3
>>> commits in one but they were all related, and makes life easier by being
>>> summarized into one like this.
>>> (6) Now you should do IdleAndDataGrid.Whitespace.Jun10.patch
>>> (7) Next, do Idle-Win32IdleEnable.jun11.patch
>>> (8) Idle-RaceConditionFix-Jun12.patch is next
>>> (9) Idle-TestFixForIdle.jun12.patch is last
>>>
>>> There, I have 9 attachments, and above is the sequence to apply them in.
>>>
>>> The below numbering system matches the above patch order
>>>
>>> #1: from the commit message:
>>> The sample code in
>>> https://bugzilla.novell.com/show_bug.cgi?id=MONO79788 was crashing on me
>>> if I clicked on a row header (where the + was). I investigated and found
>>> that it was because, when the table had no data to display yet, and if
>>> you clicked on a row header (that's the area to the left of what would
>>> be the data), as part of assigning the current cell, it would call
>>> ensure cell visibility function, which would call ScrollToColumnInPixels
>>> which would try to get the next pixel offset by looking at
>>> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width, but when no
>>> data was being displayed there were no columns. So while current column
>>> had a value of zero, there were no items in the GridColumnStyles
>>> Array/List, even at zero index. The fix for this was before indexing
>>> into GridColumnStyles to Check The Length to make sure we're not going
>>> beyond its bounds. It is probably perfectly acceptable if we're beyond
>>> the bounds to just leave this value at zero for the offset.
>>>
>>> #2 From the commit message:
>>> Xamaring bug 5511: This fixes this and some side issues..
>>> First, fixed the crash by creating two additional stacks for when
>>> navigating to and from other sub tables... Both were 'style' stacks
>>> which tracked per column styles. Those needed to be updated and reset on
>>> a per table basis. Sec

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

Alright, the first patch is in
(https://github.com/mono/mono/commit/42ebb31fc143a171a6a5930bc647627c557842ee).
I took the liberty to change the coding style.
Thanks.


Rob Wilkens wrote
> 
> This is for Stifu:
> 
> Please follow this sequence when applying or testing the patches listed
> below.  Doing in other order may break things.  If you want me to create
> a unit test for something you don't see a unit test for, let me know,
> but in some cases, clicks are required with a mouse and i'm not
> necessarily sure how to create a patch to do that.
> 
> Ok, I've attached the patches i had queued as separate individual
> patches, i hope i did this right..  These are from ranges of git
> diffs..  Please let me know if there are issues, my feelings won't be
> hurt, i'd rather do this right than do it fast.
> 
> The order to apply them in (then i'll get into what it fixes after):
> 
> I'd suggest the DataGrid patches first because they are in the middle of
> everything and get in the way -- except don't apply the
> IdleAndDataGrid.Whitespace.Jun10.patch until you've applied ALL the
> patches prior to Jun 10 (including idle patches), those patches in the
> Whitespace patch don't fix anything other the prettying up the code, but
> they depend on both set of patches in sequence..
> 
> So the sequence i'm suggesting they must be applied in if they are
> applied at all are:
> (1) DataGrid1.Jun3.patch first
> (2) DataGrid2.Jun4.patch second
> (3) DataGrid3.Novell322563.jun4.patch third
> (4) DataGrid4.Novell322154.jun6.patch
> -- but don't do the other one i said not to do at this point --
> now to the idle fixes, these next ones (5-9) are meant to all be applied
> as part of essentially one patch for it to work, but is broken up so you
> can see progression.
> (5) Idle1-3.Jun2 (sorry for forgetting patch extension), This contains 3
> commits in one but they were all related, and makes life easier by being
> summarized into one like this.
> (6) Now you should do IdleAndDataGrid.Whitespace.Jun10.patch
> (7) Next, do Idle-Win32IdleEnable.jun11.patch
> (8) Idle-RaceConditionFix-Jun12.patch is next
> (9) Idle-TestFixForIdle.jun12.patch is last
> 
> There, I have 9 attachments, and above is the sequence to apply them in.
> 
> The below numbering system matches the above patch order
> 
> #1: from the commit message:
> The sample code in
> https://bugzilla.novell.com/show_bug.cgi?id=MONO79788 was crashing on me
> if I clicked on a row header (where the + was). I investigated and found
> that it was because, when the table had no data to display yet, and if
> you clicked on a row header (that's the area to the left of what would
> be the data), as part of assigning the current cell, it would call
> ensure cell visibility function, which would call ScrollToColumnInPixels
> which would try to get the next pixel offset by looking at
> CurrentTableStyle.GridColumnStyles[CurrentColumn].Width, but when no
> data was being displayed there were no columns. So while current column
> had a value of zero, there were no items in the GridColumnStyles
> Array/List, even at zero index. The fix for this was before indexing
> into GridColumnStyles to Check The Length to make sure we're not going
> beyond its bounds. It is probably perfectly acceptable if we're beyond
> the bounds to just leave this value at zero for the offset.
> 
> #2 From the commit message:
> Xamaring bug 5511: This fixes this and some side issues..
> First, fixed the crash by creating two additional stacks for when
> navigating to and from other sub tables... Both were 'style' stacks
> which tracked per column styles. Those needed to be updated and reset on
> a per table basis. Second, When navigating forward or back, EndEdit
> needed to be called so that we don't leave an editing cell open when we
> navigate, otherwise there was the possibility and reality that the
> edited cell would still be visible and editing on the next table either
> forward or back. To recreate this on the sample code, presuming you can
> get past the initial crash which was fixed here, this could be
> illustrated without the endedits that were added as follows : Run: 1.
> click + 2. click pb 3. click + 4. click pb 3. click + 5. click pd 6.
> click back 6. click pc 7. See 0 highlighted in column header from
> previous table Finally, I modified some previous submissions on a
> related problem so that they had more "Love for Spaces" (whitespace)
> without changing the actual code other than that.
> 
> The above may have fixed, i think it was 5510 too.
> 
> 
> 
> #3: From the commit
> This solves PART of Novell Bugzilla Issue #322563
> https://b

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

Steve's click simulation hack is in DataGridViewTest.cs. I wonder if it'd be
possible to refactor it into a helper class, so it can be reused for any
test class.


Rob Wilkens wrote
> 
> Sorry, not a rush on my behalf, but i want to keep this thread alive
> until it's taken care of.
> 
> Will probably go out a few hours mid day today (won't be out as much as
> yesterday; today may be a lunch at the beach day-- dad bought an annual
> beach parking pass and we 'have' to get the most for our money out of
> it), let me know if you need anything from me, and you probably will in
> terms of creating tests.  I just have to figure out how to steal
> Steven's (i think it was him) code for faking mouse button clicks, and
> figure out where to send the clicks in terms of x and y (i have to click
> towards the far left but a little to the right, and then down maybe
> 50-100 pixels on a plus sign to make the sample crash as is and not
> crash with my fix.
> 
> -Rob
> 
> On 06/18/2012 02:42 AM, Stifu wrote:
>> A lot of work ahead, I see.
>>
>> About patch 1... I cannot manage to run the concerned test case with Mono
>> master, for some reason (I get a NullReferenceException in the DataGrid
>> constructor). I can run it with Mono 2.10, though. Rather than a
>> regression
>> (unlikely, DataGrid.cs hasn't been updated for ages), it may be related
>> to
>> the way I build WinForms. So I'll have to figure that out first.
>>
>> I'd rather hang myself than use cygwin again, so I'll just try to build
>> the
>> whole thing on Linux.
>>
>>
>> Rob Wilkens wrote
>>> BTW  -- at least one of my tests (and this is separate from earlier
>>> reply)
>>> would involve checking something visually..  I'm not sure if there is a
>>> trick for that (this is: Where edit boxes were displayed when they
>>> shouldn't be, or columns were displayed when they shouldn't have been).  
>>>
>>> But thanks for your suggestion, i will try to use it for at least where
>>> i
>>> had the crash
>>>
>>> On Jun 17, 2012, at 9:40 PM, Steven Boswell II wrote:
>>>
>>>> See
>>>> mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/DataGridViewTest.cs,
>>>> around line 1124.  I had to mimic a mouse-click in order to validate
>>>> one
>>>> of my data-grid-view bug fixes, and code to do that begins on that
>>>> line.
>>>>
>>>> From: Rob Wilkens <robwilkens@>
>>>> To: "mono-devel-list@.ximian" <mono-devel-list@.ximian>; Stifu
>>>> <stifu@> 
>>>> Sent: Sunday, June 17, 2012 6:05 PM
>>>> Subject: [Mono-dev] Win Patches for Datagrid (first here) then idle
>>>>
>>>> [...  If you want me to create a unit test for something you don't see
>>>> a
>>>> unit test for, let me know, but in some cases, clicks are required with
>>>> a
>>>> mouse and i'm not necessarily sure how to create a patch to do that.
>>>> ...]
>>>>
>>>> ___
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list@.ximian
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.ximian
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/Win-Patches-for-Datagrid-first-here-then-idle-tp4650027p4650035.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Win-Patches-for-Datagrid-first-here-then-idle-tp4650027p4650040.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Win Patches for Datagrid (first here) then idle

[Stifu]

A lot of work ahead, I see.

About patch 1... I cannot manage to run the concerned test case with Mono
master, for some reason (I get a NullReferenceException in the DataGrid
constructor). I can run it with Mono 2.10, though. Rather than a regression
(unlikely, DataGrid.cs hasn't been updated for ages), it may be related to
the way I build WinForms. So I'll have to figure that out first.

I'd rather hang myself than use cygwin again, so I'll just try to build the
whole thing on Linux.


Rob Wilkens wrote
> 
> BTW  -- at least one of my tests (and this is separate from earlier reply)
> would involve checking something visually..  I'm not sure if there is a
> trick for that (this is: Where edit boxes were displayed when they
> shouldn't be, or columns were displayed when they shouldn't have been).  
> 
> But thanks for your suggestion, i will try to use it for at least where i
> had the crash
> 
> On Jun 17, 2012, at 9:40 PM, Steven Boswell II wrote:
> 
>> See
>> mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/DataGridViewTest.cs,
>> around line 1124.  I had to mimic a mouse-click in order to validate one
>> of my data-grid-view bug fixes, and code to do that begins on that line.
>> 
>> From: Rob Wilkens <robwilkens@>
>> To: "mono-devel-list@.ximian" <mono-devel-list@.ximian>; Stifu
>> <stifu@> 
>> Sent: Sunday, June 17, 2012 6:05 PM
>> Subject: [Mono-dev] Win Patches for Datagrid (first here) then idle
>> 
>> [...  If you want me to create a unit test for something you don't see a
>> unit test for, let me know, but in some cases, clicks are required with a
>> mouse and i'm not necessarily sure how to create a patch to do that. ...]
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Win-Patches-for-Datagrid-first-here-then-idle-tp4650027p4650035.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Hah, I've been too hasty. Fixed.

About patch 10, I'm wondering... Wouldn't it be safer if we just checked if
the owner is null in the CalculateAutoSize() method, in case the same
problem could occur from somewhere else? Not sure whether that's possible.


Steven Boswell II wrote
> 
> No, both were wrong...here's a patch to make the just-checked-in unit-test
> correct.
> 
> Thanks for supporting my bug fixes!
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 17, 2012 3:08 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> What I do on Windows is only build WinForms, and that takes 2 seconds. But
> this requires fixing the WinForms project first. (By the way, I tried
> building Mono on Linux today, but got an error during the make... I'll
> have
> to try again later.)
> 
> I can confirm this DgvTest works as expected. So I take it only the
> DgvTest
> project was wrong, but the patch and unit test were correct.
> 
> 
> Steven Boswell II wrote
>> 
>> OK, I can now run Mono under MS Windows.  The last version of my
>> test-project (attached again, for your convenience) now dies where it's
>> supposed to in an unpatched Mono, i.e. it gets past 1-1.
>> 
>> I'm already checking with OS I'm on in this test.  Apparently that wasn't
>> enough.  My guess is that I'm running into some
>> other incompatibility between .NET and Mono, one way outside the scope of
>> my bug fix.  But the enclosed test-project checks both for MS Windows and
>> for the absence of Mono before using the god-awful P/Invoke-based mouse
>> click.
>> 
>> Rob: I'm trying to build latest Mono on MS Windows, and have applied the
>> patch you posted yesterday.  I'll let you (and everyone else) know how
>> far
>> I got.  Hopefully I'll be able to run the enclosed test-project against
>> it
>> successfully & FINALLY get this patch committed.
>> 
>> MY GOD, building Mono under MS Windows is slow.  I don't realize how
>> spoiled I am by Linux until times like this.
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 17, 2012 1:24 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Hah. To run the application with Mono on Windows, you should use the Mono
>> command prompt, and run the application using the "mono myapp.exe"
>> command.
>> The default window icon is different, which will confirm the application
>> is
>> run with Mono.
>> For what it's worth, P/Invokes should work with Mono on Windows. So if
>> you
>> have to use P/Invokes, maybe you shouldn't check with framework the
>> application is running on, but which OS you're on.
>> 
>> "And re: getting bug fixes accepted, and WinForms not being a priority
>> for
>> the Mono project...what about the bug fix for GetFileSystemEntries() I
>> posted a week ago?  That's not WinForms, and I haven't heard a peep about
>> it."
>> 
>> I don't know. I'm not on the Mono team, and only deal with WinForms.
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/Patches-for-mono-winforms-tp4649620p4650020.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4650023.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4650034.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch 2 is in
(https://github.com/mono/mono/commit/508b0c06680caa89e8ef9a0d0cd6c05d3126a6ab).
Thanks for your work.


Stifu wrote
> 
> What I do on Windows is only build WinForms, and that takes 2 seconds. But
> this requires fixing the WinForms project first. (By the way, I tried
> building Mono on Linux today, but got an error during the make... I'll
> have to try again later.)
> 
> I can confirm this DgvTest works as expected. So I take it only the
> DgvTest project was wrong, but the patch and unit test were correct.
> 
> 
> Steven Boswell II wrote
>> 
>> OK, I can now run Mono under MS Windows.  The last version of my
>> test-project (attached again, for your convenience) now dies where it's
>> supposed to in an unpatched Mono, i.e. it gets past 1-1.
>> 
>> I'm already checking with OS I'm on in this test.  Apparently that wasn't
>> enough.  My guess is that I'm running into some
>> other incompatibility between .NET and Mono, one way outside the scope of
>> my bug fix.  But the enclosed test-project checks both for MS Windows and
>> for the absence of Mono before using the god-awful P/Invoke-based mouse
>> click.
>> 
>> Rob: I'm trying to build latest Mono on MS Windows, and have applied the
>> patch you posted yesterday.  I'll let you (and everyone else) know how
>> far I got.  Hopefully I'll be able to run the enclosed test-project
>> against it successfully & FINALLY get this patch committed.
>> 
>> MY GOD, building Mono under MS Windows is slow.  I don't realize how
>> spoiled I am by Linux until times like this.
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 17, 2012 1:24 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Hah. To run the application with Mono on Windows, you should use the Mono
>> command prompt, and run the application using the "mono myapp.exe"
>> command.
>> The default window icon is different, which will confirm the application
>> is
>> run with Mono.
>> For what it's worth, P/Invokes should work with Mono on Windows. So if
>> you
>> have to use P/Invokes, maybe you shouldn't check with framework the
>> application is running on, but which OS you're on.
>> 
>> "And re: getting bug fixes accepted, and WinForms not being a priority
>> for
>> the Mono project...what about the bug fix for GetFileSystemEntries() I
>> posted a week ago?  That's not WinForms, and I haven't heard a peep about
>> it."
>> 
>> I don't know. I'm not on the Mono team, and only deal with WinForms.
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/Patches-for-mono-winforms-tp4649620p4650020.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4650024.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

What I do on Windows is only build WinForms, and that takes 2 seconds. But
this requires fixing the WinForms project first. (By the way, I tried
building Mono on Linux today, but got an error during the make... I'll have
to try again later.)

I can confirm this DgvTest works as expected. So I take it only the DgvTest
project was wrong, but the patch and unit test were correct.


Steven Boswell II wrote
> 
> OK, I can now run Mono under MS Windows.  The last version of my
> test-project (attached again, for your convenience) now dies where it's
> supposed to in an unpatched Mono, i.e. it gets past 1-1.
> 
> I'm already checking with OS I'm on in this test.  Apparently that wasn't
> enough.  My guess is that I'm running into some
> other incompatibility between .NET and Mono, one way outside the scope of
> my bug fix.  But the enclosed test-project checks both for MS Windows and
> for the absence of Mono before using the god-awful P/Invoke-based mouse
> click.
> 
> Rob: I'm trying to build latest Mono on MS Windows, and have applied the
> patch you posted yesterday.  I'll let you (and everyone else) know how far
> I got.  Hopefully I'll be able to run the enclosed test-project against it
> successfully & FINALLY get this patch committed.
> 
> MY GOD, building Mono under MS Windows is slow.  I don't realize how
> spoiled I am by Linux until times like this.
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 17, 2012 1:24 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Hah. To run the application with Mono on Windows, you should use the Mono
> command prompt, and run the application using the "mono myapp.exe"
> command.
> The default window icon is different, which will confirm the application
> is
> run with Mono.
> For what it's worth, P/Invokes should work with Mono on Windows. So if you
> have to use P/Invokes, maybe you shouldn't check with framework the
> application is running on, but which OS you're on.
> 
> "And re: getting bug fixes accepted, and WinForms not being a priority for
> the Mono project...what about the bug fix for GetFileSystemEntries() I
> posted a week ago?  That's not WinForms, and I haven't heard a peep about
> it."
> 
> I don't know. I'm not on the Mono team, and only deal with WinForms.
> 
> 
> 
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Patches-for-mono-winforms-tp4649620p4650020.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4650023.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Hah. To run the application with Mono on Windows, you should use the Mono
command prompt, and run the application using the "mono myapp.exe" command.
The default window icon is different, which will confirm the application is
run with Mono.
For what it's worth, P/Invokes should work with Mono on Windows. So if you
have to use P/Invokes, maybe you shouldn't check with framework the
application is running on, but which OS you're on.

"And re: getting bug fixes accepted, and WinForms not being a priority for
the Mono project...what about the bug fix for GetFileSystemEntries() I
posted a week ago?  That's not WinForms, and I haven't heard a peep about
it."

I don't know. I'm not on the Mono team, and only deal with WinForms.


Steven Boswell II wrote
> 
> Well...it seems the problem is that selecting "Mono / .NET 3.5" versus
> ".NET Framework 3.5 Client Profile" in MonoDevelop's
> Options->Build->General pane doesn't seem to change the DLLs that get
> loaded at runtime.  It looks like I've been running with .NET either way.
>  Is there something else I'm supposed to do under MS Windows to run with
> Mono instead of .NET?  I ran an installer called
> "mono-2.10.8-gtksharp-2.12.11-win32-1" to install Mono under MS Windows.
>  Is there anything else I need to install?
> 
> Here's a random idea...enclosed is another version of the test project.
>  It's just like the last one, except that, in addition to testing for
> whether it's running on MS Windows before doing the god-awful P/Invoke
> version of faking a mouse click, it also tests "Type.GetType
> ("Mono.Runtime") == null", to make sure it's .NET running and not Mono.
>  While I wait for someone to tell me what I'm doing wrong under MS
> Windows, see if this gets the test to run for you.
> 
> And re: getting bug fixes accepted, and WinForms not being a priority for
> the Mono project...what about the bug fix for GetFileSystemEntries() I
> posted a week ago?  That's not WinForms, and I haven't heard a peep about
> it.
> 
> Steven Boswell
> 
> 
> 
>  From: Steven Boswell II <ulatekh@>
> To: "mono-devel-list@.ximian" <mono-devel-list@.ximian> 
> Sent: Saturday, June 16, 2012 5:52 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> 
> Thanks, Rob.  That's exactly what I expect would happen.  Only by building
> latest Mono, with the patch, will the project's test succeed with Mono.
> 
> Don't worry about stretching your patience -- the fact that you got it to
> succeed in .NET was plenty helpful.
> 
> Stifu..."whether I build it with .NET or Mono, I get the error I
> mentioned, running the application with Mono on Windows"...if you ran it
> with unpatched Mono, that's what I expect to happen.  If you ran it with
> patched Mono or with .NET, I wouldn't.  What exactly did you do?
> 
> Steven Boswell
> 
> 
> 
>  From: Rob Wilkens <robwilkens@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 16, 2012 5:41 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> As per the test project mentioned, I just tested with Microsoft Visual
> Studio 2010 professional, on Windows 7, with Microsoft .NET (By clicking
> Debug->Start Debugging to run it), this does not raise any exceptions
> (no message box), it leaves me with an open window.  I also tested on
> Mono on Windows (version 2.10.8) and the test fails in mono, seemingly
> before a window is displayed on the screen.
> 
> Again, i know my opinion is of mixed value.
> 
> BTW - I did not try applying the patch in mono, i don't have the
> patience right now (unless you want me to) to build mono in windows.
> 
> -Rob
> 
> 
> 
> On 06/16/2012 06:39 PM, Stifu wrote:
>> I wasn't talking about the mailing list in particular, but any media
>> (bugzilla, Git...). My point was that getting that many patches pushed
>> within such a short time, for a part that is no longer maintained by the
>> Mono team, is pretty good. I'd have been
>  pretty happy if my patches received
>> that much attention a few years ago.
>>
>> Anyway, about patch 2, whether I build it with .NET or Mono, I get the
>> error
>> I mentioned, running the application with Mono on Windows. So unless this
>> is
>> an OS-specific issue, I don't know what's the problem. I'll try to check
>> it
>> out on Linux, whenever I can find some time. Meanwhile, if anyone wants
>> to
>> review the patch, feel free.
>>
>>
>> 

Re: [Mono-dev] Restart my fork?

[Stifu]

One fix = one patch + one test (if possible).
As for the lock you added, just merge that with your earlier patch, so that
the patch really fully fixes the problem.

If some patch requires another patch first, just specify that here. I'll
probably review the easiest patches first, to get them out of the way. If
you want to suggest a certain review order, go ahead.


Rob Wilkens wrote
> 
> I was going to plan to break this up into individual commits, but
> instead when i get to this i may break it up into each file's worth of
> changes (or in the case of some commits, set of files) and document what
> fixes what in each, if that is ok with you?  i.e. i'll try to document
> what was changed line by line or set of lines, and specifically when
> documenting it cover the 'why'.
> 
> The reason for this is that i have some changes i made in earlier
> commits which 'worked' but every so often crashed while adding an idle
> handler i later found, and i fixed this with a lock (this) {} in a later
> commit around a very small section of code (2-4 lines).. But that was
> after i made unrelated changes elsewhere (the datagrid changes).
> 
> Or if you prefer i get it commit by commit i'll do that, but in that
> cases, at least some of the commits will have to be applied in the same
> order because they have a dependency on a previous commit going through.
> 
> -Rob
> 
> On 06/17/2012 09:34 AM, Stifu wrote:
>> Alright, I'm not in a hurry.
>>
>>
>> Rob Wilkens wrote
>>> I won't have time to do that right now, but will later, please be
>>> patient..   I wouldn't wait around the keyboard right now for an e-mail
>>> because i'm next in line for the shower then we're heading out for
>>> morning.
>>>
>>> The bug reports are listed on the pull page, but i will try to separate
>>> the changes out into what fixes what.
>>>
>>> -Rob
>>>  
>>>
>>> On 06/17/2012 09:26 AM, Stifu wrote:
>>>> Please separate each patch, so I can review them one by one. This is
>>>> just
>>>> too
>>>> big to review, and I don't know even know what it's trying to fix.
>>>> Also, please give me the concerned bug reports, if any.
>>>>
>>>>
>>>> Robert Wilkens wrote
>>>>> Ok, if you are willing to look at it, i've attached it if i did it
>>>>> right...
>>>>>
>>>>> I did a git diff   
>>>>>
>>>>> That should have the whole range of changes of all the commits,
>>>>> hopefully i've attached the right file too.
>>>>>
>>>>> This should align with the following pull request on github.com:
>>>>> https://github.com/mono/mono/pull/322
>>>>> Which originally was a closed pull request which i cancelled when i
>>>>> needed to make additional changes:
>>>>> https://github.com/mono/mono/pull/312
>>>>>
>>>>> I'm probably not going to be home all day today, so if you have
>>>>> questions, i am willing to answer them but i may be delayed.  I'll try
>>>>> to bring my laptop if i do go out.
>>>>>
>>>>> -Rob
>>>>>
>>>>> On 06/17/2012 08:21 AM, Stifu wrote:
>>>>>> Can't really give Git-related advices, I suck at it, but I can easily
>>>>>> review
>>>>>> WinForms patches if you simply attach them to your messages the
>>>>>> old-school
>>>>>> way.
>>>>>>
>>>>>>
>>>>>> Robert Wilkens wrote
>>>>>>> My master branch contains two unrelated winforms changes (one change
>>>>>>> for
>>>>>>> idle, one change for DataGrid - not DataGridView don't worry i'm not
>>>>>>> duplicating work), it's becoming clear that they are not going to
>>>>>>> receive priority and i have no problem with that.
>>>>>>>
>>>>>>> But i do have at least one non-winforms fix which i'd like to at
>>>>>>> least
>>>>>>> get reviewed.  That's not going to happen since the winforms changes
>>>>>>> have to go thru first.
>>>>>>>
>>>>>>> Is it considered a safe thing to:
>>>>>>> 1) Backup the files that i changed for each fix
>>>>>>> 2) Delete my fork
>>>

Re: [Mono-dev] Restart my fork?

[Stifu]

Alright, I'm not in a hurry.


Rob Wilkens wrote
> 
> I won't have time to do that right now, but will later, please be
> patient..   I wouldn't wait around the keyboard right now for an e-mail
> because i'm next in line for the shower then we're heading out for
> morning.
> 
> The bug reports are listed on the pull page, but i will try to separate
> the changes out into what fixes what.
> 
> -Rob
>  
> 
> On 06/17/2012 09:26 AM, Stifu wrote:
>> Please separate each patch, so I can review them one by one. This is just
>> too
>> big to review, and I don't know even know what it's trying to fix.
>> Also, please give me the concerned bug reports, if any.
>>
>>
>> Robert Wilkens wrote
>>> Ok, if you are willing to look at it, i've attached it if i did it
>>> right...
>>>
>>> I did a git diff   
>>>
>>> That should have the whole range of changes of all the commits,
>>> hopefully i've attached the right file too.
>>>
>>> This should align with the following pull request on github.com:
>>> https://github.com/mono/mono/pull/322
>>> Which originally was a closed pull request which i cancelled when i
>>> needed to make additional changes:
>>> https://github.com/mono/mono/pull/312
>>>
>>> I'm probably not going to be home all day today, so if you have
>>> questions, i am willing to answer them but i may be delayed.  I'll try
>>> to bring my laptop if i do go out.
>>>
>>> -Rob
>>>
>>> On 06/17/2012 08:21 AM, Stifu wrote:
>>>> Can't really give Git-related advices, I suck at it, but I can easily
>>>> review
>>>> WinForms patches if you simply attach them to your messages the
>>>> old-school
>>>> way.
>>>>
>>>>
>>>> Robert Wilkens wrote
>>>>> My master branch contains two unrelated winforms changes (one change
>>>>> for
>>>>> idle, one change for DataGrid - not DataGridView don't worry i'm not
>>>>> duplicating work), it's becoming clear that they are not going to
>>>>> receive priority and i have no problem with that.
>>>>>
>>>>> But i do have at least one non-winforms fix which i'd like to at least
>>>>> get reviewed.  That's not going to happen since the winforms changes
>>>>> have to go thru first.
>>>>>
>>>>> Is it considered a safe thing to:
>>>>> 1) Backup the files that i changed for each fix
>>>>> 2) Delete my fork
>>>>> 3) Create a new fork
>>>>> 4) Create branches for each change and submit them separately
>>>>>
>>>>> I think this would help me get past my current state of 'i can't
>>>>> really
>>>>> do anything until my master branch is approved or rejected'...
>>>>>
>>>>> I probably won't do this today, but if I don't hear back i might do
>>>>> that
>>>>> sometime this week.
>>>>>
>>>>> -Rob
>>>>>
>>>>> ___
>>>>> Mono-devel-list mailing list
>>>>> Mono-devel-list@.ximian
>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>>
>>>> --
>>>> View this message in context:
>>>> http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650006.html
>>>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>>>> ___
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list@.ximian
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.ximian
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650009.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650011.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Restart my fork?

[Stifu]

Please separate each patch, so I can review them one by one. This is just too
big to review, and I don't know even know what it's trying to fix.
Also, please give me the concerned bug reports, if any.


Robert Wilkens wrote
> 
> Ok, if you are willing to look at it, i've attached it if i did it
> right...
> 
> I did a git diff   
> 
> That should have the whole range of changes of all the commits,
> hopefully i've attached the right file too.
> 
> This should align with the following pull request on github.com:
> https://github.com/mono/mono/pull/322
> Which originally was a closed pull request which i cancelled when i
> needed to make additional changes:
> https://github.com/mono/mono/pull/312
> 
> I'm probably not going to be home all day today, so if you have
> questions, i am willing to answer them but i may be delayed.  I'll try
> to bring my laptop if i do go out.
> 
> -Rob
> 
> On 06/17/2012 08:21 AM, Stifu wrote:
>> Can't really give Git-related advices, I suck at it, but I can easily
>> review
>> WinForms patches if you simply attach them to your messages the
>> old-school
>> way.
>>
>>
>> Robert Wilkens wrote
>>> My master branch contains two unrelated winforms changes (one change for
>>> idle, one change for DataGrid - not DataGridView don't worry i'm not
>>> duplicating work), it's becoming clear that they are not going to
>>> receive priority and i have no problem with that.
>>>
>>> But i do have at least one non-winforms fix which i'd like to at least
>>> get reviewed.  That's not going to happen since the winforms changes
>>> have to go thru first.
>>>
>>> Is it considered a safe thing to:
>>> 1) Backup the files that i changed for each fix
>>> 2) Delete my fork
>>> 3) Create a new fork
>>> 4) Create branches for each change and submit them separately
>>>
>>> I think this would help me get past my current state of 'i can't really
>>> do anything until my master branch is approved or rejected'...
>>>
>>> I probably won't do this today, but if I don't hear back i might do that
>>> sometime this week.
>>>
>>> -Rob
>>>
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.ximian
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650006.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650009.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Restart my fork?

[Stifu]

Can't really give Git-related advices, I suck at it, but I can easily review
WinForms patches if you simply attach them to your messages the old-school
way.


Robert Wilkens wrote
> 
> My master branch contains two unrelated winforms changes (one change for
> idle, one change for DataGrid - not DataGridView don't worry i'm not
> duplicating work), it's becoming clear that they are not going to
> receive priority and i have no problem with that.
> 
> But i do have at least one non-winforms fix which i'd like to at least
> get reviewed.  That's not going to happen since the winforms changes
> have to go thru first.
> 
> Is it considered a safe thing to:
> 1) Backup the files that i changed for each fix
> 2) Delete my fork
> 3) Create a new fork
> 4) Create branches for each change and submit them separately
> 
> I think this would help me get past my current state of 'i can't really
> do anything until my master branch is approved or rejected'...
> 
> I probably won't do this today, but if I don't hear back i might do that
> sometime this week.
> 
> -Rob
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650006.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

"Sure now you tell me" - 2 minutes after you said you'd install it. Could
hardly have been any faster.


Robert Wilkens wrote
> 
> Sure now you tell me, i chose putty and even imported my key into
> puttyssh...
> 
> But it seems first i need to install git for windows before i can do
> anything with it (i previously only used the one in cygwin).. So i'll
> wait till that install is done before i consider reinstalling tortoise
> and trying the other option
> .
> 
> 
> On 06/17/2012 07:31 AM, Stifu wrote:
>> "I will try tortoisegit in my windows install."
>>
>> When installing it, make sure not to pick the Putty (default) option, but
>> the other one.
>>
>>
>> Robert Wilkens wrote
>>> Accoding to the man page, if i'm reading it right, to use revert, i'd be
>>> creating a new commit to undo an existing commit.  In this case, i
>>> didn't commit anything.
>>>
>>> git checkout  did work for me though, it checked out the one from
>>> the current copy of my tree, replacing the modified file which i never
>>> did a git add on.
>>>
>>> I will try tortoisegit in my windows install.
>>>
>>> -Rob
>>>
>>> On 06/17/2012 07:15 AM, Stifu wrote:
>>>> Heh. So I'm not crazy. Thanks for confirming.
>>>>
>>>> To unapply the patch, you can just revert the concerned file, no?
>>>> By the way, you do it all in command lines? As a Windows user, I like
>>>> to
>>>> use
>>>> TortoiseGit.
>>>>
>>>>
>>>> Robert Wilkens wrote
>>>>> Ok, it fails for me in windows with this patch applied, i'm going to
>>>>> see
>>>>> if i can unapply this patch (just 'git checkout ' should do it i
>>>>> think...
>>>>>
>>>>> Here's the error i get:
>>>>> 1-1: expected not null, found null.
>>>>>
>>>>> -Rob
>>>>>
>>>>> On 06/17/2012 06:33 AM, Rob Wilkens wrote:
>>>>>> I figured out git apply and am going to test this in windows now.
>>>>>>
>>>>>> I am going to do this from a cygwin build.
>>>>>>
>>>>>> It may be a little while before the build and make install are done.
>>>>>>
>>>>>> -Rob
>>>>>>
>>>>>> On 06/17/2012 06:20 AM, Robert Wilkens wrote:
>>>>>>> Do you want me to try this?  Does it make a difference what platform
>>>>>>> i
>>>>>>> try this on?  Is the one patch the only patch that is required for
>>>>>>> this? 
>>>>>>> Does it matter whether i tested with my older robwilkens/mono tree
>>>>>>> or
>>>>>>> do
>>>>>>> i need to test with the latest and greatest (and not building,,
>>>>>>> though
>>>>>>> i've got a tree half-built that fixes that) version of mono.
>>>>>>>
>>>>>>> -rob
>>>>>>>
>>>>>>> On Jun 17, 2012, at 4:21 AM, Stifu wrote:
>>>>>>>
>>>>>>>> To clear things up, when running with .NET, I do *not* get the
>>>>>>>> error.
>>>>>>>> I
>>>>>>>> was
>>>>>>>> just making it clear that whether I *build* the application with
>>>>>>>> .NET
>>>>>>>> or
>>>>>>>> Mono doesn't make a difference. So what Rob sees matches what I
>>>>>>>> see.
>>>>>>>>
>>>>>>>> Running with .NET: works
>>>>>>>> Running with Mono: error
>>>>>>>>
>>>>>>>> Except Rob didn't check this last one:
>>>>>>>>
>>>>>>>> Running with patched Mono: error
>>>>>>>>
>>>>>>>>
>>>>>>>> Steven Boswell II wrote
>>>>>>>>> Thanks, Rob.  That's exactly what I expect would happen.  Only by
>>>>>>>>> building
>>>>>>>>> latest Mono, with the patch, will the project's test succeed with
>>>>>>>>> Mono.
>>>>>>>>>
>>>>>>>>> Don't worry about stretc

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

"I will try tortoisegit in my windows install."

When installing it, make sure not to pick the Putty (default) option, but
the other one.


Robert Wilkens wrote
> 
> Accoding to the man page, if i'm reading it right, to use revert, i'd be
> creating a new commit to undo an existing commit.  In this case, i
> didn't commit anything.
> 
> git checkout  did work for me though, it checked out the one from
> the current copy of my tree, replacing the modified file which i never
> did a git add on.
> 
> I will try tortoisegit in my windows install.
> 
> -Rob
> 
> On 06/17/2012 07:15 AM, Stifu wrote:
>> Heh. So I'm not crazy. Thanks for confirming.
>>
>> To unapply the patch, you can just revert the concerned file, no?
>> By the way, you do it all in command lines? As a Windows user, I like to
>> use
>> TortoiseGit.
>>
>>
>> Robert Wilkens wrote
>>> Ok, it fails for me in windows with this patch applied, i'm going to see
>>> if i can unapply this patch (just 'git checkout ' should do it i
>>> think...
>>>
>>> Here's the error i get:
>>> 1-1: expected not null, found null.
>>>
>>> -Rob
>>>
>>> On 06/17/2012 06:33 AM, Rob Wilkens wrote:
>>>> I figured out git apply and am going to test this in windows now.
>>>>
>>>> I am going to do this from a cygwin build.
>>>>
>>>> It may be a little while before the build and make install are done.
>>>>
>>>> -Rob
>>>>
>>>> On 06/17/2012 06:20 AM, Robert Wilkens wrote:
>>>>> Do you want me to try this?  Does it make a difference what platform i
>>>>> try this on?  Is the one patch the only patch that is required for
>>>>> this? 
>>>>> Does it matter whether i tested with my older robwilkens/mono tree or
>>>>> do
>>>>> i need to test with the latest and greatest (and not building,, though
>>>>> i've got a tree half-built that fixes that) version of mono.
>>>>>
>>>>> -rob
>>>>>
>>>>> On Jun 17, 2012, at 4:21 AM, Stifu wrote:
>>>>>
>>>>>> To clear things up, when running with .NET, I do *not* get the error.
>>>>>> I
>>>>>> was
>>>>>> just making it clear that whether I *build* the application with .NET
>>>>>> or
>>>>>> Mono doesn't make a difference. So what Rob sees matches what I see.
>>>>>>
>>>>>> Running with .NET: works
>>>>>> Running with Mono: error
>>>>>>
>>>>>> Except Rob didn't check this last one:
>>>>>>
>>>>>> Running with patched Mono: error
>>>>>>
>>>>>>
>>>>>> Steven Boswell II wrote
>>>>>>> Thanks, Rob.  That's exactly what I expect would happen.  Only by
>>>>>>> building
>>>>>>> latest Mono, with the patch, will the project's test succeed with
>>>>>>> Mono.
>>>>>>>
>>>>>>> Don't worry about stretching your patience -- the fact that you got
>>>>>>> it
>>>>>>> to
>>>>>>> succeed in .NET was plenty helpful.
>>>>>>>
>>>>>>> Stifu..."whether I build it with .NET or Mono, I get the error I
>>>>>>> mentioned, running the application with Mono on Windows"...if you
>>>>>>> ran
>>>>>>> it
>>>>>>> with unpatched Mono, that's what I expect to happen.  If you ran it
>>>>>>> with
>>>>>>> patched Mono or with .NET, I wouldn't.  What exactly did you do?
>>>>>>>
>>>>>>> Steven Boswell
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> From: Rob Wilkens <robwilkens@>
>>>>>>> To: mono-devel-list@.ximian 
>>>>>>> Sent: Saturday, June 16, 2012 5:41 PM
>>>>>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>>>>>
>>>>>>> As per the test project mentioned, I just tested with Microsoft
>>>>>>> Visual
>>>>>>> Studio 2010 professional, on Windows 7, with Microsoft .NET (By
>>>>>&g

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Heh. So I'm not crazy. Thanks for confirming.

To unapply the patch, you can just revert the concerned file, no?
By the way, you do it all in command lines? As a Windows user, I like to use
TortoiseGit.


Robert Wilkens wrote
> 
> Ok, it fails for me in windows with this patch applied, i'm going to see
> if i can unapply this patch (just 'git checkout ' should do it i
> think...
> 
> Here's the error i get:
> 1-1: expected not null, found null.
> 
> -Rob
> 
> On 06/17/2012 06:33 AM, Rob Wilkens wrote:
>> I figured out git apply and am going to test this in windows now.
>>
>> I am going to do this from a cygwin build.
>>
>> It may be a little while before the build and make install are done.
>>
>> -Rob
>>
>> On 06/17/2012 06:20 AM, Robert Wilkens wrote:
>>> Do you want me to try this?  Does it make a difference what platform i
>>> try this on?  Is the one patch the only patch that is required for this? 
>>> Does it matter whether i tested with my older robwilkens/mono tree or do
>>> i need to test with the latest and greatest (and not building,, though
>>> i've got a tree half-built that fixes that) version of mono.
>>>
>>> -rob
>>>
>>> On Jun 17, 2012, at 4:21 AM, Stifu wrote:
>>>
>>>> To clear things up, when running with .NET, I do *not* get the error. I
>>>> was
>>>> just making it clear that whether I *build* the application with .NET
>>>> or
>>>> Mono doesn't make a difference. So what Rob sees matches what I see.
>>>>
>>>> Running with .NET: works
>>>> Running with Mono: error
>>>>
>>>> Except Rob didn't check this last one:
>>>>
>>>> Running with patched Mono: error
>>>>
>>>>
>>>> Steven Boswell II wrote
>>>>> Thanks, Rob.  That's exactly what I expect would happen.  Only by
>>>>> building
>>>>> latest Mono, with the patch, will the project's test succeed with
>>>>> Mono.
>>>>>
>>>>> Don't worry about stretching your patience -- the fact that you got it
>>>>> to
>>>>> succeed in .NET was plenty helpful.
>>>>>
>>>>> Stifu..."whether I build it with .NET or Mono, I get the error I
>>>>> mentioned, running the application with Mono on Windows"...if you ran
>>>>> it
>>>>> with unpatched Mono, that's what I expect to happen.  If you ran it
>>>>> with
>>>>> patched Mono or with .NET, I wouldn't.  What exactly did you do?
>>>>>
>>>>> Steven Boswell
>>>>>
>>>>>
>>>>> 
>>>>> From: Rob Wilkens <robwilkens@>
>>>>> To: mono-devel-list@.ximian 
>>>>> Sent: Saturday, June 16, 2012 5:41 PM
>>>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>>>
>>>>> As per the test project mentioned, I just tested with Microsoft Visual
>>>>> Studio 2010 professional, on Windows 7, with Microsoft .NET (By
>>>>> clicking
>>>>> Debug->Start Debugging to run it), this does not raise any exceptions
>>>>> (no message box), it leaves me with an open window.  I also tested on
>>>>> Mono on Windows (version 2.10.8) and the test fails in mono, seemingly
>>>>> before a window is displayed on the screen.
>>>>>
>>>>> Again, i know my opinion is of mixed value.
>>>>>
>>>>> BTW - I did not try applying the patch in mono, i don't have the
>>>>> patience right now (unless you want me to) to build mono in windows.
>>>>>
>>>>> -Rob
>>>>>
>>>>>
>>>>>
>>>>> On 06/16/2012 06:39 PM, Stifu wrote:
>>>>>> I wasn't talking about the mailing list in particular, but any media
>>>>>> (bugzilla, Git...). My point was that getting that many patches
>>>>>> pushed
>>>>>> within such a short time, for a part that is no longer maintained by
>>>>>> the
>>>>>> Mono team, is pretty good. I'd have been pretty happy if my patches
>>>>>> received
>>>>>> that much attention a few years ago.
>>>>>>
>>>>>> Anyway, about patch 2, whether I build it with .NET or Mono, I

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

"Do you want me to try this?"
Feel free.

"Does it make a difference what platform i try this on?"
I don't know yet. That's what I'm trying to figure out. I tested on Windows.
Then again, it's possible it failed due to the way I built the assembly (not
using cygwin), so you may want to try on Windows too.

"Is the one patch the only patch that is required for this?"
Yes.

"Does it matter whether i tested with my older robwilkens/mono tree or do i
need to test with the latest and greatest (and not building,, though i've
got a tree half-built that fixes that) version of mono."
Shouldn't matter.


Robert Wilkens wrote
> 
> Do you want me to try this?  Does it make a difference what platform i try
> this on?  Is the one patch the only patch that is required for this?  Does
> it matter whether i tested with my older robwilkens/mono tree or do i need
> to test with the latest and greatest (and not building,, though i've got a
> tree half-built that fixes that) version of mono.
> 
> -rob
> 
> On Jun 17, 2012, at 4:21 AM, Stifu wrote:
> 
>> To clear things up, when running with .NET, I do *not* get the error. I
>> was
>> just making it clear that whether I *build* the application with .NET or
>> Mono doesn't make a difference. So what Rob sees matches what I see.
>> 
>> Running with .NET: works
>> Running with Mono: error
>> 
>> Except Rob didn't check this last one:
>> 
>> Running with patched Mono: error
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Thanks, Rob.  That's exactly what I expect would happen.  Only by
>>> building
>>> latest Mono, with the patch, will the project's test succeed with Mono.
>>> 
>>> Don't worry about stretching your patience -- the fact that you got it
>>> to
>>> succeed in .NET was plenty helpful.
>>> 
>>> Stifu..."whether I build it with .NET or Mono, I get the error I
>>> mentioned, running the application with Mono on Windows"...if you ran it
>>> with unpatched Mono, that's what I expect to happen.  If you ran it with
>>> patched Mono or with .NET, I wouldn't.  What exactly did you do?
>>> 
>>> Steven Boswell
>>> 
>>> 
>>> 
>>> From: Rob Wilkens <robwilkens@>
>>> To: mono-devel-list@.ximian 
>>> Sent: Saturday, June 16, 2012 5:41 PM
>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>> 
>>> As per the test project mentioned, I just tested with Microsoft Visual
>>> Studio 2010 professional, on Windows 7, with Microsoft .NET (By clicking
>>> Debug->Start Debugging to run it), this does not raise any exceptions
>>> (no message box), it leaves me with an open window.  I also tested on
>>> Mono on Windows (version 2.10.8) and the test fails in mono, seemingly
>>> before a window is displayed on the screen.
>>> 
>>> Again, i know my opinion is of mixed value.
>>> 
>>> BTW - I did not try applying the patch in mono, i don't have the
>>> patience right now (unless you want me to) to build mono in windows.
>>> 
>>> -Rob
>>> 
>>> 
>>> 
>>> On 06/16/2012 06:39 PM, Stifu wrote:
>>>> I wasn't talking about the mailing list in particular, but any media
>>>> (bugzilla, Git...). My point was that getting that many patches pushed
>>>> within such a short time, for a part that is no longer maintained by
>>>> the
>>>> Mono team, is pretty good. I'd have been pretty happy if my patches
>>>> received
>>>> that much attention a few years ago.
>>>> 
>>>> Anyway, about patch 2, whether I build it with .NET or Mono, I get the
>>>> error
>>>> I mentioned, running the application with Mono on Windows. So unless
>>>> this
>>>> is
>>>> an OS-specific issue, I don't know what's the problem. I'll try to
>>>> check
>>>> it
>>>> out on Linux, whenever I can find some time. Meanwhile, if anyone wants
>>>> to
>>>> review the patch, feel free.
>>>> 
>>>> 
>>>> Steven Boswell II wrote
>>>>> Are you saying that there have been bug fixes submitted to this
>>>>> mailing
>>>>> list, that have sat around for YEARS without being acted upon by those
>>>>> with version-control-commit authority...?
>>>>> 
>>>>&

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

To clear things up, when running with .NET, I do *not* get the error. I was
just making it clear that whether I *build* the application with .NET or
Mono doesn't make a difference. So what Rob sees matches what I see.

Running with .NET: works
Running with Mono: error

Except Rob didn't check this last one:

Running with patched Mono: error


Steven Boswell II wrote
> 
> Thanks, Rob.  That's exactly what I expect would happen.  Only by building
> latest Mono, with the patch, will the project's test succeed with Mono.
> 
> Don't worry about stretching your patience -- the fact that you got it to
> succeed in .NET was plenty helpful.
> 
> Stifu..."whether I build it with .NET or Mono, I get the error I
> mentioned, running the application with Mono on Windows"...if you ran it
> with unpatched Mono, that's what I expect to happen.  If you ran it with
> patched Mono or with .NET, I wouldn't.  What exactly did you do?
> 
> Steven Boswell
> 
> 
> 
>  From: Rob Wilkens <robwilkens@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 16, 2012 5:41 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> As per the test project mentioned, I just tested with Microsoft Visual
> Studio 2010 professional, on Windows 7, with Microsoft .NET (By clicking
> Debug->Start Debugging to run it), this does not raise any exceptions
> (no message box), it leaves me with an open window.  I also tested on
> Mono on Windows (version 2.10.8) and the test fails in mono, seemingly
> before a window is displayed on the screen.
> 
> Again, i know my opinion is of mixed value.
> 
> BTW - I did not try applying the patch in mono, i don't have the
> patience right now (unless you want me to) to build mono in windows.
> 
> -Rob
> 
> 
> 
> On 06/16/2012 06:39 PM, Stifu wrote:
>> I wasn't talking about the mailing list in particular, but any media
>> (bugzilla, Git...). My point was that getting that many patches pushed
>> within such a short time, for a part that is no longer maintained by the
>> Mono team, is pretty good. I'd have been pretty happy if my patches
>> received
>> that much attention a few years ago.
>>
>> Anyway, about patch 2, whether I build it with .NET or Mono, I get the
>> error
>> I mentioned, running the application with Mono on Windows. So unless this
>> is
>> an OS-specific issue, I don't know what's the problem. I'll try to check
>> it
>> out on Linux, whenever I can find some time. Meanwhile, if anyone wants
>> to
>> review the patch, feel free.
>>
>>
>> Steven Boswell II wrote
>>> Are you saying that there have been bug fixes submitted to this mailing
>>> list, that have sat around for YEARS without being acted upon by those
>>> with version-control-commit authority...?
>>>
>>> I installed latest mono to /usr/local, compiled my test with "gmcs
>>> -out:DgvTest.exe Program.cs -r:System -r:System.Windows.Forms -r
>>> System.Drawing", and ran it with "mono DgvTest.exe", and it runs fine
>>> for
>>> me.  So I guess we're back to having an impasse.  Sigh.
>>>
>>> Steven Boswell
>>>
>>>
>>> 
>>>  From: Stifu <stifu@>
>>> To: mono-devel-list@.ximian 
>>> Sent: Saturday, June 16, 2012 1:09 AM
>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>  
>>> Honestly, you've had it much better than the vast majority. :)
>>> Some others have been waiting for years. Also, now you can add NUnit to
>>> your
>>> resume. :p
>>>
>>> Anyway, I get a "1-1: expected not null, found null" message box in
>>> DgvTest4
>>> with Mono, even after applying your patch.
>>>
>>>
>>> Steven Boswell II wrote
>>>> I agree, but we both know how much toil it takes to get our bug fixes
>>>> accepted and applied to the git repository on this mailing list... ;-)
>>>>
>>>>
>>>> 
>>>>   From: Rob Wilkens <robwilkens@>
>>>> To: mono-devel-list@.ximian 
>>>> Sent: Friday, June 15, 2012 5:42 PM
>>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>>  
>>>>
>>>> I know my opinion is of mixed value, but it looks to make sense to me.. 
>>>> If the toolstripitem is being changed so it no longer has an owner,
>>>> calculating a size might not make sense
>&g

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I wasn't talking about the mailing list in particular, but any media
(bugzilla, Git...). My point was that getting that many patches pushed
within such a short time, for a part that is no longer maintained by the
Mono team, is pretty good. I'd have been pretty happy if my patches received
that much attention a few years ago.

Anyway, about patch 2, whether I build it with .NET or Mono, I get the error
I mentioned, running the application with Mono on Windows. So unless this is
an OS-specific issue, I don't know what's the problem. I'll try to check it
out on Linux, whenever I can find some time. Meanwhile, if anyone wants to
review the patch, feel free.


Steven Boswell II wrote
> 
> Are you saying that there have been bug fixes submitted to this mailing
> list, that have sat around for YEARS without being acted upon by those
> with version-control-commit authority...?
> 
> I installed latest mono to /usr/local, compiled my test with "gmcs
> -out:DgvTest.exe Program.cs -r:System -r:System.Windows.Forms -r
> System.Drawing", and ran it with "mono DgvTest.exe", and it runs fine for
> me.  So I guess we're back to having an impasse.  Sigh.
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 16, 2012 1:09 AM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Honestly, you've had it much better than the vast majority. :)
> Some others have been waiting for years. Also, now you can add NUnit to
> your
> resume. :p
> 
> Anyway, I get a "1-1: expected not null, found null" message box in
> DgvTest4
> with Mono, even after applying your patch.
> 
> 
> Steven Boswell II wrote
>> 
>> I agree, but we both know how much toil it takes to get our bug fixes
>> accepted and applied to the git repository on this mailing list... ;-)
>> 
>> 
>> 
>>  From: Rob Wilkens <robwilkens@>
>> To: mono-devel-list@.ximian 
>> Sent: Friday, June 15, 2012 5:42 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> 
>> I know my opinion is of mixed value, but it looks to make sense to me.. 
>> If the toolstripitem is being changed so it no longer has an owner,
>> calculating a size might not make sense
>> 
>> -Rob
>> 
>> On 06/15/2012 08:34 PM, Steven Boswell II wrote: 
>> [... Digging through the stack trace, I arrived at
>> System.Windows.Forms.ToolStripItem.set_InternalOwner, where the owner was
>> being set to null, and right afterwards, CalculateAutoSize() was being
>> called.  Why would anyone need to calculate the size of a menu-item that
>> isn't even connected to a menu any more?  So, for me, the bug fix was
>> obvious: check if the owner isn't null before
>> calling CalculateAutoSize().
>>  That's what the enclosed patch does. ...]
>>>
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4649980.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649989.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Honestly, you've had it much better than the vast majority. :)
Some others have been waiting for years. Also, now you can add NUnit to your
resume. :p

Anyway, I get a "1-1: expected not null, found null" message box in DgvTest4
with Mono, even after applying your patch.


Steven Boswell II wrote
> 
> I agree, but we both know how much toil it takes to get our bug fixes
> accepted and applied to the git repository on this mailing list... ;-)
> 
> 
> 
>  From: Rob Wilkens 
> To: mono-devel-list@.ximian 
> Sent: Friday, June 15, 2012 5:42 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> 
> I know my opinion is of mixed value, but it looks to make sense to me.. 
> If the toolstripitem is being changed so it no longer has an owner,
> calculating a size might not make sense
> 
> -Rob
> 
> On 06/15/2012 08:34 PM, Steven Boswell II wrote: 
> [... Digging through the stack trace, I arrived at
> System.Windows.Forms.ToolStripItem.set_InternalOwner, where the owner was
> being set to null, and right afterwards, CalculateAutoSize() was being
> called.  Why would anyone need to calculate the size of a menu-item that
> isn't even connected to a menu any more?  So, for me, the bug fix was
> obvious: check if the owner isn't null before calling CalculateAutoSize().
>  That's what the enclosed patch does. ...]
>>
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649980.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] .net winforms and windows

[Stifu]

"My test code (attached) runs fine in Windows .net, doesn't crash once, and i
just ran it from the command prompt about 30-40 times in a row in .net.  So
that should run in mono, no?"

Yes, I was just confused by your original post: "In my testing of .net
winforms on windows i received a lot of gdi+ object busy errors", which made
it sound like the errors were .NET ones.


Rob Wilkens wrote
> 
> [long story short: Got to troubleshoot some more, but the answer is that 
> these apps are functional in windows, attached a sample]
> 
> In Windows.NET it definitely works, both the code sample from the bug 
> report (which, incidentally, is not running for me right now, so i've 
> pulled back my pull request while i investigate, if i figure out why i 
> will reopen it, i haven't troubleshot that yet)..  My test code 
> (attached) runs fine in Windows .net, doesn't crash once, and i just ran 
> it from the command prompt about 30-40 times in a row in .net.  So that 
> should run in mono, no?
> 
> In unpatched mono in windows, my code leaves two windows open, and after 
> you close that it will say 'error' because the would-be assertions fail.
> 
> In mono with my patch, it passed, but it crashed every 5-10 runs, 
> unrelated, i beleive, to my patch but more to the rest of the code now 
> being run because of the patch.  Yesterday i was getting GDI+ Object 
> Busy, I can't reproduce that now, but that could be any number of things 
> such as timing.
> 
> The crash I'm occasionally getting in my app now may have something to 
> do with the change in response to your message yesterday about needing 
> to call invoke (the form was created in thread 1, invoke is being called 
> in thread 3[the 2nd thread]).  But the form was shown with a call to 
> Application.Run(form2) in thread 2, because i couldn't figure another 
> easy way to make the application.run loop to exit on its own at the end 
> of execution (I tried several methods, none worked).
> 
> The crash I've traced twice to here (again in Windows .NET this does not 
> crash) using gdb:..
> #8  0x02733612 in ?? ()
> #9  0x027333c1 in ?? ()
> #10 0x659cb7ac in mono_jit_runtime_invoke (method=0x5bee70, obj=0x2f709d8,
>  params=0x393ff44, exc=0x0) at mini.c:5897
> #11 0x65b235d2 in mono_runtime_invoke (method=0x5bee70, obj=0x2f709d8,
>  params=0x393ff44, exc=0x0) at object.c:2809
> #12 0x65b24237 in mono_runtime_delegate_invoke (delegate=0x2f709d8,
>  params=0x393ff44, exc=0x0) at object.c:3489
> #13 0x65b4ef76 in start_wrapper (data=0x2ff3d68) at threads.c:577
> #14 0x65b7452a in inner_start_thread (arg=0x2ff3990)
>at mono-threads-windows.c:86
> #15 0x7670339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
> from /cygdrive/c/Windows/syswow64/kernel32.dll
> #16 0x02ff3990 in ?? ()
> #17 0x770f9ef2 in ntdll!RtlpNtSetValueKey ()
> ---Type  to continue, or q  to quit---ls ~
> from /cygdrive/c/Windows/system32/ntdll.dll
> #18 0x02ff3990 in ?? ()
> #19 0x770f9ec5 in ntdll!RtlpNtSetValueKey ()
> from /cygdrive/c/Windows/system32/ntdll.dll
> #20 0x65b744e0 in mono_threads_platform_free ()
> from
> /cygdrive/c/cygwin/home/RobWilkens/new-mono-local/bin/mono-2.0.dll
> 
> But again, this doesn't seem to crash every or most times, and is 
> unrelated to my patch, only to my test.
> 
> And i still have to first debug the original sample code..
> 
> I'll try to make sure my code sample and the sample from the bug report 
> work before i re-open my pull request.  Both run fine on Windows 7 with 
> MS .NET.
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

--
View this message in context: 
http://mono.1490590.n4.nabble.com/net-winforms-and-windows-tp4649922p4649928.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] .net winforms and windows

[Stifu]

Just to make sure, you mean you get these issues with .NET, with Mono, or
with both?
Anyway, to clear things up, as far as GDI+ and WinForms are concerned, the
goal is to be as compatible with them as possible, not to make something
better or more powerful. Ideally, the same things should work or fail on
each framework. We don't want things that work only on Mono and not with
.NET, especially for compatibility stacks like these.


Rob Wilkens wrote
> 
> I wanted to think about what to work on next, and i wonder if anyone has 
> an opinion on this:
> 
> In my testing of .net winforms on windows i received a lot of gdi+ 
> object busy errors when i was testing a multithreaded app, regardless of 
> what thread the form was 'created' in (what thread the form was shown in 
> may have been a factor).This only happened on Win32, and caused 
> crashes in the apps when it occurred.
> 
> If there really is an issue with gdi+ objects being busy because they 
> are being accessed from both threads, then perhaps (and i haven't looked 
> at the code yet) -- well, perhaps the calls to gdi+ should be made 
> thread safe or at least thread "safer".  i.e. Something as simple as 
> creating a gdi+ lock or something similar, and before anything tries to 
> access gdi+ acquire the lock (at least on win32, which is the only place 
> this seemed to be an issue).  IT should be better to make an app wait 
> for a thread to finish using gdi+ (wait for the lock) then for otherwise 
> the application to crash altogether in a WmPaint command.
> 
> i know winforms, unofficially offically, is dead, but this seems like a 
> simple enough thing to try to correct.
> 
> -Rob
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/net-winforms-and-windows-tp4649922p4649924.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Threading and Winforms on Win32 only

[Stifu]

>From http://www.mono-project.com/FAQ:_Winforms:

"Mono's implementation of WinForms does not support Forms or Controls being
created on multiple threads. All Forms/Controls must be created on the same
thread.

Note this only applies to creation. You can still write multithreaded
applications that do work in other threads and modify already created
controls using Control.Invoke."


Robert Wilkens wrote
> 
> I'm getting the following exception sporadically while testing my sample 
> code that is used as a unit test (though i've never had it fail as a 
> unit test) both with and without my patch, even with mono 2.10.8 but 
> this is only happening on Windows...
> 
> System.MemberAccessException: Object is busy and cannot state allow this 
> operation [GDI+ status: ObjectBusy]
>at System.Drawing.GDIPlus.CheckStatus (Status status) [0x0] in 
> :0
>at System.Drawing.Graphics.FillRectangle (System.Drawing.Brush brush, 
> Int32 x, Int32 y, Int32 width, Int32 height) [0x0] in  unknown>:0
>at System.Drawing.Graphics.FillRectangle (System.Drawing.Brush brush, 
> Rectangle rect) [0x0] in :0
> ...all the way back to a WM_PAINT message...
> 
> I know this is probably happening because as someone told me recently 
> somewhere (I don't know if they were right) in WinForms only one thread 
> to control the interface, the rest are background processes..and in 
> this sample code, both threads create Windows..
> 
> ...but this works in microsoft.net
> ...and it works in X11 (at least with my patch) in mono
> 
> Also, while i seem to be able to build mono in cygwin from my
> git clone git@:robwilkens/mono
> tree but , i seem to have errors when i try to compile from my
> git clone git@:mono/mono
> tree.  Am I doing something wrong or is cygwin-based windows building 
> having issues (i ask because of the question asked on the list in the 
> last 24 hours about windows builds).
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Threading-and-Winforms-on-Win32-only-tp4649882p4649889.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch 7 has been pushed
(https://github.com/mono/mono/commit/1743a005ccdc0d8c93795e236d2a5a32043b722c).
Only one left.


Stifu wrote
> 
> I'll take care of this soon.
> 
> For the record, I'll go ahead and change the visibility of all new test
> classes and struct to private. I don't think they need to be public. If
> they actually do (to reuse them in other test classes later), then they
> should probably be moved to a helper class.
> 
> 
> Steven Boswell II wrote
>> 
>> Argh...I missed the all-important "dgv.Parent = form;" line.
>> Try this one.
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 10, 2012 2:47 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Test fails with .NET.
>> 
>> 1-1
>>   Expected: not null
>>   But was:  null
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Then here's the (hopefully) final version of patch #7.
>>> 
>>> Next will be a version of patch #2 with a unit test, and then...I'll
>>> have
>>> to work on the other bugs in my list. :-)
>>> 
>>> Steven Boswell
>>> 
>>> 
>>> 
>>>  From: Stifu <stifu@>
>>> To: mono-devel-list@.ximian 
>>> Sent: Sunday, June 10, 2012 1:45 PM
>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>  
>>> I don't know for sure, but if there seems to be no nicer way, let's go
>>> for
>>> that. It can still be changed later anyway. Other unit tests are
>>> certainly
>>> not perfect anyway, there are a couple that fail with .NET.
>>> 
>>> 
>>> Steven Boswell II wrote
>>>> I figured out why my unit-test project for patch #7 wasn't working in
>>>> MS
>>>> Windows.  Enclosed is a version of the project that works both under
>>>> Linux
>>>> and MS Windows.
>>>> 
>>>> My main question is, should I include all that MS-Windows-specific code
>>>> in
>>>> the actual unit test?  I found one other unit test
>>>> under Test/System.Windows.Forms that uses DllImport --
>>>> DateTimePickerTest.cs .  So there seems to be some precedent.
>>>> 
>>>> Let me know what the right thing to do is, and I'll submit a final
>>>> version
>>>> of patch #7.
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.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-tp4649620p4649857.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4649879.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I'll take care of this soon.

For the record, I'll go ahead and change the visibility of all new test
classes and struct to private. I don't think they need to be public. If they
actually do (to reuse them in other test classes later), then they should
probably be moved to a helper class.


Steven Boswell II wrote
> 
> Argh...I missed the all-important "dgv.Parent = form;" line.
> Try this one.
> 
> 
> ____
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 10, 2012 2:47 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Test fails with .NET.
> 
> 1-1
>   Expected: not null
>   But was:  null
> 
> 
> Steven Boswell II wrote
>> 
>> Then here's the (hopefully) final version of patch #7.
>> 
>> Next will be a version of patch #2 with a unit test, and then...I'll have
>> to work on the other bugs in my list. :-)
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 10, 2012 1:45 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> I don't know for sure, but if there seems to be no nicer way, let's go
>> for
>> that. It can still be changed later anyway. Other unit tests are
>> certainly
>> not perfect anyway, there are a couple that fail with .NET.
>> 
>> 
>> Steven Boswell II wrote
>>> I figured out why my unit-test project for patch #7 wasn't working in MS
>>> Windows.  Enclosed is a version of the project that works both under
>>> Linux
>>> and MS Windows.
>>> 
>>> My main question is, should I include all that MS-Windows-specific code
>>> in
>>> the actual unit test?  I found one other unit test
>>> under Test/System.Windows.Forms that uses DllImport --
>>> DateTimePickerTest.cs .  So there seems to be some precedent.
>>> 
>>> Let me know what the right thing to do is, and I'll submit a final
>>> version
>>> of patch #7.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4649857.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649864.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Test fails with .NET.

1-1
  Expected: not null
  But was:  null


Steven Boswell II wrote
> 
> Then here's the (hopefully) final version of patch #7.
> 
> Next will be a version of patch #2 with a unit test, and then...I'll have
> to work on the other bugs in my list. :-)
> 
> Steven Boswell
> 
> 
> ________
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 10, 2012 1:45 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> I don't know for sure, but if there seems to be no nicer way, let's go for
> that. It can still be changed later anyway. Other unit tests are certainly
> not perfect anyway, there are a couple that fail with .NET.
> 
> 
> Steven Boswell II wrote
>> I figured out why my unit-test project for patch #7 wasn't working in MS
>> Windows.  Enclosed is a version of the project that works both under
>> Linux
>> and MS Windows.
>> 
>> My main question is, should I include all that MS-Windows-specific code
>> in
>> the actual unit test?  I found one other unit test
>> under Test/System.Windows.Forms that uses DllImport --
>> DateTimePickerTest.cs .  So there seems to be some precedent.
>> 
>> Let me know what the right thing to do is, and I'll submit a final
>> version
>> of patch #7.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649857.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I don't know for sure, but if there seems to be no nicer way, let's go for
that. It can still be changed later anyway. Other unit tests are certainly
not perfect anyway, there are a couple that fail with .NET.


Steven Boswell II wrote
> 
> I figured out why my unit-test project for patch #7 wasn't working in MS
> Windows.  Enclosed is a version of the project that works both under Linux
> and MS Windows.
> 
> My main question is, should I include all that MS-Windows-specific code in
> the actual unit test?  I found one other unit test
> under Test/System.Windows.Forms that uses DllImport --
> DateTimePickerTest.cs .  So there seems to be some precedent.
> 
> Let me know what the right thing to do is, and I'll submit a final version
> of patch #7.
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649855.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch 1 is finally in
(https://github.com/mono/mono/commit/f9bea537f1ac41753f2204b8528a6292bb547111).
Made minor changes to the tests (in particular, made the ECST_Record class
private, and renamed it to EcstRecord to comply with naming guidelines).

I was indeed still using the old patch / unit tests, though I thought I had
the new ones, hence the confusion.

Thanks!


Stifu wrote
> 
> Patch 9 has been slam dunked
> (https://github.com/mono/mono/commit/33831c2a77cd6a7369051022df385de29f3970a6).
> Thanks for the quick patch.
> 
> 
> Steven Boswell II wrote
>> 
>> Enclosed is a new patch, one that fixes the differences in DataGridView's
>> firing of SelectionChanged events between .NET and Mono, and adjusts the
>> unit test to deal with the corrected behavior.
>> Also enclosed is a project containing the unit test code, so that one can
>> verify it under .NET, or watch it fail under the unpatched Mono.
>> Hopefully this patch is a slam dunk. :-)
>> 
>> Steven Boswell
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4649851.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] I think i've fixed the whitespace

[Stifu]

"I started building all of mono on cygwin, should i expect problems?"

Not especially, it's just going to take a while if you do it each time.

By the way, I don't have a Mac, so I won't be able to review your
Mac-related patches.


Rob Wilkens wrote
> 
> I started building all of mono on cygwin, should i expect problems?
> 
> I'm working on my mac at the moment, autogen complained that it needed get
> text so i downloaded and am installing/building-from-scratch that now.
> 
> Thanks
> Rob
> 
> On Jun 10, 2012, at 8:34 AM, Stifu wrote:
> 
>> Yes, if you change the driver parts, you should test on the concerned OS.
>> 
>> With cygwin, are you building all of Mono, or just the assembly you need?
>> 
>> 
>> Rob Wilkens wrote
>>> 
>>> Thanks - if you get the time, great, if not, it's ok.
>>> 
>>> In my original commit, I made changes to:
>>> XplatUICarbon.cs - so I probably should test on my mac
>>> and
>>> XplatUIWin32.cs - and i probably should test on windows 7
>>> 
>>> While i didn't change interfacing with the display managers, only calls
>>> to
>>> the idle event handler, I think that it would be wise to test.
>>> 
>>> I've already got the cygwin thing building, buggy or not, so i'm hoping
>>> just to let that go.  That's running in a virtual machine in Linux
>>> (Windows 7 in VirtualBox).  On My Mac upstairs now (not a laptop) I'm
>>> downloading from github (just sent my ssh key over so i could).  I will
>>> try to start a build on the mac today too.  No promises on whether
>>> either
>>> of these finish in reasonable time because both systems go to 'sleep'
>>> often (the mac automatically, and the laptop, when i close the lid). 
>>> The
>>> cygwin build seems slow, not sure what to expect from the mac.
>>> 
>>> -Rob
>>> 
>>> 
>>> On Jun 10, 2012, at 8:10 AM, Stifu wrote:
>>> 
>>>> I might be able to look at your fixes at some point, but no promises.
>>>> 
>>>> Testing only on X11 isn't an issue for most changes.
>>>> 
>>>> By the way, I'm a Windows user but don't bother with cygwin anymore. I
>>>> just
>>>> can't stand that thing. I just grab the sources from Git and build them
>>>> with
>>>> my IDE (that requires fixing some references first, for WinForms).
>>>> 
>>>> Carbon is what's used by the Mac WinForms driver. For the record, the
>>>> Carbon
>>>> driver is full of bugs that aren't there on Windows or Linux.
>>>> 
>>>> 
>>>> Rob Wilkens wrote
>>>>> 
>>>>> Ok, I've corrected the Whitespace issues...  You will only see the 
>>>>> changes in pull request one of two because pull request 2 is on a 
>>>>> different branch even though it contains some of the same commits.
>>>>> 
>>>>> I've also now labelled my pull requests in the sequence they are 
>>>>> intended to come in..
>>>>> 
>>>>> I know my first three pull requests were pulled in by the infamous 
>>>>> Miguel Di Icaza, whom i heard of years ago before i was even a mono 
>>>>> user.  Not sure if i  need to wait for him to have free time to review 
>>>>> these changes, and i understand he's busy so i'm not rushing anything.
>>>>> 
>>>>> My code was only tested on X11, is that an issue?  If so, i started a 
>>>>> build on Win32 (With CygWin) and may be able to test on my Mac 
>>>>> afterwards too.  I'm not sure about other platforms (what's a
>>>>> 'carbon').
>>>>> 
>>>>> -Rob
>>>>> ___
>>>>> Mono-devel-list mailing list
>>>>> Mono-devel-list@.ximian
>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> View this message in context:
>>>> http://mono.1490590.n4.nabble.com/I-think-i-ve-fixed-the-whitespace-tp4649843p4649844.html
>>>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>>>> ___
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list@.ximian
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> 
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.ximian
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> 
>> 
>> 
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/I-think-i-ve-fixed-the-whitespace-tp4649843p4649846.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

--
View this message in context: 
http://mono.1490590.n4.nabble.com/I-think-i-ve-fixed-the-whitespace-tp4649843p4649848.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] I think i've fixed the whitespace

[Stifu]

Yes, if you change the driver parts, you should test on the concerned OS.

With cygwin, are you building all of Mono, or just the assembly you need?


Rob Wilkens wrote
> 
> Thanks - if you get the time, great, if not, it's ok.
> 
> In my original commit, I made changes to:
> XplatUICarbon.cs - so I probably should test on my mac
> and
> XplatUIWin32.cs - and i probably should test on windows 7
> 
> While i didn't change interfacing with the display managers, only calls to
> the idle event handler, I think that it would be wise to test.
> 
> I've already got the cygwin thing building, buggy or not, so i'm hoping
> just to let that go.  That's running in a virtual machine in Linux
> (Windows 7 in VirtualBox).  On My Mac upstairs now (not a laptop) I'm
> downloading from github (just sent my ssh key over so i could).  I will
> try to start a build on the mac today too.  No promises on whether either
> of these finish in reasonable time because both systems go to 'sleep'
> often (the mac automatically, and the laptop, when i close the lid).  The
> cygwin build seems slow, not sure what to expect from the mac.
> 
> -Rob
> 
> 
> On Jun 10, 2012, at 8:10 AM, Stifu wrote:
> 
>> I might be able to look at your fixes at some point, but no promises.
>> 
>> Testing only on X11 isn't an issue for most changes.
>> 
>> By the way, I'm a Windows user but don't bother with cygwin anymore. I
>> just
>> can't stand that thing. I just grab the sources from Git and build them
>> with
>> my IDE (that requires fixing some references first, for WinForms).
>> 
>> Carbon is what's used by the Mac WinForms driver. For the record, the
>> Carbon
>> driver is full of bugs that aren't there on Windows or Linux.
>> 
>> 
>> Rob Wilkens wrote
>>> 
>>> Ok, I've corrected the Whitespace issues...  You will only see the 
>>> changes in pull request one of two because pull request 2 is on a 
>>> different branch even though it contains some of the same commits.
>>> 
>>> I've also now labelled my pull requests in the sequence they are 
>>> intended to come in..
>>> 
>>> I know my first three pull requests were pulled in by the infamous 
>>> Miguel Di Icaza, whom i heard of years ago before i was even a mono 
>>> user.  Not sure if i  need to wait for him to have free time to review 
>>> these changes, and i understand he's busy so i'm not rushing anything.
>>> 
>>> My code was only tested on X11, is that an issue?  If so, i started a 
>>> build on Win32 (With CygWin) and may be able to test on my Mac 
>>> afterwards too.  I'm not sure about other platforms (what's a 'carbon').
>>> 
>>> -Rob
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.ximian
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> 
>> 
>> 
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/I-think-i-ve-fixed-the-whitespace-tp4649843p4649844.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/I-think-i-ve-fixed-the-whitespace-tp4649843p4649846.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] I think i've fixed the whitespace

[Stifu]

I might be able to look at your fixes at some point, but no promises.

Testing only on X11 isn't an issue for most changes.

By the way, I'm a Windows user but don't bother with cygwin anymore. I just
can't stand that thing. I just grab the sources from Git and build them with
my IDE (that requires fixing some references first, for WinForms).

Carbon is what's used by the Mac WinForms driver. For the record, the Carbon
driver is full of bugs that aren't there on Windows or Linux.


Rob Wilkens wrote
> 
> Ok, I've corrected the Whitespace issues...  You will only see the 
> changes in pull request one of two because pull request 2 is on a 
> different branch even though it contains some of the same commits.
> 
> I've also now labelled my pull requests in the sequence they are 
> intended to come in..
> 
> I know my first three pull requests were pulled in by the infamous 
> Miguel Di Icaza, whom i heard of years ago before i was even a mono 
> user.  Not sure if i  need to wait for him to have free time to review 
> these changes, and i understand he's busy so i'm not rushing anything.
> 
> My code was only tested on X11, is that an issue?  If so, i started a 
> build on Win32 (With CygWin) and may be able to test on my Mac 
> afterwards too.  I'm not sure about other platforms (what's a 'carbon').
> 
> -Rob
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/I-think-i-ve-fixed-the-whitespace-tp4649843p4649844.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch 9 has been slam dunked
(https://github.com/mono/mono/commit/33831c2a77cd6a7369051022df385de29f3970a6).
Thanks for the quick patch.


Steven Boswell II wrote
> 
> Enclosed is a new patch, one that fixes the differences in DataGridView's
> firing of SelectionChanged events between .NET and Mono, and adjusts the
> unit test to deal with the corrected behavior.
> Also enclosed is a project containing the unit test code, so that one can
> verify it under .NET, or watch it fail under the unpatched Mono.
> Hopefully this patch is a slam dunk. :-)
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649842.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I'm happy to help.

I think you forgot the attachment.


Steven Boswell II wrote
> 
> Thank you!  This is exactly what I wanted to accomplish this weekend. :-)
> 
> Enclosed is a version of DgvTest I put together from the unit test.
> It puts up an assertion dialog with unpatched Mono, but not with patched
> Mono, nor with .NET under MS Windows.
> 
> See how it works for you.
> 
> Steven Boswell
> 
> 
> ________
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 9, 2012 12:41 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Patch 4 is in
> (https://github.com/mono/mono/commit/ecd410269466799c8bde71fc55ea9bf2a052c364).
> Cheers.
> 
> I'll spend some more time on patch 1 to see if I can figure out what's
> wrong.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649832.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch 4 is in
(https://github.com/mono/mono/commit/ecd410269466799c8bde71fc55ea9bf2a052c364).
Cheers.

I'll spend some more time on patch 1 to see if I can figure out what's
wrong.


Steven Boswell II wrote
> 
> Maybe you're running an older version of my unit test, before I added code
> that ensured the event-handler was being called.  I've attached a fresh
> copy of patch #1.
> 
> Enclosed is a reworked version of patch #4, one whose behavior has been
> tested against .NET.  Apply the unit test patch, see that you get a unit
> test failure, then apply my patch, and see that the unit test no longer
> fails.  Also enclosed is a ComboBoxTest project containing the unit test,
> so you can run it under .NET easily.
> 
> Also, I noticed that bringing up a dialog box before calling
> Application.Run() tends to make Mono freak out.  Maybe that's the problem
> with your DgwTest project?  The enclosed ComboBoxTest project waits until
> the Form's Load event to bring up dialog boxes.
> 
> I will go and redo patch #3 so that it works under .NET, and try to come
> up with unit tests for patches 2 and 7.  Those require user
> interaction...if I can figure out how to fake a mouse click, I should be
> able to do this.  Looks like the accepted method is to create a subclass
> and then call OnMouseClick() directly.
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 9, 2012 9:34 AM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> "Um...you're not supposed to get the "Event handler!" message-box with an
> unpatched Mono.  The patch's main purpose is to make sure that event
> handler
> gets called.  Or do I misunderstand what you're saying?"
> 
> Then isn't the test wrong? If the event handler doesn't get executed, then
> the unit test still passes. I just tried commenting the event handler and
> run the test with .NET, and it passes.
> 
> By the way, I think there may have been issues with patch 3... Now the
> concerned 2 tests (SelectedColumnsTest and SelectedRowsTest) don't pass
> anymore with .NET, it seems.
> 
> I get: 1-14
>   Expected: 0
>   But was:  2
> 
> Can you confirm? I did stumble across this error while reviewing your
> patch,
> but then I thought it ended up passing. I must have made a mistake
> somewhere.
> 
> I didn't actually find your GitHub account, just referenced your e-mail
> address and that's it. :p
> C# Qt bindings is a cool project. I was gonna mention CXXI, but you
> already
> know about it.
> 
> 
> Steven Boswell II wrote
>> 
>> Um...you're not supposed to get the "Event handler!" message-box with an
>> unpatched Mono.  The patch's main purpose is to make sure that event
>> handler gets called.  Or do I misunderstand what you're saying?
>> 
>> Thanks for committing my other patch.  I had totally forgotten about my
>> account on GitHub.  Kudos for finding it. :-)
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Saturday, June 9, 2012 12:03 AM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> By "ran fine", do you mean you do get the "Event handler!" message box?
>> Because I don't, with Mono (unpatched).
>> 
>> Patch 8 pushed, slightly reformatted
>> (https://github.com/mono/mono/commit/641ae7303320c2bad8ff83f9b5f9fc0d285b6b0e).
>> Thanks.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4649820.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649826.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Patch 5 has been pushed
(https://github.com/mono/mono/commit/f2b0672d8c65ccc08582d1b24783630e1237bcef).
Thanks again.

Now, let's see...

Patch 1: under review
Patch 2: waiting for unit test
Patch 3: pushed, but with one remaining problem
Patch 4: waiting for unit test
Patch 5: pushed
Patch 6: pushed
Patch 7: waiting for unit test
Patch 8: pushed


Steven Boswell II wrote
> 
> Attached is my patch #5, which is the same as it was before, except now
> I've included a unit-test patch.
> 
> First, apply the unit-test patch, run the unit test, and notice that you
> get a failed test that you didn't get before -- the throwing of an
> ArgumentOutOfRangeException.
> Then, apply the patch, and run the unit test again, and notice that the
> test no longer fails.
> 
> Hopefully this is enough to get the change accepted quickly & committed to
> git. :-)
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649821.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

"Um...you're not supposed to get the "Event handler!" message-box with an
unpatched Mono.  The patch's main purpose is to make sure that event handler
gets called.  Or do I misunderstand what you're saying?"

Then isn't the test wrong? If the event handler doesn't get executed, then
the unit test still passes. I just tried commenting the event handler and
run the test with .NET, and it passes.

By the way, I think there may have been issues with patch 3... Now the
concerned 2 tests (SelectedColumnsTest and SelectedRowsTest) don't pass
anymore with .NET, it seems.

I get: 1-14
  Expected: 0
  But was:  2

Can you confirm? I did stumble across this error while reviewing your patch,
but then I thought it ended up passing. I must have made a mistake
somewhere.

I didn't actually find your GitHub account, just referenced your e-mail
address and that's it. :p
C# Qt bindings is a cool project. I was gonna mention CXXI, but you already
know about it.


Steven Boswell II wrote
> 
> Um...you're not supposed to get the "Event handler!" message-box with an
> unpatched Mono.  The patch's main purpose is to make sure that event
> handler gets called.  Or do I misunderstand what you're saying?
> 
> Thanks for committing my other patch.  I had totally forgotten about my
> account on GitHub.  Kudos for finding it. :-)
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 9, 2012 12:03 AM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> By "ran fine", do you mean you do get the "Event handler!" message box?
> Because I don't, with Mono (unpatched).
> 
> Patch 8 pushed, slightly reformatted
> (https://github.com/mono/mono/commit/641ae7303320c2bad8ff83f9b5f9fc0d285b6b0e).
> Thanks.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649820.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

By "ran fine", do you mean you do get the "Event handler!" message box?
Because I don't, with Mono (unpatched).

Patch 8 pushed, slightly reformatted
(https://github.com/mono/mono/commit/641ae7303320c2bad8ff83f9b5f9fc0d285b6b0e).
Thanks.

Rob: WPF is no more open than WinForms, and both start with "Windows"
anyway.
By the way, as far as I'm concerned, WPF is pretty much dead (possibly
more-so than WinForms). At first, the Mono team didn't want to implement it
because it was too big, too complex, and they just didn't have enough
resources to do it. At this point, I think it's no longer worth
reimplementing even if they had the resources for it.


Steven Boswell II wrote
> 
> Well, that sample ran fine on my side, so I guess we have a problem.  Any
> idea how to resolve this issue?
> 
> Re: using themes...sure, that's a long-term solution, but since
> mono-winforms is no longer officially supported, and Microsoft has moved
> on to WPF, I'd say the chances of this happening are between slim and
> none.  Still...enclosed is a newer version of the same patch, one that
> uses ThemeEngine.Current.ColorGrayText instead.
> 
> Please let me know if there's anything else I need to do on this bug,
> especially since it's a visual change & so it's pretty much impossible to
> make a unit test for it.
> 
> BTW, I couldn't find any bug reports for this issue.
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Thursday, June 7, 2012 11:13 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> The one solution I uploaded doesn't have the hang, but it has the
> never-called event handler.
> I haven't tried anything else since then.
> 
> I did notice issues with the disabled look of some controls, too (probably
> have some related bug reports still up on Novell bugzilla). I think this
> should all be handled within System.Windows.Forms.Theming, but it's not
> always the case with existing code. Ideally, we should gradually move
> theme-related code from System.Windows.Forms to
> System.Windows.Forms.Theming. Just saying that for the information, not
> saying we should do both fixing and moving things in the same patch.
> 
> 
> Steven Boswell II wrote
>> 
>> Stifu, did you have any better luck running your DgwTest, or my patch #1,
>> successfully?  I was never able to reproduce the hang you described.
>> 
>> I will hopefully have time and energy this weekend to write unit tests
>> for
>> more of the patches I sent earlier.
>> 
>> I want to fix the appearance of disabled ListBox controls -- currently,
>> they don't look any different than enabled ListBox controls.  Digging
>> around the other controls, it seems that most of them simply draw the
>> text
>> with the GrayText color, they don't do anything fancier than that to
>> implement the disabled look.  Enclosed is a patch that does that for
>> ListBox.  If you know of a better way to accomplish this effect, I'm all
>> ears.
>> 
>> Steven Boswell
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.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-tp4649620p4649781.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649809.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

The one solution I uploaded doesn't have the hang, but it has the
never-called event handler.
I haven't tried anything else since then.

I did notice issues with the disabled look of some controls, too (probably
have some related bug reports still up on Novell bugzilla). I think this
should all be handled within System.Windows.Forms.Theming, but it's not
always the case with existing code. Ideally, we should gradually move
theme-related code from System.Windows.Forms to
System.Windows.Forms.Theming. Just saying that for the information, not
saying we should do both fixing and moving things in the same patch.


Steven Boswell II wrote
> 
> Stifu, did you have any better luck running your DgwTest, or my patch #1,
> successfully?  I was never able to reproduce the hang you described.
> 
> I will hopefully have time and energy this weekend to write unit tests for
> more of the patches I sent earlier.
> 
> I want to fix the appearance of disabled ListBox controls -- currently,
> they don't look any different than enabled ListBox controls.  Digging
> around the other controls, it seems that most of them simply draw the text
> with the GrayText color, they don't do anything fancier than that to
> implement the disabled look.  Enclosed is a patch that does that for
> ListBox.  If you know of a better way to accomplish this effect, I'm all
> ears.
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649781.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

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@.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@.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.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

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...


Steven Boswell II wrote
> 
> Re: patch 1, I have an idea.  Take the unit-test code and run it as an
> application, and put a call to "Console.WriteLine
> (Environment.StackTrace)" in the event-handler.  If the
> EditingControlShowing event isn't being called from my patched code, I'd
> like to know where it's being called from.
> 
> And I'll go ahead and write unit tests for patches 2, 4, 5, and 7, if I
> can figure out some.
> 
> Steven Boswell
> 
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 3, 2012 11:03 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> "Also, as far as I can tell, patches 2, 4, and 5 are really small, and
> defy
> the creation of unit tests anyway -- it should be enough for someone
> knowledgeable about WinForms to decide if these changes are correct."
> 
> No matter how small these patches are, and no matter if they're obviously
> correct. If something can be tested, it should be tested. :) I've
> committed
> several one-line patches, each of them coming with their unit test, so
> I've
> spent more time writing tests than fixes.
> 
> This also ensures that no one breaks the tests / feature later on, by
> working on the code, trying to fix another bug, moving code around,
> refactoring... I guess you could easily come up with various stats showing
> that fixes without tests are XX% more likely to get broken again later.
> Tests also ensure we're on the same level across all OSes or machine type
> (for example, we could imagine patch number X does not fix the bug on Mac
> for some reason, and so this problem would be detected thanks to the
> test).
> To sum things up, tests are what makes a framework mature and reliable.
> Without them, you're just applying temporary patches.
> 
> I'll check all of this out when I have more time. And I don't mind coming
> up
> with the tests myself, if I can figure out something. As for patch 1, I'll
> just check if I can reproduce the bug on Linux.
> 
> 
> Steven Boswell II wrote
>> 
>> Yes, the unit test fails for me without my patch -- I made darn sure of
>> that after wasting your time. ;-)  The additions to my unit test ensure
>> that the EditingControlShowing event is getting called.  Without my
>> patch,
>> Mono never calls that event.  So if it's succeeding for you...I'm totally
>> lost.
>> 
>> Let me know if you need any more info, or any other changes, so that you
>> can commit patch 3.
>> 
>> Also, as far as I can tell, patches 2, 4, and 5 are really small, and
>> defy
>> the creation of unit tests anyway -- it should be enough for someone
>> knowledgeable about WinForms to decide if these changes are correct.  I
>> know that it brings Mono's behavior in line with .NET.  Please let me
>> know
>> if I should do anything else with these patches.
>> 
>> For the time being, I seem to be out of bugs, and am working on
>> annoyances...that's a good sign. :-)  Enclosed is my latest change;
>> there's no unit test because it requires user interaction to even see the
>> problem.  Before, getting a data-grid-view combo-box to drop down its
>> menu
>> took three mouse-clicks.  Now, it only takes one.  This brings the
>> behavior in line with .NET.  Let me know what you think of this change.
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 3, 2012 3:20 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Nope, I still can't get the tests to fail. :\
>> Does it fail for you (when unpatched)? It's possible the bug doesn't
>> affect
>> Mono on Windows, but I'd like to make sure of it.
>> 
>> Can't see anything wrong with patch 3 at first sight.
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Sorry about that.  I've added code to make sure the event-handler gets
>>> called.  Enclosed is another attempt.
>>> Also, do you have any further comments about patch 3?  For your
>>> convenience, I've enclosed another copy.
>>> 
>>> 
>>> 
>>>  From: Stifu <stifu@>
&g

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I took your test, and turned it into a console application, and did what you
suggested. It seems it just hangs Mono. I tried the same, but making it a
WinForms app this time, and added a message box in the event handler. The
message box shows up on .NET (4 times) but not on Mono.

Attaching the WinForms app here.

http://mono.1490590.n4.nabble.com/file/n4649703/DgwTest.zip DgwTest.zip 


Steven Boswell II wrote
> 
> Re: patch 1, I have an idea.  Take the unit-test code and run it as an
> application, and put a call to "Console.WriteLine
> (Environment.StackTrace)" in the event-handler.  If the
> EditingControlShowing event isn't being called from my patched code, I'd
> like to know where it's being called from.
> 
> And I'll go ahead and write unit tests for patches 2, 4, 5, and 7, if I
> can figure out some.
> 
> Steven Boswell
> 
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 3, 2012 11:03 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> "Also, as far as I can tell, patches 2, 4, and 5 are really small, and
> defy
> the creation of unit tests anyway -- it should be enough for someone
> knowledgeable about WinForms to decide if these changes are correct."
> 
> No matter how small these patches are, and no matter if they're obviously
> correct. If something can be tested, it should be tested. :) I've
> committed
> several one-line patches, each of them coming with their unit test, so
> I've
> spent more time writing tests than fixes.
> 
> This also ensures that no one breaks the tests / feature later on, by
> working on the code, trying to fix another bug, moving code around,
> refactoring... I guess you could easily come up with various stats showing
> that fixes without tests are XX% more likely to get broken again later.
> Tests also ensure we're on the same level across all OSes or machine type
> (for example, we could imagine patch number X does not fix the bug on Mac
> for some reason, and so this problem would be detected thanks to the
> test).
> To sum things up, tests are what makes a framework mature and reliable.
> Without them, you're just applying temporary patches.
> 
> I'll check all of this out when I have more time. And I don't mind coming
> up
> with the tests myself, if I can figure out something. As for patch 1, I'll
> just check if I can reproduce the bug on Linux.
> 
> 
> Steven Boswell II wrote
>> 
>> Yes, the unit test fails for me without my patch -- I made darn sure of
>> that after wasting your time. ;-)  The additions to my unit test ensure
>> that the EditingControlShowing event is getting called.  Without my
>> patch,
>> Mono never calls that event.  So if it's succeeding for you...I'm totally
>> lost.
>> 
>> Let me know if you need any more info, or any other changes, so that you
>> can commit patch 3.
>> 
>> Also, as far as I can tell, patches 2, 4, and 5 are really small, and
>> defy
>> the creation of unit tests anyway -- it should be enough for someone
>> knowledgeable about WinForms to decide if these changes are correct.  I
>> know that it brings Mono's behavior in line with .NET.  Please let me
>> know
>> if I should do anything else with these patches.
>> 
>> For the time being, I seem to be out of bugs, and am working on
>> annoyances...that's a good sign. :-)  Enclosed is my latest change;
>> there's no unit test because it requires user interaction to even see the
>> problem.  Before, getting a data-grid-view combo-box to drop down its
>> menu
>> took three mouse-clicks.  Now, it only takes one.  This brings the
>> behavior in line with .NET.  Let me know what you think of this change.
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 3, 2012 3:20 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Nope, I still can't get the tests to fail. :\
>> Does it fail for you (when unpatched)? It's possible the bug doesn't
>> affect
>> Mono on Windows, but I'd like to make sure of it.
>> 
>> Can't see anything wrong with patch 3 at first sight.
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Sorry about that.  I've added code to make sure the event-handler gets
>>> called.  Enclosed is another attempt.
>>> Also, do you have any further comments about patch 3?  For your
>>> conv

Re: [Mono-dev] DataGrid changes recently?

[Stifu]

Backporting is about applying patches to older branches.
For example, if you commit a fix to master, it won't be available in the
next Mono 2.10.x release, because Mono 2.10 is on its own branch (which was
created / branched from master a while ago), like each major version. So, if
your fix was really important, you'd want to backport it to the 2.10 branch.


Rob Wilkens wrote
> 
> I just read the whole document, and decided to bookmark it, I'll try to 
> refer to it often, it's a well written document.  The only part i was a 
> little lost on was re: git and backporting.  I don't even know what it 
> means to backport, but then i'm new to git in general.
> 
> I understand very little of git short of:
> git clone.. (to get started)
> git status (to list changed files)
> git add (to mark a file as part of change)
> git diff --staged (to see changes before committing)
> git commit... (to finalize changes and put a description on them)
> git push  . (to send them to github, at least i think that's what 
> this does)
> and whatever i can figure out by blindly clicking around on github.com.
> 
> -Rob
> 
> On 06/03/2012 06:37 PM, Stifu wrote:
>> By the way, make sure to check out the coding guidelines:
>> http://www.mono-project.com/Coding_Guidelines
>>
>> I'm bringing that up because I saw code that needed more love for spaces.
>> a=b; should be a = b;
>> if (a==b) should be if (a == b), etc
>>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/DataGrid-changes-recently-tp4649678p4649692.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

"Also, as far as I can tell, patches 2, 4, and 5 are really small, and defy
the creation of unit tests anyway -- it should be enough for someone
knowledgeable about WinForms to decide if these changes are correct."

No matter how small these patches are, and no matter if they're obviously
correct. If something can be tested, it should be tested. :) I've committed
several one-line patches, each of them coming with their unit test, so I've
spent more time writing tests than fixes.

This also ensures that no one breaks the tests / feature later on, by
working on the code, trying to fix another bug, moving code around,
refactoring... I guess you could easily come up with various stats showing
that fixes without tests are XX% more likely to get broken again later.
Tests also ensure we're on the same level across all OSes or machine type
(for example, we could imagine patch number X does not fix the bug on Mac
for some reason, and so this problem would be detected thanks to the test).
To sum things up, tests are what makes a framework mature and reliable.
Without them, you're just applying temporary patches.

I'll check all of this out when I have more time. And I don't mind coming up
with the tests myself, if I can figure out something. As for patch 1, I'll
just check if I can reproduce the bug on Linux.


Steven Boswell II wrote
> 
> Yes, the unit test fails for me without my patch -- I made darn sure of
> that after wasting your time. ;-)  The additions to my unit test ensure
> that the EditingControlShowing event is getting called.  Without my patch,
> Mono never calls that event.  So if it's succeeding for you...I'm totally
> lost.
> 
> Let me know if you need any more info, or any other changes, so that you
> can commit patch 3.
> 
> Also, as far as I can tell, patches 2, 4, and 5 are really small, and defy
> the creation of unit tests anyway -- it should be enough for someone
> knowledgeable about WinForms to decide if these changes are correct.  I
> know that it brings Mono's behavior in line with .NET.  Please let me know
> if I should do anything else with these patches.
> 
> For the time being, I seem to be out of bugs, and am working on
> annoyances...that's a good sign. :-)  Enclosed is my latest change;
> there's no unit test because it requires user interaction to even see the
> problem.  Before, getting a data-grid-view combo-box to drop down its menu
> took three mouse-clicks.  Now, it only takes one.  This brings the
> behavior in line with .NET.  Let me know what you think of this change.
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 3, 2012 3:20 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Nope, I still can't get the tests to fail. :\
> Does it fail for you (when unpatched)? It's possible the bug doesn't
> affect
> Mono on Windows, but I'd like to make sure of it.
> 
> Can't see anything wrong with patch 3 at first sight.
> 
> 
> Steven Boswell II wrote
>> 
>> Sorry about that.  I've added code to make sure the event-handler gets
>> called.  Enclosed is another attempt.
>> Also, do you have any further comments about patch 3?  For your
>> convenience, I've enclosed another copy.
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 3, 2012 8:58 AM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> I checked out your unit tests for patch 1.
>> On Mono on Windows, they already pass even without your patch. I cannot
>> check Linux right now.
>> 
>> Have you double checked that your tests fail without your patch?
>> Thanks for clearing that up.
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Crap, I didn't notice that InitializeEditingControl() was public.
>>> 
>>> My whole motivation for splitting up that method was to make sure that
>>> the
>>> style modified by the EditingControlShowing event-handler would be
>>> applied
>>> to the cell.  But that's done a few lines later, by the call to
>>> "dgvEditingControl.ApplyCellStyleToEditingControl (style)".  Argh.
>>> 
>>> In any case, enclosed is a much simpler patch that doesn't change the
>>> public API.  Hopefully I didn't do anything else stupid -- I'm truly not
>>> trying to waste your time. ;-)
>>> 
>>> Steven Boswell
>>> 
>>> 
>>> 
>>>  From: Stifu <stifu@&

Re: [Mono-dev] DataGrid changes recently?

[Stifu]

"Also, When i committed this fix, i noticed that it went on to my 
previous pull request...  Should i worry about having too many commits 
that are unrelated in one pull request, or can they just pull through 
the changes they want if they're not comfortable with them?"

I guess they'll manage. If not, they'll probably contact you.
The noise does add confusion, though... So it's better to take your time, to
make as few commits as possible.

By the way, make sure to check out the coding guidelines:
http://www.mono-project.com/Coding_Guidelines

I'm bringing that up because I saw code that needed more love for spaces.
a=b; should be a = b;
if (a==b) should be if (a == b), etc


Rob Wilkens wrote
> 
> On 06/03/2012 05:30 PM, Stifu wrote:
>> If this particular bug hasn't been reported, then yeah, go ahead and
>> report
>> it.
>> And whoever was assigned to WinForms bugs in 2006, don't expect anything
>> to
>> get done (obviously, after 6 years...). The Mono team announced they
>> wouldn't work on WinForms anymore, and that it was up to the community to
>> maintain it.
> 
> BTW- thanks for sharing that they stopped official support for it, so 
> that someone like me feels like i'm not stepping on someone's feet by 
> working on these issues..
> 
> Also, When i committed this fix, i noticed that it went on to my 
> previous pull request...  Should i worry about having too many commits 
> that are unrelated in one pull request, or can they just pull through 
> the changes they want if they're not comfortable with them?
> 
> Thanks!
> Rob
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

--
View this message in context: 
http://mono.1490590.n4.nabble.com/DataGrid-changes-recently-tp4649678p4649685.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Nope, I still can't get the tests to fail. :\
Does it fail for you (when unpatched)? It's possible the bug doesn't affect
Mono on Windows, but I'd like to make sure of it.

Can't see anything wrong with patch 3 at first sight.


Steven Boswell II wrote
> 
> Sorry about that.  I've added code to make sure the event-handler gets
> called.  Enclosed is another attempt.
> Also, do you have any further comments about patch 3?  For your
> convenience, I've enclosed another copy.
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 3, 2012 8:58 AM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> I checked out your unit tests for patch 1.
> On Mono on Windows, they already pass even without your patch. I cannot
> check Linux right now.
> 
> Have you double checked that your tests fail without your patch?
> Thanks for clearing that up.
> 
> 
> Steven Boswell II wrote
>> 
>> Crap, I didn't notice that InitializeEditingControl() was public.
>> 
>> My whole motivation for splitting up that method was to make sure that
>> the
>> style modified by the EditingControlShowing event-handler would be
>> applied
>> to the cell.  But that's done a few lines later, by the call to
>> "dgvEditingControl.ApplyCellStyleToEditingControl (style)".  Argh.
>> 
>> In any case, enclosed is a much simpler patch that doesn't change the
>> public API.  Hopefully I didn't do anything else stupid -- I'm truly not
>> trying to waste your time. ;-)
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Sunday, June 3, 2012 1:33 AM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> This patch does not look good to me, because you're changing the public
>> API.
>> 
>> In DataGridViewCell, the InitializeEditingControl method expects 2
>> parameters rather than 3 after your patch, which means we're breaking the
>> API and are no longer compatible with .NET.
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Argh...one more dumb oversight in my change.
>>> Enclosed is ANOTHER version of the patch.
>>> I wish I had the luxury of working on my hobbies when I was awake and
>>> energetic. ;-)
>>> 
>>> Steven Boswell
>>> 
>>> 
>>> 
>>>  From: Steven Boswell II <ulatekh@>
>>> To: "mono-devel-list@.ximian" <mono-devel-list@.ximian> 
>>> Sent: Saturday, June 2, 2012 7:58 PM
>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>  
>>> 
>>> Rob, you're my hero.  Very few tests in DataGridViewTest.cs create a
>>> Form,
>>> but most of the ones that do involve data binding.
>>> I added a Form to my test, and it succeeded immediately.  Apparently,
>>> Application.Run() isn't necessary, but that was a good idea.
>>> Enclosed is a revised patch, for review by the Powers That Be.
>>> 
>>> Steven Boswell
>>> 
>>> 
>>> 
>>>  From: Rob Wilkens <robwilkens@>
>>> To: mono-devel-list@.ximian 
>>> Sent: Saturday, June 2, 2012 6:46 PM
>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>  
>>> 
>>> On 06/02/2012 09:38 PM, Rob Wilkens wrote: 
>>> On 06/02/2012 08:55 PM, Steven Boswell II wrote: 
>>>>The EditingControlShowing event has to be called, and it has to be
called
>> after the control's contents have been initialized properly...that's not
>> really two separate issues.
>>>>>
>>>>>
>>>>>The enclosed patch is an updated version; in addition to having a unit
>> test, it fixes one additional bug revealed by my testing. Before,
>> DataGridViewComboBoxCell.InitializeEditingControl() was setting the
>> initial
>> value from the FormattedValue property, instead of
>> the initialFormattedValue
>> parameter.
>>>>>
>>>>>
>>>>>I tried to write an additional unit test that worked with bound data,
> but
>> for the life of me I can't figure out why it doesn't work.  I've done
>> data-binding with DataGridView before...it wasn't this mysterious.  In my
>> unit test, after I set the DataGridView's DataSource property, the
>> data-grid
>> doesn't initial

Re: [Mono-dev] DataGrid changes recently?

[Stifu]

If this particular bug hasn't been reported, then yeah, go ahead and report
it.
And whoever was assigned to WinForms bugs in 2006, don't expect anything to
get done (obviously, after 6 years...). The Mono team announced they
wouldn't work on WinForms anymore, and that it was up to the community to
maintain it.


Rob Wilkens wrote
> 
> I haven't pulled in the latest code changes, and i know there were some 
> recent patches on DataGridView but have there been any changes on
> DataGrid?
> 
> I was looking at the sample code in this closed bug:
> https://bugzilla.novell.com/show_bug.cgi?id=MONO79788
> 
> And it crashes on me if i click on the row with the arrow.
> 
> It doesn't do this in windows with the same binary in the same directory.
> 
> Before i submit a fix for this, presuming i actually find one, I need to 
> know if i should file a new bug report on this myself?  There were 
> related bug reports filed, all assigned to someone back around 2006, but 
> nothing that i saw said anything about a crash under these circumstances.
> 
> For reference, it crashed with the mono that came with ubuntu 12.04 and 
> my latest github builds (which may be _behind_ the main mono github a 
> little)...
> 
> Thanks!
> 
> Rob
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/DataGrid-changes-recently-tp4649678p4649680.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

I checked out your unit tests for patch 1.
On Mono on Windows, they already pass even without your patch. I cannot
check Linux right now.

Have you double checked that your tests fail without your patch?
Thanks for clearing that up.


Steven Boswell II wrote
> 
> Crap, I didn't notice that InitializeEditingControl() was public.
> 
> My whole motivation for splitting up that method was to make sure that the
> style modified by the EditingControlShowing event-handler would be applied
> to the cell.  But that's done a few lines later, by the call to
> "dgvEditingControl.ApplyCellStyleToEditingControl (style)".  Argh.
> 
> In any case, enclosed is a much simpler patch that doesn't change the
> public API.  Hopefully I didn't do anything else stupid -- I'm truly not
> trying to waste your time. ;-)
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Sunday, June 3, 2012 1:33 AM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> This patch does not look good to me, because you're changing the public
> API.
> 
> In DataGridViewCell, the InitializeEditingControl method expects 2
> parameters rather than 3 after your patch, which means we're breaking the
> API and are no longer compatible with .NET.
> 
> 
> Steven Boswell II wrote
>> 
>> Argh...one more dumb oversight in my change.
>> Enclosed is ANOTHER version of the patch.
>> I wish I had the luxury of working on my hobbies when I was awake and
>> energetic. ;-)
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Steven Boswell II <ulatekh@>
>> To: "mono-devel-list@.ximian" <mono-devel-list@.ximian> 
>> Sent: Saturday, June 2, 2012 7:58 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> 
>> Rob, you're my hero.  Very few tests in DataGridViewTest.cs create a
>> Form,
>> but most of the ones that do involve data binding.
>> I added a Form to my test, and it succeeded immediately.  Apparently,
>> Application.Run() isn't necessary, but that was a good idea.
>> Enclosed is a revised patch, for review by the Powers That Be.
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Rob Wilkens <robwilkens@>
>> To: mono-devel-list@.ximian 
>> Sent: Saturday, June 2, 2012 6:46 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> 
>> On 06/02/2012 09:38 PM, Rob Wilkens wrote: 
>> On 06/02/2012 08:55 PM, Steven Boswell II wrote: 
>>>The EditingControlShowing event has to be called, and it has to be called
> after the control's contents have been initialized properly...that's not
> really two separate issues.
>>>>
>>>>
>>>>The enclosed patch is an updated version; in addition to having a unit
> test, it fixes one additional bug revealed by my testing. Before,
> DataGridViewComboBoxCell.InitializeEditingControl() was setting the
> initial
> value from the FormattedValue property, instead of
> the initialFormattedValue
> parameter.
>>>>
>>>>
>>>>I tried to write an additional unit test that worked with bound data,
but
> for the life of me I can't figure out why it doesn't work.  I've done
> data-binding with DataGridView before...it wasn't this mysterious.  In my
> unit test, after I set the DataGridView's DataSource property, the
> data-grid
> doesn't initialize properly; instead of four rows, it ends up with one
> row,
> and all its cell values are null.  After beating my head against the wall
> for several hours, I'm perfectly happy to be told what a moron I am, if
> someone will just tell me why the EditingControlShowingTest_Bound test
> doesn't work. :-)
>>>>
>>>>
>>>>Steven Boswell
>>>>
>>>Not writing to call you a moron, I'm a newbie myself and i could
>>       be wrong...  But i copied and pasted your test code for
>>       EditingControlShowingTest_Bound into Visual Studio 2010, but
>>       rather than creating the DataGridVIew in code i placed it on the
>>       form and modified your code to use the one on the form...  And i
>>       disabled the asserts...  And from what i can tell it runs fine in
>>       both .net and mono (that is, the data grid view populates).
>>>
>>>One thing that I noticed about your code, though, is it depends on
>>       a 'showing' event..
>>>
>>>And i wonder if that means your

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

This patch does not look good to me, because you're changing the public API.

In DataGridViewCell, the InitializeEditingControl method expects 2
parameters rather than 3 after your patch, which means we're breaking the
API and are no longer compatible with .NET.


Steven Boswell II wrote
> 
> Argh...one more dumb oversight in my change.
> Enclosed is ANOTHER version of the patch.
> I wish I had the luxury of working on my hobbies when I was awake and
> energetic. ;-)
> 
> Steven Boswell
> 
> 
> 
>  From: Steven Boswell II 
> To: "mono-devel-list@.ximian"  
> Sent: Saturday, June 2, 2012 7:58 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> 
> Rob, you're my hero.  Very few tests in DataGridViewTest.cs create a Form,
> but most of the ones that do involve data binding.
> I added a Form to my test, and it succeeded immediately.  Apparently,
> Application.Run() isn't necessary, but that was a good idea.
> Enclosed is a revised patch, for review by the Powers That Be.
> 
> Steven Boswell
> 
> 
> 
>  From: Rob Wilkens 
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 2, 2012 6:46 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> 
> On 06/02/2012 09:38 PM, Rob Wilkens wrote: 
> On 06/02/2012 08:55 PM, Steven Boswell II wrote: 
>>The EditingControlShowing event has to be called, and it has to be called
after the control's contents have been initialized properly...that's not
really two separate issues.
>>>
>>>
>>>The enclosed patch is an updated version; in addition to having a unit
test, it fixes one additional bug revealed by my testing. Before,
DataGridViewComboBoxCell.InitializeEditingControl() was setting the initial
value from the FormattedValue property, instead of the initialFormattedValue
parameter.
>>>
>>>
>>>I tried to write an additional unit test that worked with bound data, but
for the life of me I can't figure out why it doesn't work.  I've done
data-binding with DataGridView before...it wasn't this mysterious.  In my
unit test, after I set the DataGridView's DataSource property, the data-grid
doesn't initialize properly; instead of four rows, it ends up with one row,
and all its cell values are null.  After beating my head against the wall
for several hours, I'm perfectly happy to be told what a moron I am, if
someone will just tell me why the EditingControlShowingTest_Bound test
doesn't work. :-)
>>>
>>>
>>>Steven Boswell
>>>
>>Not writing to call you a moron, I'm a newbie myself and i could
>   be wrong...  But i copied and pasted your test code for
>   EditingControlShowingTest_Bound into Visual Studio 2010, but
>   rather than creating the DataGridVIew in code i placed it on the
>   form and modified your code to use the one on the form...  And i
>   disabled the asserts...  And from what i can tell it runs fine in
>   both .net and mono (that is, the data grid view populates).
>>
>>One thing that I noticed about your code, though, is it depends on
>   a 'showing' event..
>>
>>And i wonder if that means your datagridview needs to be placed on
>   a form which is displayed, so that it is actually shown...
>>
>>i.e. change your code something like this:
>>
>>using (Form Form1=new Form()){
>>    Form1.Controls.Add(_dataGridView);//optionaly set sizeand
>   location of both gridview and form
>>    Form1.Show();
>>
>>    ... insert the rest of your code here  
>>}
>>
> Oh, and if i'm right, you might need the equivalent of an
> Application.Run(Form1) to process the events since you're listening for
> events, just don't forget to close Form1 or the Run loop might never end
> and your test can hang up with a displayed window...
> 
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649670.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

"I'm surprised no one else has thought of running Mono's unit tests against
.NET, given how useful that would be for ensuring that Mono is compatible."

Oh yes, you can do that. I must have misunderstood your question. As you
said "built-in", I thought you meant automatic, done in the Mono test suite,
or something. But you can just take the tests and manually run them with
.NET (as long as they don't also test internal stuff, but I'm not sure if or
where that happens).


Steven Boswell II wrote
> 
> Oops, sorry.  I'm just so used to using LINQ. :-)  I can rewrite that
> portion of the test without it.  When I saw that "make test" built
> something called "System.Windows.Forms_test_net_4_5.dll", and "make check"
> said it was running against "CLR Version: 4.0.30319.17020", I didn't think
> I was limited to 2.0 features.
> 
> I was just adding to an existing test, not really changing it.  It still
> tests what it did before, just more.  But I can go revert the
> test-identifiers I changed.
> 
> In any case, enclosed is an updated patch.
> 
> I'm surprised no one else has thought of running Mono's unit tests against
> .NET, given how useful that would be for ensuring that Mono is compatible.
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 2, 2012 1:09 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Hmm, I don't think the added dependency to System.Linq in the tests is OK.
> The whole thing is supposed to build and run with the .NET 2.0 profile.
> 
> Also, I could be wrong, but I think it's usually a bad idea to change
> existing tests (unless they're wrong). Just make new tests instead
> (SelectedRowsTest2(), or whatever). Can anyone confirm?
> 
> As explained here: http://www.mono-project.com/Test_Suite
> 
> "Include an unique message for each Assert() so that when the assert
> fails,
> it is trivial to locate it in the source. Otherwise, it may be difficult
> to
> determine which part of the test is failing. A good way to ensure unique
> messages is to use something like #A01, #A02 etc.
> (...)
> Once you used such a number in an Assert(), don't change it later on -
> people might use it it identify the test in bug reports or in mailing
> lists."
> 
> "BTW, is there any built-in way to run these unit tests against .NET, to
> make sure that what Mono does matches up with what .NET does?"
> 
> Not that I know of.
> 
> 
> Steven Boswell II wrote
>> 
>> Enclosed is a replacement for the previous
>> DataGridView.SelectionChanged()
>> patch I submitted.  On top of containing the unit test, this one also
>> adds
>> a call to OnSelectionChanged() to
>> DataGridView.OnColumnPostRemovedInternal() -- I had previously added a
>> call to OnSelectionChanged() to DataGridView.OnRowsPostRemovedInternal().
>> 
>> Please let me know if this is what you expect of a unit test, then I'll
>> try writing some for my other changes.
>> 
>> BTW, is there any built-in way to run these unit tests against .NET, to
>> make sure that what Mono does matches up with what .NET does?
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Saturday, June 2, 2012 8:45 AM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Alright. Patch 6 has been pushed
>> (https://github.com/mono/mono/commit/3d04a14a278d6160e33c16b52b86d68fe45d80b1).
>> 
>> I'll take care of the rest later, when I feel less lazy. :)
>> About patch 1, if there are indeed 2 separate issues, then it's better to
>> split the patch in 2, and also include 2 unit tests if possible.
>> 
>> Thanks.
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> Patch 1 is for https://bugzilla.xamarin.com/show_bug.cgi?id=5419 .
>>> Patch 2 is for https://bugzilla.xamarin.com/show_bug.cgi?id=5420 .
>>> Patch 3 is for https://bugzilla.xamarin.com/show_bug.cgi?id=3415 .
>>> I attached the relevant patch to all three of those bug reports.
>>> Patch 6 is
>>> for https://bugzilla.novell.com/show_bug.cgi?id=567331 and https://bugzilla.novell.com/show_bug.cgi?id=668012 .
>>>  I would post my patches to those bug reports, but Novell wants WAY too
>>> much personal information just to reply to a bug report.
>>> I don't see reports for the other bugs.
>>> 
>>> I'll go read about NUni

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Hmm, I don't think the added dependency to System.Linq in the tests is OK.
The whole thing is supposed to build and run with the .NET 2.0 profile.

Also, I could be wrong, but I think it's usually a bad idea to change
existing tests (unless they're wrong). Just make new tests instead
(SelectedRowsTest2(), or whatever). Can anyone confirm?

As explained here: http://www.mono-project.com/Test_Suite

"Include an unique message for each Assert() so that when the assert fails,
it is trivial to locate it in the source. Otherwise, it may be difficult to
determine which part of the test is failing. A good way to ensure unique
messages is to use something like #A01, #A02 etc.
(...)
Once you used such a number in an Assert(), don't change it later on -
people might use it it identify the test in bug reports or in mailing
lists."

"BTW, is there any built-in way to run these unit tests against .NET, to
make sure that what Mono does matches up with what .NET does?"

Not that I know of.


Steven Boswell II wrote
> 
> Enclosed is a replacement for the previous DataGridView.SelectionChanged()
> patch I submitted.  On top of containing the unit test, this one also adds
> a call to OnSelectionChanged() to
> DataGridView.OnColumnPostRemovedInternal() -- I had previously added a
> call to OnSelectionChanged() to DataGridView.OnRowsPostRemovedInternal().
> 
> Please let me know if this is what you expect of a unit test, then I'll
> try writing some for my other changes.
> 
> BTW, is there any built-in way to run these unit tests against .NET, to
> make sure that what Mono does matches up with what .NET does?
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Saturday, June 2, 2012 8:45 AM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Alright. Patch 6 has been pushed
> (https://github.com/mono/mono/commit/3d04a14a278d6160e33c16b52b86d68fe45d80b1).
> 
> I'll take care of the rest later, when I feel less lazy. :)
> About patch 1, if there are indeed 2 separate issues, then it's better to
> split the patch in 2, and also include 2 unit tests if possible.
> 
> Thanks.
> 
> 
> Steven Boswell II wrote
>> 
>> Patch 1 is for https://bugzilla.xamarin.com/show_bug.cgi?id=5419 .
>> Patch 2 is for https://bugzilla.xamarin.com/show_bug.cgi?id=5420 .
>> Patch 3 is for https://bugzilla.xamarin.com/show_bug.cgi?id=3415 .
>> I attached the relevant patch to all three of those bug reports.
>> Patch 6 is
>> for https://bugzilla.novell.com/show_bug.cgi?id=567331 and https://bugzilla.novell.com/show_bug.cgi?id=668012 .
>>  I would post my patches to those bug reports, but Novell wants WAY too
>> much personal information just to reply to a bug report.
>> I don't see reports for the other bugs.
>> 
>> I'll go read about NUnit now.
>> 
>> Thanks for reviewing my bug fixes!
>> 
>> Steven Boswell
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Friday, June 1, 2012 4:33 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> You could just write tests for what's easy to test, and leave the rest.
>> As a bonus, you could post links to related bug reports here, and attach
>> patch + unit test (if any) in each of them. You don't need to bother with
>> GitHub for now.
>> 
>> I'll have a look and review what I can.
>> 
>> Thanks.
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> I reported a few of them in Bugzilla, but I wasn't sure if that database
>>> got any attention, e.g. the DataGridView.SelectionRows bug wasreported
>>> months ago and go no reply.  I don't currently have an account on
>>> GitHub;
>>> if I absolutely must have one, I'll go make one, but I wasn't planning
>>> to
>>> do that unless I started making tons of changes or something.  Also, how
>>> does one write a unit test for something that has to be verified
>>> visually
>>> (e.g. fixing ToolStripItem.BackColor) or via user interaction (e.g.
>>> fixing
>>> DataGridView.SelectionRows)?  So I suppose, yes, I need help :-)
>>> 
>>> Steven Boswell
>>> 
>>> 
>>> 
>>> 
>>>  From: Stifu <stifu@>
>>> To: mono-devel-list@.ximian 
>>> Sent: Thursday, May 31, 2012 11:06 PM
>>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>>  
>>> Hello,
>>> 
>>> Thanks for 

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Alright. Patch 6 has been pushed
(https://github.com/mono/mono/commit/3d04a14a278d6160e33c16b52b86d68fe45d80b1).

I'll take care of the rest later, when I feel less lazy. :)
About patch 1, if there are indeed 2 separate issues, then it's better to
split the patch in 2, and also include 2 unit tests if possible.

Thanks.


Steven Boswell II wrote
> 
> Patch 1 is for https://bugzilla.xamarin.com/show_bug.cgi?id=5419 .
> Patch 2 is for https://bugzilla.xamarin.com/show_bug.cgi?id=5420 .
> Patch 3 is for https://bugzilla.xamarin.com/show_bug.cgi?id=3415 .
> I attached the relevant patch to all three of those bug reports.
> Patch 6 is
> for https://bugzilla.novell.com/show_bug.cgi?id=567331 and https://bugzilla.novell.com/show_bug.cgi?id=668012 .
>  I would post my patches to those bug reports, but Novell wants WAY too
> much personal information just to reply to a bug report.
> I don't see reports for the other bugs.
> 
> I'll go read about NUnit now.
> 
> Thanks for reviewing my bug fixes!
> 
> Steven Boswell
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Friday, June 1, 2012 4:33 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> You could just write tests for what's easy to test, and leave the rest.
> As a bonus, you could post links to related bug reports here, and attach
> patch + unit test (if any) in each of them. You don't need to bother with
> GitHub for now.
> 
> I'll have a look and review what I can.
> 
> Thanks.
> 
> 
> Steven Boswell II wrote
>> 
>> I reported a few of them in Bugzilla, but I wasn't sure if that database
>> got any attention, e.g. the DataGridView.SelectionRows bug wasreported
>> months ago and go no reply.  I don't currently have an account on GitHub;
>> if I absolutely must have one, I'll go make one, but I wasn't planning to
>> do that unless I started making tons of changes or something.  Also, how
>> does one write a unit test for something that has to be verified visually
>> (e.g. fixing ToolStripItem.BackColor) or via user interaction (e.g.
>> fixing
>> DataGridView.SelectionRows)?  So I suppose, yes, I need help :-)
>> 
>> Steven Boswell
>> 
>> 
>> 
>> 
>>  From: Stifu <stifu@>
>> To: mono-devel-list@.ximian 
>> Sent: Thursday, May 31, 2012 11:06 PM
>> Subject: Re: [Mono-dev] Patches for mono-winforms
>>  
>> Hello,
>> 
>> Thanks for your work.
>> 
>> If I'm not mistaken, you reported each of these bugs, right? At least I
>> could find the two first ones in bugzilla, but didn't go further. Anyway,
>> I
>> suggest you make pull requests for each bug separately, specifying the
>> bug
>> number. Also, please include unit tests with each patch, highlighting
>> what
>> was fixed. I know it's more work, but it will make commiters more
>> confident
>> with your changes, and will guarantee no one will ever break these parts
>> again.
>> 
>> Let me know if you need help.
>> 
>> 
>> Steven Boswell II wrote
>>> 
>>> I work in a shop where our apps are written with C# and WinForms.  Thank
>>> God for Mono; I'm allowed to do all my work under Linux with Mono, and
>>> my
>>> code works fine under MS Windows and .NET.
>>> 
>>> Recently, I ran into a showstopper bug in mono-winforms, and finally
>>> decided to look through the code.  I fixed the bug quickly.  That led me
>>> to looking for the source of other, non-showstopper bugs I've
>>> encountered,
>>> and those went quickly too.  Enclosed is an archive with all of the bug
>>> fixes I made, which were made against the latest version on GitHub.  (I
>>> originally made these bug fixes against version 2.10.5, the most recent
>>> one in Fedora Core 16's yum repos.)
>>> 
>>> Patch 1 implements the EditingControlShowing event in DataGridView.
>>>  Before, it wasn't called at all.  I had to split a
>>> DataGridViewCell.StyleEditingControl() method off of
>>> DataGridViewCell.InitializeEditingControl(); under .NET, ComboBox.Items
>>> is
>>> initialized before EditingControlShowing is posted, and this split was
>>> necessary to get Mono to work that way too.  Styles modified in the
>>> EditingControlShowing event are now applied to text-box and checkbox
>>> controls too, not just combo-boxes.
>>> 
>>> Patch 2 resolves different behavior between .NET and Mono when the 

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

You could just write tests for what's easy to test, and leave the rest.
As a bonus, you could post links to related bug reports here, and attach
patch + unit test (if any) in each of them. You don't need to bother with
GitHub for now.

I'll have a look and review what I can.

Thanks.


Steven Boswell II wrote
> 
> I reported a few of them in Bugzilla, but I wasn't sure if that database
> got any attention, e.g. the DataGridView.SelectionRows bug wasreported
> months ago and go no reply.  I don't currently have an account on GitHub;
> if I absolutely must have one, I'll go make one, but I wasn't planning to
> do that unless I started making tons of changes or something.  Also, how
> does one write a unit test for something that has to be verified visually
> (e.g. fixing ToolStripItem.BackColor) or via user interaction (e.g. fixing
> DataGridView.SelectionRows)?  So I suppose, yes, I need help :-)
> 
> Steven Boswell
> 
> 
> 
> 
>  From: Stifu <stifu@>
> To: mono-devel-list@.ximian 
> Sent: Thursday, May 31, 2012 11:06 PM
> Subject: Re: [Mono-dev] Patches for mono-winforms
>  
> Hello,
> 
> Thanks for your work.
> 
> If I'm not mistaken, you reported each of these bugs, right? At least I
> could find the two first ones in bugzilla, but didn't go further. Anyway,
> I
> suggest you make pull requests for each bug separately, specifying the bug
> number. Also, please include unit tests with each patch, highlighting what
> was fixed. I know it's more work, but it will make commiters more
> confident
> with your changes, and will guarantee no one will ever break these parts
> again.
> 
> Let me know if you need help.
> 
> 
> Steven Boswell II wrote
>> 
>> I work in a shop where our apps are written with C# and WinForms.  Thank
>> God for Mono; I'm allowed to do all my work under Linux with Mono, and my
>> code works fine under MS Windows and .NET.
>> 
>> Recently, I ran into a showstopper bug in mono-winforms, and finally
>> decided to look through the code.  I fixed the bug quickly.  That led me
>> to looking for the source of other, non-showstopper bugs I've
>> encountered,
>> and those went quickly too.  Enclosed is an archive with all of the bug
>> fixes I made, which were made against the latest version on GitHub.  (I
>> originally made these bug fixes against version 2.10.5, the most recent
>> one in Fedora Core 16's yum repos.)
>> 
>> Patch 1 implements the EditingControlShowing event in DataGridView.
>>  Before, it wasn't called at all.  I had to split a
>> DataGridViewCell.StyleEditingControl() method off of
>> DataGridViewCell.InitializeEditingControl(); under .NET, ComboBox.Items
>> is
>> initialized before EditingControlShowing is posted, and this split was
>> necessary to get Mono to work that way too.  Styles modified in the
>> EditingControlShowing event are now applied to text-box and checkbox
>> controls too, not just combo-boxes.
>> 
>> Patch 2 resolves different behavior between .NET and Mono when the user
>> leaves a DataGridView.  Under .NET, the last-edited cell is committed;
>> under Mono, changed made to the last-edited cell are lost.  It was a
>> one-line fix.
>> 
>> Patch 3 fires the DataGridView.SelectionChanged event when the selected
>> rows/columns changes.  Before, the values of the SelectedRows and
>> SelectedColumns properties were semi-random during the SelectionChanged
>> event; now they're accurate.
>> 
>> Patches 4 and 5 fix two different exception-throws I encountered when
>> ComboBox.Items.Remove() is called with an item that's not in the combo
>> box.  .NET doesn't throw any exceptions in this case.
>> 
>> Patch 6 fixes the implementation of BackColor on ToolStripItem objects.
>>  Now it behaves like it does under .NET, i.e. the BackColor setting on
>> menu items etc. shows up.
>> 
>> I would very much appreciate it if you would consider committing these
>> changes.  My MS-Windows-oriented co-workers were impressed by how quickly
>> bugs in Mono can be found and fixed.  Who knows, maybe I'll get some
>> converts to open-source.  (It amazes me that this sort of thing still has
>> to be evangelized...sigh.)
>> 
>> Steven Boswell
>> 
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> 
> 
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Patches-for-mono-winfo

Re: [Mono-dev] Patches for mono-winforms

[Stifu]

Hello,

Thanks for your work.

If I'm not mistaken, you reported each of these bugs, right? At least I
could find the two first ones in bugzilla, but didn't go further. Anyway, I
suggest you make pull requests for each bug separately, specifying the bug
number. Also, please include unit tests with each patch, highlighting what
was fixed. I know it's more work, but it will make commiters more confident
with your changes, and will guarantee no one will ever break these parts
again.

Let me know if you need help.


Steven Boswell II wrote
> 
> I work in a shop where our apps are written with C# and WinForms.  Thank
> God for Mono; I'm allowed to do all my work under Linux with Mono, and my
> code works fine under MS Windows and .NET.
> 
> Recently, I ran into a showstopper bug in mono-winforms, and finally
> decided to look through the code.  I fixed the bug quickly.  That led me
> to looking for the source of other, non-showstopper bugs I've encountered,
> and those went quickly too.  Enclosed is an archive with all of the bug
> fixes I made, which were made against the latest version on GitHub.  (I
> originally made these bug fixes against version 2.10.5, the most recent
> one in Fedora Core 16's yum repos.)
> 
> Patch 1 implements the EditingControlShowing event in DataGridView.
>  Before, it wasn't called at all.  I had to split a
> DataGridViewCell.StyleEditingControl() method off of
> DataGridViewCell.InitializeEditingControl(); under .NET, ComboBox.Items is
> initialized before EditingControlShowing is posted, and this split was
> necessary to get Mono to work that way too.  Styles modified in the
> EditingControlShowing event are now applied to text-box and checkbox
> controls too, not just combo-boxes.
> 
> Patch 2 resolves different behavior between .NET and Mono when the user
> leaves a DataGridView.  Under .NET, the last-edited cell is committed;
> under Mono, changed made to the last-edited cell are lost.  It was a
> one-line fix.
> 
> Patch 3 fires the DataGridView.SelectionChanged event when the selected
> rows/columns changes.  Before, the values of the SelectedRows and
> SelectedColumns properties were semi-random during the SelectionChanged
> event; now they're accurate.
> 
> Patches 4 and 5 fix two different exception-throws I encountered when
> ComboBox.Items.Remove() is called with an item that's not in the combo
> box.  .NET doesn't throw any exceptions in this case.
> 
> Patch 6 fixes the implementation of BackColor on ToolStripItem objects.
>  Now it behaves like it does under .NET, i.e. the BackColor setting on
> menu items etc. shows up.
> 
> I would very much appreciate it if you would consider committing these
> changes.  My MS-Windows-oriented co-workers were impressed by how quickly
> bugs in Mono can be found and fixed.  Who knows, maybe I'll get some
> converts to open-source.  (It amazes me that this sort of thing still has
> to be evangelized...sigh.)
> 
> Steven Boswell
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.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-tp4649620p4649621.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Request for Novell bug maintainer

[Stifu]

So, there is nothing left to fix in this bug, and Mono behaves the same as
.NET. Is that right?
By the way, I think that on bugzilla.novell, anyone can close bugs and all,
unlike on xamarin.bugzilla.


Robert Wilkens wrote
> 
> I was just looking at this old 'bug' from the Novell's bugzilla:
> 
> https://bugzilla.novell.com/show_bug.cgi?id=321541
> 
> Some stuff was fixed for that bug some 6 years ago, but it hasn't been 
> closed yet because they didn't understand why the events were being 
> delivered to both threads.
> 
> The answer is because both threads in the sample code are processing the 
> same event queue by virtue of calling Application.Run() which is the 
> event processor, and there is only one event queue per application.  I 
> read this somewhere on msdn today when i was googling information 
> related to the problem.  Only one thread should be processing the event 
> queue.
> 
> Does anyone here have the authority to close old Novell bugs such as 
> this one?  It would make it easier to get an idea of what is actually 
> still broken versus what needs to be fixed.
> 
> I am only writing here because i saw very few people were being cc'd 
> when i made a comment on it stating this much.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Request-for-Novell-bug-maintainer-tp4649597p4649598.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] I'm hooked

[Stifu]

Rest assured that Mono is so huge that there are still many easy problems
around.

By the way, I saw you looked at some WinForms bugs on bugzilla... If you're
looking at WinForms bugs to fix, you may be interested in checking out the
old bugzilla, the one from Novell, which has many bug reports that weren't
migrated to the Xamarin bugzilla.

https://bugzilla.novell.com/buglist.cgi?resolution=---&classification=Mono&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&bug_status=RESOLVED&component=Windows.Forms&product=Mono%3A%20Class%20Libraries%20

Let me know if you need help.


Robert Wilkens wrote
> 
> You make a good point, i was wrong.  I dreaded doing the tests only
> because i knew they weren't doing anything useful in terms of
> functionality of the project in the short term, but i did learn a lot in
> the test generation process, and in the end always had fun with that too.
> 
> I'm sort of struggling deciding which direction to go next, but i've got
> to find my comfort level i guess.  I think my best bet is to start with
> the easier problems (if there are any more) that no one else felt was
> worth their time (or they're too busy with real fires to put out), and
> familiarize myself as I go with things i'm uncomfortable with (like
> setting up an apache/asp.net development environment - as a small
> example).
> 
> -Rob
> 
> 
> 
> On May 26, 2012, at 2:50 AM, Stifu wrote:
> 
>> Tests are part of the fun, IMO. And they prove you're not just randomly
>> changing code for the sake of it.
>> I haven't contributed much, but I guess something like 3/4 of the code I
>> submitted it was tests.
>> 
>> 
>> Rob Wilkens wrote
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> 
>>> Glad to hear it -- I enjoy it but the part that is more like work is
>>> generating tests ;-) and actually running the test.  The rest of it is
>>> fun.  Still, I respect the process, and by request, have added a unit
>>> test to my pull request.
>>> 
>>> - -Rob
>>> 
>>> On 05/25/2012 05:09 PM, Rodrigo Kumpera wrote:
>>>> I love to see people excited with contributing to mono.
>>>> 
>>>> Thanks for taking take to do this. Everyone in the community
>>>> appreciate your effort.
>>>> 
>>>> 
>>>> 
>>>> On Fri, May 25, 2012 at 5:56 PM, Rob Wilkens <robwilkens@>
>>>> wrote:
>>>> 
>>>> After fixing the bug i reported myself a few weeks ago, i had my 
>>>> doubts as to whether the commit would be accepted as a newbie
>>>> here. But it was!
>>>> 
>>>> So, i'm hooked!  I just submitted another patch(commit) today via 
>>>> github.
>>>> 
>>>> This one for bug #853 
>>>> https://bugzilla.xamarin.com/show_bug.cgi?id=853
>>>> 
>>>> I realize posting to the list for each individual fix probably
>>>> isn't necessary, but i am new here, so i want to say that if any of
>>>> the people responsible have any questions, I am subscribed here.
>>>> 
>>>> I probably won't start on any other bug reports until this one
>>>> goes thru (or not).  I realize it may be 3+ weeks like last time,
>>>> which is fine, because i need to pace myself.  I'm the type of
>>>> person to get obsessive over this kind of thing.
>>>> 
>>>> -Rob
>>>>> ___ Mono-devel-list
>>>>> mailing list Mono-devel-list@.ximian 
>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>> 
>>>> 
>>> 
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>> 
>>> iF4EAREIAAYFAk/AFxQACgkQcefeIla2m83fWAD+IssHG6HbM1uu8mrXfLO83UTS
>>> uOfZ64R2HTwMg/xYOh8A/iTRcNxAuX0mSbud4LxyJILr/MDyK7ac30V8IqZHPkzr
>>> =xhQP
>>> -END PGP SIGNATURE-
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@.ximian
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> 
>> 
>> 
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/I-m-hooked-tp4649549p4649553.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@.ximian
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

--
View this message in context: 
http://mono.1490590.n4.nabble.com/I-m-hooked-tp4649549p4649564.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] I'm hooked

[Stifu]

Tests are part of the fun, IMO. And they prove you're not just randomly
changing code for the sake of it.
I haven't contributed much, but I guess something like 3/4 of the code I
submitted it was tests.


Rob Wilkens wrote
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> Glad to hear it -- I enjoy it but the part that is more like work is
> generating tests ;-) and actually running the test.  The rest of it is
> fun.  Still, I respect the process, and by request, have added a unit
> test to my pull request.
> 
> - -Rob
> 
> On 05/25/2012 05:09 PM, Rodrigo Kumpera wrote:
>> I love to see people excited with contributing to mono.
>> 
>> Thanks for taking take to do this. Everyone in the community
>> appreciate your effort.
>> 
>> 
>> 
>> On Fri, May 25, 2012 at 5:56 PM, Rob Wilkens 
>> wrote:
>> 
>> After fixing the bug i reported myself a few weeks ago, i had my 
>> doubts as to whether the commit would be accepted as a newbie
>> here. But it was!
>> 
>> So, i'm hooked!  I just submitted another patch(commit) today via 
>> github.
>> 
>> This one for bug #853 
>> https://bugzilla.xamarin.com/show_bug.cgi?id=853
>> 
>> I realize posting to the list for each individual fix probably
>> isn't necessary, but i am new here, so i want to say that if any of
>> the people responsible have any questions, I am subscribed here.
>> 
>> I probably won't start on any other bug reports until this one
>> goes thru (or not).  I realize it may be 3+ weeks like last time,
>> which is fine, because i need to pace myself.  I'm the type of
>> person to get obsessive over this kind of thing.
>> 
>> -Rob
>>> ___ Mono-devel-list
>>> mailing list Mono-devel-list@.ximian 
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> 
>> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iF4EAREIAAYFAk/AFxQACgkQcefeIla2m83fWAD+IssHG6HbM1uu8mrXfLO83UTS
> uOfZ64R2HTwMg/xYOh8A/iTRcNxAuX0mSbud4LxyJILr/MDyK7ac30V8IqZHPkzr
> =xhQP
> -END PGP SIGNATURE-
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/I-m-hooked-tp4649549p4649553.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono Maintainers list

[Stifu]

Hi,

Tom Hindle and myself (Thomas Goldstein) have been maintaining WinForms a
little. I'm not very active, but I don't mind reviewing patches if the
impacted code is within my knowledge.

No IRC for me.


Alex wrote
> 
> Hello folks!
> 
> I'm planning to write and maintain a page listing maintainers of
> specific parts of Mono. When you have a patch that you wish to
> contribute, it is usually easier to go directly to the maintainer of
> the part of the code that you are modifying in order to have it
> reviewed, rather than posting to the mailing list or #monodev and
> waiting for someone to notice it. However, it is not currently clear
> who to go to for the various parts of Mono's source. I'm planning to
> improve this situation by creating a Maintainers page on the wiki,
> which I am also committing to keeping up to date.
> 
> So, in order to put together an initial list, I'm writing to the
> various dev lists. If you are willing to take maintainership of a
> particular part of Mono's source base, please reply to this email with
> a description of the parts of Mono you wish to take maintainership of
> and your IRC nickname (if any). Essentially, doing this just means
> that people will be able to go to you when they need patch reviews.
> 
> Thanks!
> 
> Regards,
> Alex
> ___
> Mono-devel-list mailing list
> Mono-devel-list@.ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Mono-Maintainers-list-tp4547164p4547187.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Xamarin Bugzilla issues

[Stifu]

About the second point, going to Preferences / Permissions, I see "There are
no permission bits set on your account.". I take it that's a difference from
Novell's Bugzilla, where anyone could edit bugs.

Could someone grant me the needed rights?


Stifu wrote
> 
> Hi,
> 
> 2 problems I'm having with the Xamarin bugzilla:
> 
> 1- Someone commented on bug #395
> (http://bugzilla.xamarin.com/show_bug.cgi?id=395), but I never received
> notification mails. After having double checked my preferences, I should
> have. It's not in my spam folder or anything.
> 
> 2- I cannot edit most bugs (seems like I can only edit #395 because I'm
> assignee). Options are hidden although I'm logged in. I want to mark #821
> as resolved, but I can't.
> 
> Any ideas?
> 
> Thanks.
> 


--
View this message in context: 
http://mono.1490590.n4.nabble.com/Xamarin-Bugzilla-issues-tp4109310p4113263.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Xamarin Bugzilla issues

[Stifu]

Hi,

2 problems I'm having with the Xamarin bugzilla:

1- Someone commented on bug #395
(http://bugzilla.xamarin.com/show_bug.cgi?id=395), but I never received
notification mails. After having double checked my preferences, I should
have. It's not in my spam folder or anything.

2- I cannot edit most bugs (seems like I can only edit #395 because I'm
assignee). Options are hidden although I'm logged in. I want to mark #821 as
resolved, but I can't.

Any ideas?

Thanks.

--
View this message in context: 
http://mono.1490590.n4.nabble.com/Xamarin-Bugzilla-issues-tp4109310p4109310.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list