Re: [Mono-winforms-list] Porting Visual Studio Created WinForms Applications C#
To clear things up, it's been in the hands of the community since 2010, but it was actually started by the Mono team. Sure, you can contribute in any way you like. Fix your own pet bugs, fix bugs from bugzilla, or add new stuff. Then submit patches / pull requests. Sources: https://github.com/mono/mono/tree/master/mcs/class/System.Windows.Forms Let me know if I can help. - Mail original - De: Marcel Burger m.burger.w...@gmail.com À: Stifu st...@free.fr Cc: mono-winforms-list@lists.ximian.com Envoyé: Mercredi 29 Juillet 2015 10:22:36 Objet: Re: [Mono-winforms-list] Porting Visual Studio Created WinForms Applications C# Hi, Is there a way I can contribute to this project? I do like working with Winforms, and now that you told me it's a community based project, I admire the effort alot ! Until now, every functionality seems to work flawlessly. It's mainly a matter of knowing which librareis you can/can't use and which controls and their properties to use and how to manipulate the controls so they work on multiple OSses. Kind regards, Marcel Burger On Wed, Jul 29, 2015 at 9:50 AM, st...@free.fr wrote: Hi, I'm hoping that future mono updates wil solve these graphical issues automagically, so the software works and looks as stunning as it does on a windows system :-) For your information, the WinForms project is only maintained by the community, so such a project would have to come from us. Xamarin won't do it. If not, I guess, HTML5 instead of WinForm will be a nice GUI replacement :-) There's also XWT (but still no designer): https://github.com/mono/xwt - Mail original - De: Marcel Burger m.burger.w...@gmail.com À: Stifu st...@free.fr Cc: mono-winforms-list@lists.ximian.com Envoyé: Mercredi 29 Juillet 2015 09:37:27 Objet: Re: [Mono-winforms-list] Porting Visual Studio Created WinForms Applications C# Hello Peter, Currently I'm also building a multi platform desktop application. I develop with VS, import it in a virtual Linux Mint via Git and build it with Monodevelop. I use Monodevelop and Google to fix the list of build failures Monodevelop comes up with. Besides that I try to use as little Dependencies as I can and only use Libraries which are crossplatform. So, 1 codebase - several deployments. Personally I don't mind the Designer files VS creates, since these files only initiate and set the properties of the controls you create when you use the visual designer is VS. The .resx files (also) contain the images you use in your application (b.t.w. I've noticed that it's better to avoid using Icon files but instead use png files and convert them to ico via code). Monodevelop doesn't have a WinForm designer so you will be creating (some sort of) Designer files yourself anyway to initiatie and set the controls you need. I have noticed that some Control properties set in VS don't act like they should in Monodevelop, many of which have been submitted as bugs. In many cases initiating those Controls and setting the properties yourself (via code instead of using the Visual Designer) solve the problems (but not all of them, some properties simply don't work so I choose to ommit them instead of creating hacks around them ...). So you can also stick to develop a winform app without a Visual Designer ;) Keep in mind that you will have some issues regarding: - visual refreshing on Unix systems (controls simply won't refresh themselve like they do on Windows, so sometimes you don't see the controls at all, which looks pretty awful. I see it in more applications on Unix systems ...) - The controls used via Monodevelop are based on winXP which make them look a buit outdated - Some controls used via Monodevelop have different base (not mutable) properties then WIndows, which leads to different spacing requirements ... (e.g. ComboBox). Since I only have the requirement that the software should work on Unix and that the graphical issues are not that important, I stick with my current development strategy. I think it's very cool that I only have to write the code once and deploy it on different OSses, but the graphical experience is a bit dissapointing. I'm hoping that future mono updates wil solve these graphical issues automagically, so the software works and looks as stunning as it does on a windows system :-) I don't mind helping out in that area ;) If not, I guess, HTML5 instead of WinForm will be a nice GUI replacement :-) cheers, Marcel Burger On Tue, Jul 28, 2015 at 5:23 PM, Stifu st...@free.fr wrote: Hi, MonoDevelop and Xamarin Studio don't have a WinForms designer, so you'd better stick with Visual Studio. I admit I'm not really up to date on this, but there must be VS plugins to run your app with Mono from the IDE. I've found the MonoDebugger project ( http://www.monodebugger.net/ ), but it seems it's still not available. Maybe Xamarin for Visual
Re: [Mono-winforms-list] Porting Visual Studio Created WinForms Applications C#
Hi, I'm hoping that future mono updates wil solve these graphical issues automagically, so the software works and looks as stunning as it does on a windows system :-) For your information, the WinForms project is only maintained by the community, so such a project would have to come from us. Xamarin won't do it. If not, I guess, HTML5 instead of WinForm will be a nice GUI replacement :-) There's also XWT (but still no designer): https://github.com/mono/xwt - Mail original - De: Marcel Burger m.burger.w...@gmail.com À: Stifu st...@free.fr Cc: mono-winforms-list@lists.ximian.com Envoyé: Mercredi 29 Juillet 2015 09:37:27 Objet: Re: [Mono-winforms-list] Porting Visual Studio Created WinForms Applications C# Hello Peter, Currently I'm also building a multi platform desktop application. I develop with VS, import it in a virtual Linux Mint via Git and build it with Monodevelop. I use Monodevelop and Google to fix the list of build failures Monodevelop comes up with. Besides that I try to use as little Dependencies as I can and only use Libraries which are crossplatform. So, 1 codebase - several deployments. Personally I don't mind the Designer files VS creates, since these files only initiate and set the properties of the controls you create when you use the visual designer is VS. The .resx files (also) contain the images you use in your application (b.t.w. I've noticed that it's better to avoid using Icon files but instead use png files and convert them to ico via code). Monodevelop doesn't have a WinForm designer so you will be creating (some sort of) Designer files yourself anyway to initiatie and set the controls you need. I have noticed that some Control properties set in VS don't act like they should in Monodevelop, many of which have been submitted as bugs. In many cases initiating those Controls and setting the properties yourself (via code instead of using the Visual Designer) solve the problems (but not all of them, some properties simply don't work so I choose to ommit them instead of creating hacks around them ...). So you can also stick to develop a winform app without a Visual Designer ;) Keep in mind that you will have some issues regarding: - visual refreshing on Unix systems (controls simply won't refresh themselve like they do on Windows, so sometimes you don't see the controls at all, which looks pretty awful. I see it in more applications on Unix systems ...) - The controls used via Monodevelop are based on winXP which make them look a buit outdated - Some controls used via Monodevelop have different base (not mutable) properties then WIndows, which leads to different spacing requirements ... (e.g. ComboBox). Since I only have the requirement that the software should work on Unix and that the graphical issues are not that important, I stick with my current development strategy. I think it's very cool that I only have to write the code once and deploy it on different OSses, but the graphical experience is a bit dissapointing. I'm hoping that future mono updates wil solve these graphical issues automagically, so the software works and looks as stunning as it does on a windows system :-) I don't mind helping out in that area ;) If not, I guess, HTML5 instead of WinForm will be a nice GUI replacement :-) cheers, Marcel Burger On Tue, Jul 28, 2015 at 5:23 PM, Stifu st...@free.fr wrote: Hi, MonoDevelop and Xamarin Studio don't have a WinForms designer, so you'd better stick with Visual Studio. I admit I'm not really up to date on this, but there must be VS plugins to run your app with Mono from the IDE. I've found the MonoDebugger project ( http://www.monodebugger.net/ ), but it seems it's still not available. Maybe Xamarin for Visual Studio does what you want ( http://xamarin.com/visual-studio ), but I'm not sure, since it's actually specialized in mobile development. Note you could also just build your app with VS then manually test it on Mono on all the targeted platforms. It's not ideal, but it's what I do (except I use SharpDevelop). jonesypeter wrote Hello, I wonder if I could ask a very simplistic question. I have searched for an answer before posting. I have created a very simple WinForms applications and created the .exe and checked that this runs with Mono as well and it all went fine. If I want to build this application directly with Mono how do I do this, because Visual Studio creates a large list of files including Form1.Designer.cs, Form1.resz. and Program.cs Thanks Peter Jones -- View this message in context: http://mono.1490590.n4.nabble.com/Porting-Visual-Studio-Created-WinForms-Applications-C-tp4666376p4666385.html Sent from the Mono - WinForms mailing list archive at Nabble.com. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman
Re: [Mono-winforms-list] Drawing in a winform using Gtk C# in Xamarin Studio
Hello, You should either use WinForms or GTK#, not both. If you want to use WinForms, then you should draw using GDI+, the same way you would in .NET. If you want to use GTK#, then you should draw using GDK (http://docs.go-mono.com/?link=T%3aGdk.Pixbuf). RoboPi wrote Hello, I'm looking for help or tutorials on how to draw to a drawingarea on a Windows Form using C# in Xamarin Studio. I just need to draw simple shapes, line, rectangles, circles, and be able to fill them in with color. A simple sample code would be great. I haven't been able to find anything on YouTube or Google. Any help will be greatly appreciated. Thank you, James -- View this message in context: http://mono.1490590.n4.nabble.com/Drawing-in-a-winform-using-Gtk-C-in-Xamarin-Studio-tp4666294p4666295.html Sent from the Mono - WinForms mailing list archive at Nabble.com. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Drawing in a winform using Gtk C# in Xamarin Studio
I can confirm you're working on a GTK# project and not on a WinForms one. Mono can run WinForms apps (with some bugs), but doesn't have a WinForms designer. So if you wanna build a WinForms app with a GUI designer, you'd need to do it from Windows using Visual Studio or SharpDevelop. If you wanna build a desktop app from Xamarin Studio with a GUI designer, I think GTK# is your only choice. Note that there's another interesting GUI toolkit: XWT (https://github.com/mono/xwt), but it still doesn't have a designer either if I'm not mistaken. Anyway, I've never used GTK#, so can't help you with it. But I found this after a quick search, which might be useful: http://stackoverflow.com/questions/9113069/how-to-use-gdk-library-in-c-sharp-mono RoboPi wrote Thanks for the quick reply. Unfortunately I'm new to all of this and I don't know what I'm doing so I'll try to explain I'm running Windows 7.I downloaded Monodevelop Xamarin StudioWhen I start a project I choose New SolutionFrom there I chose .NET and Gtk# 2.0 ProjectI then select MainWindow.cs opened with Window Designer I get a form to design and create code for the objects I place on the form. When I run the program I get a Window that contains all my buttons, etc. So that's where I'm at. I've placed a DrawingArea object (or widget?) from the toolbox onto the form. Now I would like to draw to that drawing area. So I need to find some documentation or tutorials on how to do that. That's where I'm at. So what am I using here? Is this a Gtk C# window? Or a Winform? And can I use a standard Windows form in this studio? I used to have Microsoft C# studio and I could draw to a windows forms pretty easily. But it doesn't seem to work the same in the Monodevelop Xamarin studio. I just need to get past this graphics problem and I can get on with writing my code to draw the simulations I want to program. I just can't figure out how to draw to the DrawingArea object, or widget? I've been looking for a tutorial on how to do that and I couldn't find one. Thanks From: Stifu [via Mono] lt; ml-node+s1490590n4666295h93@.nabble gt; To: RoboPi lt; antiquecraftsman@ gt; Sent: Tuesday, July 7, 2015 12:09 PM Subject: Re: Drawing in a winform using Gtk C# in Xamarin Studio Hello, You should either use WinForms or GTK#, not both. If you want to use WinForms, then you should draw using GDI+, the same way you would in .NET. If you want to use GTK#, then you should draw using GDK (http://docs.go-mono.com/?link=T%3aGdk.Pixbuf). RoboPi wroteHello, I'm looking for help or tutorials on how to draw to a drawingarea on a Windows Form using C# in Xamarin Studio. I just need to draw simple shapes, line, rectangles, circles, and be able to fill them in with color. A simple sample code would be great. I haven't been able to find anything on YouTube or Google. Any help will be greatly appreciated. Thank you, James If you reply to this email, your message will be added to the discussion below: http://mono.1490590.n4.nabble.com/Drawing-in-a-winform-using-Gtk-C-in-Xamarin-Studio-tp4666294p4666295.html To unsubscribe from Drawing in a winform using Gtk C# in Xamarin Studio, click here. NAML -- View this message in context: http://mono.1490590.n4.nabble.com/Drawing-in-a-winform-using-Gtk-C-in-Xamarin-Studio-tp4666294p4666299.html Sent from the Mono - WinForms mailing list archive at Nabble.com. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] stuck with WinForms issue, not sure how to proceed
Hello, I know I'm a bit late, but just in case, I'll reply anyway. What I'd do is retrieve the Mono WinForms source code, then hack away to figure out what's wrong... Then you can just swap the Mono WinForms DLL with the one you built. Getting the WinForms project to build can be tricky, though (haven't tried lately). Sources: https://github.com/mono/mono/tree/master/mcs/class/System.Windows.Forms RhinoNY wrote Hi there, I have a Windows Forms custom control assembly which I have authored that does not run under Mono and I’m stuck trying to figure out why. I have provided a link to the testbed exe and the DLL below. Both target Framework 2.0. The DLL has a custom splitter, group bar, and navigation bar that I have authored. http://www.ryanrogers.com/monotest.zip I have ran both the DLL and EXE through Mono Analyzer and there were no issues found. Of course, I make no p/invoke calls or anything like that. I have compiled under VS 2010 as well as Mono. No warnings or errors compiling with either. I used the CSC.exe syntax out from VS and ran it through the Mono compiler. However, it doesn’t matter whether I run the MS-compiled assemblies of the Mono-compiled assemblies. In both cases I see a stack overflow warning (when run with –verbose), and the UI never launches. Everything runs fine using the MS runtime. I have tried both the “latest” and “stable” builds of Mono, and get the same result. I’m new too Mono, but a .Net veteran. How do I get more info out of Mono so that I can tell what is causing the problem? I know it’s my NavBar / GroupBar control that is causing the issue, as when I remove their creation from the testbed exe, it launches. So something these controls are doing is causing an issue, but I have no idea what, and am not sure the best way to diagnose this using Visual Studio. They are quite complex controls so I need some way to diagnose this. Do I need to be running MonoDevelop? Was hoping to avoid that... Are there some log files or logging options I'm overlooking? Any help or pointers would be most appreciated! Thanks, Ryan -- View this message in context: http://mono.1490590.n4.nabble.com/stuck-with-WinForms-issue-not-sure-how-to-proceed-tp4663153p4666296.html Sent from the Mono - WinForms mailing list archive at Nabble.com. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-list] Strange exception in Winforms app
Hi, I wish WinForms was more usable in general, but yeah, that's how it is. People will recommend you stay away from WinForms because it's old and badly supported in Mono. That said, WinForms is maintained by the community now, so if we want to make it better, it's in our hands. If you feel the motivation to fix that bug, I can review your patch and commit it. If that app is only unusable due to that one specific WinForms bug, it could be worth fixing it, rather than try to port the whole app to another GUI toolkit, which may not be a realistic solution. baltasarq wrote Hi, there, I'm using Mono 3.2.8 in Lubuntu 14.04, and I'm observing an odd behaviour which renders a WinForms app unusable. This application works perfectly in Windows, I mean, with the .NET stack, and worked perfectly in the previous version of Lubuntu (with an older version of Mono). http://baltasarq.info/dev/pgcal/ The app has a DataGridView. The problem is that, the second time you try to write something in a cell, WinForms launches the following exception (below). After this exception, the second time you write in the datagridview cell, the exception is raised continuously, so you actually cannot use the app. Any hint? Is this problem known? EDIT: Oh, well, bad news. Yep, the problem is known (though nobody seems to care). User djdjaa89 reported it in bugzilla on January 1st, 2013, and had no answer. http://bugzilla.xamarin.com/show_bug.cgi?id=9653 I guess what the answer to this e.mail is going to be. == $ mono ../pgcal/pgcal/bin/Release/pgcal.exe System.ObjectDisposedException: The object was used after being disposed. at System.Windows.Forms.Control.CreateHandle () [0x0] in filename unknown :0 at System.Windows.Forms.TextBoxBase.CreateHandle () [0x0] in filename unknown :0 at System.Windows.Forms.Control.CreateControl () [0x0] in filename unknown :0 at System.Windows.Forms.Control.SetVisibleCore (Boolean value) [0x0] in filename unknown :0 at System.Windows.Forms.Control.set_Visible (Boolean value) [0x0] in filename unknown :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:set_Visible (bool) at System.Windows.Forms.DataGridView.BeginEdit (Boolean selectAll) [0x0] in filename unknown :0 at System.Windows.Forms.DataGridView.ProcessKeyEventArgs (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control.ProcessKeyMessage (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control.WmKeys (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.DataGridView.WndProc (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x0] in filename unknown :0 System.ObjectDisposedException: The object was used after being disposed. at System.Windows.Forms.Control.CreateHandle () [0x0] in filename unknown :0 at System.Windows.Forms.TextBoxBase.CreateHandle () [0x0] in filename unknown :0 at System.Windows.Forms.Control.get_Handle () [0x0] in filename unknown :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:get_Handle () at System.Windows.Forms.DataGridView.ProcessKeyEventArgs (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control.ProcessKeyMessage (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control.WmKeys (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.DataGridView.WndProc (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message m) [0x0] in filename unknown :0 at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x0] in filename unknown :0 == -- Baltasar ( baltasarq@ http://baltasarq.info/) ___ Mono-list maillist - Mono-list@.ximian
Re: [Mono-winforms-list] GIF @ WinForm kinda mess
Is it an animated gif or not? Only related bug I could find: https://bugzilla.novell.com/show_bug.cgi?id=564059 supercalho3000 wrote Hello there, I'm running CS code under debian wheezy with mono 2.10 + gnome, and i have one application that i want to port. The problem is that when i run the application in debian, the gifs simply shows a bunch of lines, and unknown things, kinda glitched. PNG, and other components on the forms r nice, but gif r a bit mess. Is anyone knows what are this little issue? :D regards! -- View this message in context: http://mono.1490590.n4.nabble.com/GIF-WinForm-kinda-mess-tp4661513p4661516.html Sent from the Mono - WinForms mailing list archive at Nabble.com. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-list] C# .net app to be deployed on Linux
It really depends on the app, so it's not possible to give a simple answer. .NET apps do not need to be recompiled to run with Mono (an app compiled with .NET should run on Mono, and vice versa). However, if the .NET app uses Windows-specific code (specific paths, hard-coded separators, native code calls, etc), it will need to be modified to run on Linux. As for the database, it depends on what kind of database it is. Does the same database also exist on Linux, or do you plan to use a different kind of database on Linux? How is the database accessed? Is the connector assembly used to access the database cross platform or not? The changes needed depend on the app... But you could start by simply trying to run it and see if you get any exceptions (if the app hasn't been designed with Linux in mind, you probably will). ManasiDesh wrote Hello Folks, I have this C# .net application which talks to SQL database. Now I need to deploy the application on Linux. Do I need Mono on linux aswell? Will the C# application get compiled with Mono on Linux? Can It without any modifications talk to SQL database? If not then what are the changes I need to incoroprate? Please provide your inputs. Thanking you all in advance:) Cheers, Manasi -- View this message in context: http://mono.1490590.n4.nabble.com/C-net-app-to-be-deployed-on-Linux-tp4661408p4661411.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Socket.IsBound wrong behavior
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.
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 lt;
alistair.bush@
gt; 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 lt;
alistair.bush@
gt; wrote:
Well that certainly sucks.
On Tue, Oct 29, 2013 at 3:03 AM, Robert Jordan lt;
robertj@
gt; 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
zone.
Maybe this:
is_daylight = start.tm_isdst 0;
just before
/* For each day of the year, calculate the tm_gmtoff. */
for (day = 0; day 365; day++) {
Robert
___
Mono-devel-list mailing list
Mono-devel-list@.ximian
Re: [Mono-list] WCF knoen types
Yes, there's a WinForms regression: http://mono.1490590.n4.nabble.com/WinForms-regression-with-Mono-3-2-3-td4661029.html Not sure if it's been acknowledged by the Mono team. I haven't taken the time to file it on bugzilla. I assumed it was Windows only, but maybe not. ZZTop wrote I did but it looks like there is a problem with 3.2.3 support for WinForms. My app is WinForm app that using WCF for communications. Here is error I get with 3.2.3 System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.WindowsFormsSynchronizationContext --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.ThemeEngine --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.ThemeWin32Classic --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.KnownColors --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus --- System.DllNotFoundException: /tmp/install/lib/libgdiplus.so at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong,System.Drawing.GdiplusStartupInput,System.Drawing.GdiplusStartupOutput) at System.Drawing.GDIPlus..cctor () [0x0] in filename unknown :0 --- End of inner exception stack trace --- at System.Drawing.KnownColors..cctor () [0x0] in filename unknown :0 --- End of inner exception stack trace --- at System.Drawing.Color.get_Black () [0x0] in filename unknown :0 at System.Windows.Forms.ThemeWin32Classic..cctor () [0x0] in filename unknown :0 --- End of inner exception stack trace --- at System.Windows.Forms.ThemeEngine..cctor () [0x0] in filename unknown :0 --- End of inner exception stack trace --- at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined () [0x0] in filename unknown :0 at System.Windows.Forms.Control..ctor () [0x0] in filename unknown :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:.ctor () at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor () [0x0] in filename unknown :0 -- View this message in context: http://mono.1490590.n4.nabble.com/WCF-knoen-types-tp4661213p4661223.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Downloading Mono
When you click on Mac OS X, the description that shows up contains 3 links. Mono MRE installer | Mono MDK installer MonoDevelop So, it depends on what you want to do. If you only want to run Mono apps, then the first link (MRE) is the one for you. If you want to develop Mono apps, then you may need all 3 links (I'm not sure whether MDK includes MRE, but let's assume it doesn't). ratstar999 wrote Okay, im sorry for this post, and it is going to sound incredibly stupid, but how do i download mono? I went to the download page and clicked on my operating system, Mac OSx, and a description came up, but no download or a link/button for it. I can't seem to find where this is. I also tried searching the forms but I could't find anything. Thank you and I apologize. I am new at this. -- View this message in context: http://mono.1490590.n4.nabble.com/Downloading-Mono-tp4661204p4661206.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [Mono-dev] Removing NET_2_0 define
Well, it *is* progress on the source code, although binaries aren't be affected. IMHO, the small history noise is totally worth it. Source code control systems are not supposed to be hindrances that prevent or discourage us from making wanted code changes, no matter how minor. A while ago, Miguel and myself did the same thing (removing #if checks) on WinForms, for what it's worth. Rodrigo Kumpera wrote No, it's just that doing such work doesn't produce progress. But, OTOH, if anyone would like to work on such thing, I would not mind On Fri, Oct 18, 2013 at 10:55 AM, Alexander Köplinger alex.koeplinger@ wrote: I understand that, so the concern is that having a single commit that changes “many” files is a problem when looking at the history? *Von:* Rodrigo Kumpera lt; kumpera@ gt; *Gesendet:* Freitag, 18. Oktober 2013 16:40 *An:* Alexander Köplinger lt; alex.koeplinger@ gt; *Cc:* jonpryor@ We value the commit history as much as the current codebase. When troubleshooting mono, having a neat and simple history is of extreme value. On Fri, Oct 18, 2013 at 10:31 AM, Alexander Köplinger alex.koeplinger@ wrote: Ok, then I’ll make a PR. @Jonathan: I don’t see why this would generate “commit noise”, for me the code base would be far more readable without the #if checks. Alex *Von:* Rodrigo Kumpera lt; kumpera@ gt; *Gesendet:* Freitag, 18. Oktober 2013 15:16 *An:* Alexander Köplinger lt; alex.koeplinger@ gt; *Cc:* mono-devel-list@.ximian It can be removed. It wasn't done out of laziness. On Wed, Oct 16, 2013 at 10:00 AM, Alexander Köplinger alex.koeplinger@ wrote: As far as I understand it, Mono now only supports the 2.0 and later profiles. ** ** Wouldn’t it make sense to remove the #if NET_2_0 checks in the codebase as those are now unnecessary (every profile is now 2.0 or later)? Or are they actually required for something? If not, I’d provide a pull request to clean up those checks. ** ** Alex ** ** ___ Mono-devel-list mailing list Mono-devel-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Re-Mono-dev-Removing-NET-2-0-define-tp4661154p4661161.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-winforms-list] WinForms regression with Mono 3.2.3
This is on Windows. The WinForms app worked with Mono 2.10, but no longer with 3.2.3. I guess this affects pretty much all WinForms apps, but if not, I'm trying to run this app: https://code.google.com/p/epicedit/ Is this a known issue? Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initiali zer for System.Windows.Forms.WindowsFormsSynchronizationContext --- System.Type InitializationException: An exception was thrown by the type initializer for Sys tem.Windows.Forms.ThemeEngine --- System.TypeInitializationException: An except ion was thrown by the type initializer for System.Windows.Forms.ThemeWin32Classi c --- System.TypeInitializationException: An exception was thrown by the type i nitializer for System.Drawing.KnownColors --- System.TypeInitializationExceptio n: An exception was thrown by the type initializer for System.Drawing.GDIPlus -- - System.DllNotFoundException: /tmp/install/lib/libgdiplus.so at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong,S ystem.Drawing.GdiplusStartupInput,System.Drawing.GdiplusStartupOutput) at System.Drawing.GDIPlus..cctor () [0x000cc] in C:\cygwin\sources\mono\mcs\cl ass\System.Drawing\System.Drawing\gdipFunctions.cs:127 --- End of inner exception stack trace --- at System.Drawing.KnownColors..cctor () [0x0001a] in C:\cygwin\sources\mono\mc s\class\System.Drawing\System.Drawing\KnownColors.cs:225 --- End of inner exception stack trace --- at System.Drawing.Color.get_Black () [0x0] in C:\cygwin\sources\mono\mcs\c lass\System.Drawing\System.Drawing\Color.cs:483 at System.Windows.Forms.ThemeWin32Classic..cctor () [0x0] in C:\cygwin\sou rces\mono\mcs\class\Managed.Windows.Forms\System.Windows.Forms\ThemeWin32Classic .cs:52 --- End of inner exception stack trace --- at System.Windows.Forms.ThemeVisualStyles..ctor () [0x0] in C:\cygwin\sour ces\mono\mcs\class\Managed.Windows.Forms\System.Windows.Forms\ThemeVisualStyles. cs:45 at System.Windows.Forms.ThemeEngine..cctor () [0x0002d] in C:\cygwin\sources\m ono\mcs\class\Managed.Windows.Forms\System.Windows.Forms\ThemeEngine.cs:49 --- End of inner exception stack trace --- at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined () [0x0 ] in C:\cygwin\sources\mono\mcs\class\Managed.Windows.Forms\System.Windows.F orms\SystemInformation.cs:317 at System.Windows.Forms.Control..ctor () [0x000e3] in C:\cygwin\sources\mono\m cs\class\Managed.Windows.Forms\System.Windows.Forms\Control.cs:900 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:.ctor () at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor () [0x0] in C:\cygwin\sources\mono\mcs\class\Managed.Windows.Forms\System.Windows.Forms\ WindowsFormsSynchronizationContext.cs:45 --- End of inner exception stack trace --- at System.Windows.Forms.Control..ctor () [0x00014] in C:\cygwin\sources\mono\m cs\class\Managed.Windows.Forms\System.Windows.Forms\Control.cs:871 at System.Windows.Forms.ScrollableControl..ctor () [0x0] in C:\cygwin\sour ces\mono\mcs\class\Managed.Windows.Forms\System.Windows.Forms\ScrollableControl. cs:157 at System.Windows.Forms.ContainerControl..ctor () [0xe] in C:\cygwin\sourc es\mono\mcs\class\Managed.Windows.Forms\System.Windows.Forms\ContainerControl.cs :54 at System.Windows.Forms.Form..ctor () [0x00012] in C:\cygwin\sources\mono\mcs\ class\Managed.Windows.Forms\System.Windows.Forms\Form.cs:387 at EpicEdit.UI.MainForm..ctor (System.String[] args) [0x0] in filename un known:0 at (wrapper remoting-invoke-with-check) EpicEdit.UI.MainForm:.ctor (string[]) at EpicEdit.UI.MainForm.Main (System.String[] args) [0x0] in filename unk nown:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: An except ion was thrown by the type initializer for System.Windows.Forms.WindowsFormsSync hronizationContext --- System.TypeInitializationException: An exception was thr own by the type initializer for System.Windows.Forms.ThemeEngine --- System.Typ eInitializationException: An exception was thrown by the type initializer for Sy stem.Windows.Forms.ThemeWin32Classic --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.KnownColors --- System.TypeInitializationException: An exception was thrown by the type initia lizer for System.Drawing.GDIPlus --- System.DllNotFoundException: /tmp/install/ lib/libgdiplus.so at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong,S ystem.Drawing.GdiplusStartupInput,System.Drawing.GdiplusStartupOutput) at System.Drawing.GDIPlus..cctor () [0x000cc] in C:\cygwin\sources\mono\mcs\cl ass\System.Drawing\System.Drawing\gdipFunctions.cs:127 --- End of inner exception stack trace --- at System.Drawing.KnownColors..cctor () [0x0001a] in C:\cygwin\sources\mono\mc s\class\System.Drawing\System.Drawing\KnownColors.cs:225 --- End of inner exception stack trace ---
Re: [Mono-list] Graphics.DrawImage(...) bug not fixed till 3 years :-((
Hi, Could you post the bug report URL for reference? Thanks. biternal wrote Hi, there is a horrible bug till years in the drawimage-method of the graphics-class in System.Drawing! When you tile an image into nine segments, you have 8 border-segments and one center. If you draw and stretch these tiles to another image using the graphics-class, not all tiles are drawn and the areas keep blank/transparent! Here is an example screenshoot. I can post the sourcecode when needed. http://mono.1490590.n4.nabble.com/file/n4660949/ScreenShot_Linux_Mono_System.Drawing_Error.png -- View this message in context: http://mono.1490590.n4.nabble.com/Graphics-DrawImage-bug-not-fixed-till-3-years-tp4660949p4660952.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] What is current status of GTK#
I haven't looked closely at XWT, but personally, I hope they did *not* base all control and property names or anything else on GTK#. If they did, that'd sound like they're shoehorning other implementations to match GTK#, which sounds like bad design to me. Like trying to fit cylinders into square holes. IMO, the right way to go at it is to elevate the abstraction level with a neutral API, and I think that's what they did. Besides, some of the GTK# component names I've seen didn't look good to me, as they did not match the naming convention used elsewhere in the .NET framework (I guess they tried to more or less match the C API names, something they decided against with MonoMac). Petr Bena wrote Hi, What does it mean? Is GTK# going to be supported in future? I am afraid it will die and get replaced by xwt or something like that :( (if that is a case, I hope that mono developers make it really easy to convert existing gtk# application to xwt, by calling the controls same and properties as well, as rewriting the whole GUI of huge app is a lot of pointless work) Also, you mentioned that monodevelop is using gtk#3 is there any guide how to install and use it? I suppose that only way is to download the sources and build it myself, which may not work in windows as it would require the gtk3 libraries as well. Thank you On Tue, May 7, 2013 at 4:36 PM, Ian Norton lt; ian.norton-badrul@ gt; wrote: On Tue, May 07, 2013 at 03:28:30PM +0100, Petr Bena wrote: Hey, I already posted gtk-sharp-list but given that it's rather dead I don't expect any answer soon there. I am using gtk# as a primary graphical framework for at least 2 or more of my applications, but I haven't seen many updates recently. What is current development status? Is anyone working on it? Can we expect GTK# for gtk3 any time soon? AIUI, monodevelop4 is built using a mixture of gtk#3 and xwt. I don't think there is any stetic designer support for the gtk-3 flavor yet. I know that people are probably switching to wxt but I don't like it. I know what you mean, for me the big hole is the lack of a multi-line text entry box. I think it is a very good idea though and when using the GTK backend I'm sure it is just as responsive as regular gtk# GTK is very small and leaves smaller memory footprint than WPF or WinForms even on windows and is significantly faster, so I would prefer to just stick with native GTK rather than some library that uses GTK on linux only. Thank you for reply ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/What-is-current-status-of-GTK-tp4659603p4660936.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] A possible implementation for AssemblyName.ReferenceMatchesDefinition
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
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-list] Can't get a simple shared object to be used - DllNotFoundException
I've never done that myself, but if I remember correctly, you're not supposed to add the .so part. Just do [DllImport(libshared)]. That way, it's up to the framework to figure out the right extension depending on the OS it runs on. In other words, that'd mean it can't find your file because it's looking for libshared.so.so. thomasw234 wrote Hi, I'm trying to get my head around making use of Linux shared object files. I have created a basic C-based shared object which prints (Shared Object Called) when main() is called. Compiled it in gcc with -fPIC and got libshared.so as an output. Go into C#, add [DllImport(libshared.so)] public static extern int main(); Call main(), get a DllNotFoundException. libshared.so is in the same directory as the c# program. I thought it might be a platform problem (I'm using 64 bit fedora 18, and 64 bit mono 3.20), but I've tried building the shared object with both -m32 and -m64 arguments, with no luck. I can provide code if it helps, but the machine that I'm building is a corporate machine that isn't allowed on the internet, so I'll have to copy it out line-by-line. Thanks, Thomas -- View this message in context: http://mono.1490590.n4.nabble.com/Can-t-get-a-simple-shared-object-to-be-used-DllNotFoundException-tp4660332p4660334.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Migrating Windows C#.NET Winforms project to OSX using MonoDevelop
Unfortunately, NotifyIcon.ShowSystray() has not been implemented on Mac. References: http://mono.1490590.n4.nabble.com/SysTray-Compatibility-td4657850.html http://lists.ximian.com/pipermail/mono-bugs/2008-October/080810.html I wonder if it works if you use the X11 driver (command line: MONO_MWF_MAC_FORCE_X11=1 mono yourapp.exe). I guess it should. Otherwise, you basically have 3 options: - Implement NotifyIcon.ShowSystray() in Mono (I wish) - Not use NotifyIcon.ShowSystray() - Not use WinForms mike1972 wrote I have a C#.NET Windows Forms project which compiles, builds and runs without any problems on Windows. Now I'm trying to migrate it to OSX using Mono. The project compiles and builds, but I get an exception (see link to image below). When I double-click one of the entries in the stack trace, it says that the file couldn't be found. Does this mean that I forgot to install something when I installed Mono (i.e. something related to support for Windows.Forms) According to the mono website, WinForms should be fully supported so I'm not sure why I get the exception saying that the requested feature isn't implemented?!?! Any help is appreciated - thank you!! http://oi41.tinypic.com/i3hpxv.jpg My setup is: Mac OS X 10.8.4 IDE: MonoDevelop 3.0.6 Runtime: Mono 2.10.12 (mono-2-10/c9b270d) GTK 2.24.16 GTK# (2.12.0.0) Package version: 21012 ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Migrating-Windows-C-NET-Winforms-project-to-OSX-using-MonoDevelop-tp4660233p4660235.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Migrating Windows C#.NET Winforms project to OSX using MonoDevelop
According to the first link I gave, MoMa doesn't catch this. Andrew York wrote If it is a simple project to move to Gtk the Gtk.Window.Iconify works great but I'm going to bet that would be a lot of work for you. I have had no issues using Gtk between Windows and Linux that don't have quick a quick work around but WinForm always seems to be problematic. MoMa can be of help for cross platform development but I don't know if it would have caught this or not. On 7/18/2013 11:25 PM, Mauritz Jameson wrote: I have a C#.NET Windows Forms project which compiles, builds and runs without any problems on Windows. Now I'm trying to migrate it to OSX using Mono. The project compiles and builds, but I get an exception (see link to image below). When I double-click one of the entries in the stack trace, it says that the file couldn't be found. Does this mean that I forgot to install something when I installed Mono (i.e. something related to support for Windows.Forms) According to the mono website, WinForms should be fully supported so I'm not sure why I get the exception saying that the requested feature isn't implemented?!?! Any help is appreciated - thank you!! http://oi41.tinypic.com/i3hpxv.jpg My setup is: Mac OS X 10.8.4 IDE: MonoDevelop 3.0.6 Runtime: Mono 2.10.12 (mono-2-10/c9b270d) GTK 2.24.16 GTK# (2.12.0.0) Package version: 21012 ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list No virus found in this message. Checked by AVG - www.avg.com lt;http://www.avg.comgt; Version: 2013.0.3349 / Virus Database: 3204/6502 - Release Date: 07/18/13 -- Andrew York .NET SQL Server Developer Home: (269) 244-5237 Cell: (269) 816-2095 Email: andy@ ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Migrating-Windows-C-NET-Winforms-project-to-OSX-using-MonoDevelop-tp4660233p4660238.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono for ARM Cortex-A8
I don't know, but my understanding is that as long as an X11 server can run on it (and it seems like that's the case), then WinForms should work. Only one way to find out for sure: try it. rbaocug wrote Hello, as we know that Mono can support Winform applications, if we use Mono on ARM Cortex-A8, does it support Winform application also, or we mush use GTK# for the GUI programming. Thanks a lot! Best Regards, Henry ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-for-ARM-Cortex-A8-tp4660175p4660178.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Can this linq be optimised?
A single Substring() (to isolate the part between brackets), then a Trim()?
Or if the word between the brackets is not supposed to contain ANY space,
maybe use the Trim overload that expects a char array parameter.
Like this (except in your LINQ query):
string word = ( hello);
char[] trimChars = new char[] {'(', ' ', ')'};
string result = word.Trim(trimChars);
PS: if it works and is fast enough, then maybe it's good enough. It may look
(and actually be) inefficient, but if it doesn't affect users, don't bother
unless you've got time to kill. You might also be interested in double
checking Regex performances, but I'd expect it to be slower.
nodoid wrote
Hi,
I have a class containing ints, strings and anything else you'd expect
to find in a class. I create a list of the class and then extract the
strings and perform a Distinct() on them. That bit is easy.
Problem is this - the strings all have something in brackets. Sometimes
the braces have a space on the inside before and after the single word
inside of them and sometimes they don't.
My LINQ query looks like this
List
string
tmp = (from m in cropTypes
let cw = m.CropName
let kw = cw.Substring(0,
cw.LastIndexOf()) + 1)
let t = kw.IndexOf('(')
let p1 = kw.Substring(0, t)
let p2 = kw.Substring(t, (kw.Length -
1) - t + 1).Replace( , string.Empty)
let p3 = p1 + p2
select p3).Distinct().ToList();
This query works fine but looks inefficient. Is there a way to rewrite
this to remove any spaces inside of the braces?
Thanks
Paul
--
Space, it says, is big. Really big. You just won't believe how
vastly, hugely, mindbogglingly big it is. I mean, you may think it's a
long way down the road to the chemist's, but that's just peanuts to
space, listen...
Hitch Hikers Guide to the Galaxy, a truly remarkable book!
___
Mono-list maillist -
Mono-list@.ximian
http://lists.ximian.com/mailman/listinfo/mono-list
--
View this message in context:
http://mono.1490590.n4.nabble.com/Can-this-linq-be-optimised-tp4659853p4659859.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Can this linq be optimised?
Tried string.Trim(trimChars); yet? nodoid wrote Hi, can you give us some example strings? Sure. The names can be in either the form of ( foo ) or (foo) of ( foo) or (foo ) (though the last two are rare) Paul -- Space, it says, is big. Really big. You just won't believe how vastly, hugely, mindbogglingly big it is. I mean, you may think it's a long way down the road to the chemist's, but that's just peanuts to space, listen... Hitch Hikers Guide to the Galaxy, a truly remarkable book! ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Can-this-linq-be-optimised-tp4659853p4659863.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] ZipArchive?
I also like Ionic.Zip better (the API seems a bit more natural / modern to me), but sometimes had to use SharpZipLib for GPL projects, which can't use non-GPL libraries. Ian Norton-3 wrote I tend to use ionic.zip On 28 May 2013 13:51, Madsn lt; madsn@ gt; wrote: Hi, I had hoped to find the System.IO.Compression.ZipArchive class when using mono .net 4.5, but didn't find it. Will it be supported or are there copyright issues or something? (Or didn't I just look hard enough) In case it won't be supported, I have seen several third party zip libraries. Anyone having any experiences which todays libraries? -- View this message in context: http://mono.1490590.n4.nabble.com/ZipArchive-tp4659787.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/ZipArchive-tp4659787p4659801.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] java parser in C#
May not be exactly what you're looking for, but check it out if you don't know about it: http://www.ikvm.net/ mutasim wrote Good Day i think mono C# compiler can handle the java source excution as the parser of java is not different from C# just few syntaxes will be modify, as there alot of programmers using java for there development , and add java to the .net platform will return the J# to the developers -- View this message in context: http://mono.1490590.n4.nabble.com/java-parser-in-C-tp4659251p4659255.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Xamarin 2.0 concern
Well, in Xamarin team's defense, I have to say MonoTouch and Mono for Android were not very clear or consistent names. Dropping the Mono name is a bit sad, but I hope it'll succeed. Doug wrote I don't really see it as a big issue; companies rebrand all the time. The mono 'brand' is encumbered by a bunch of negative associations, largely to do with it being abandoned by novell, discarded by linux, a second class citizen to the 'official' windows C# runtime. Abandoning the name to try to build a new brand isn't a new idea; building a sustainable company when your core product has these associations attached to it must be painful. Did you read the hacker news responses to the new products? Generally positive, but full of 'cross platform UI's don't work' comments. Ouch. Yes, moonlight (and silverlight) were a waste of time and no one liked or used them. ...but that's history now. That's why the new product suite is all about creating native user interfaces for different platforms and binding them to a common backend logic. This seems to be a much more successful approach, but because of the legacy of moonlight, people don't immediately appreciate that, and stay away. There's a lot of really great work going on here, (never mind the increasingly popular MonoGame drawing developers in). I think your comments are a little unjustified. It's just a brand name change. All the code is up on github; it's not going anywhere. ~ Doug. On Sat, Feb 23, 2013 at 10:54 PM, Dimitar Dobrev lt; dpldobrev@ gt;wrote: Hello, all, I guess most of you see the announcement of Xamarin 2.0 as good news. However, I cannot help but feel the opposite. Let me tell you why: 1. At the Xamarin 2.0 FAQ lt;http://xamarin.com/xamarin-2.0-faqgt; it says: Our new product brands are: Xamarin.iOS (replaces MonoTouch) Xamarin.Android (replaces Mono for Android) Xamarin Studio, our new IDE (replaces MonoDevelop) That is, the name Mono is now completely phased out of the Xamarin product line. At the Xamarin Studio page lt;http://xamarin.com/studiogt; , MonoDevelop, upon which the Studio is based, is not mentioned once! Are you ashamed of MonoDevelop after you've been offering it to customers for years? At the Xamarin main page lt;http://xamarin.com/gt; Mono is mentioned only once at the very bottom, under the Community section - is Mono no longer part of Xamarin itself? I think this is not the beginning but rather the end of a process that started with the renaming of MonoMac to Xamarin.Mac (and please don't tell me MonoMac is our community-supported version because I haven't heard about it since). Then was the renaming of YOUR MonoSpace conference to MonkeySpace and the explanation was really ridiculous - bigger scope... open source .NET development in general (Miguel de Icaza at that very same MonkeySpace conference). What bigger scope? .NET runs only on Windows, be it desktop or phone, while Mono runs on tens of platforms, including Windows. Yes, I do understand it's about the scope of the community but how broader is that community since the only significant piece of .NET missing in Mono is WPF? Mono is the core of your company, both historically and at present, since all of your products are based on it. And you are removing its name from anywhere it's mentioned. I don't see this as justified even for marketing reasons because if people know about you, it's because of Mono. That is, Mono is your marketing message. If you do reply to this mail, I'd really like to hear something a little deeper that The change of our product names does not mean we are abandoning Mono, we are going to support it just as before. We all know how this works out: the name is abandoned, time passes, many current users forget about it, new users do not learn it at all, and after a little more time the project itself is abandoned. This kind of tactics reminds me of a very specific company which leads me to: 2. Microsoft Joins Xamarin Evolve 2013 as Sole Platinum Sponsor http://blog.xamarin.com/microsoft-joins-xamarin-evolve-2013-as-sole-platinum-sponsor/ - I believe Microsoft have proven time and time again that they are enemies of Mono in particular and of open source in general. I do not want to quote a large part of the web on that but let me say a few words just about Mono. Miguel, you may remember you said Microsoft as a company are not open-source-friendly yourself at FOSDEM at the beginning of 2011. You may also remember how you at the same conference you told the story how you showed your C# REPL to Microsoft just before PDC 2008 and once they saw that, they changed their program and rushed their C# REPL with the only intent of showing it before you did. The proof that they didn't have a working product back then (while you did) lies in the simple fact that now, 5 (five!) years later
Re: [Mono-list] Xamarin 2.0 concern
As I said, not clear *or* not consistent, depending on the name. MonoTouch is not clear. There are many touch devices, you can't guess it's for iOS from its name. Mono for Android *is* clear, but not consistent (with the MonoTouch name). MonoDroid was more consistent (Mono+short name, no space or multiple words). Or for clarity over brevity, MonoTouch should have been called Mono for iOS, to fit with Mono for Android. Dimitar Dobrev wrote Stifu, Besides all said above, I would argue a bit further on these names. Clarity - for Android could not be clearer, even the old Monodroid was clear enough to me; Touch -yes, a bit vague but at the time MonoTouch was initially released there was only one widely distributed touch platform. About consistency - Mono is present in both names, I cannot see how more consistent it can get. Anyway, I'm not saying they should've necessarily kept these names, I'm saying they should've kept Mono in them. -- View this message in context: http://mono.1490590.n4.nabble.com/Xamarin-2-0-concern-tp4658722p4658728.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] OT: Re: Why Gnome prefer JavaScript?
You'll find better explanations online, but basically, they share the Java
bit for stupid marketing reasons. Java was getting popular back then, and so
slapping Java on random things sounded good to some people. Some insist on
calling JavaScript ECMAScript, but it's too late now.
Ian Norton-Badrul-2 wrote
On Tue, Feb 05, 2013 at 04:18:16PM +, Jonathan Pryor wrote:
On Feb 5, 2013, at 10:23 AM, Alberto León lt;
leontiscar@
gt; wrote:
But, JavaScript was the reason to Oracle denounced Google.
No, Java as why Oracle sued Google. JavaScript is completely different.
It's kinda/sorta/not-really like comparing C and Perl -- sure, they both
use '{' for blocks, but other than that...completely different.
Anyone know why Java and Javascript share the Java bit?
Ian
___
Mono-list maillist -
Mono-list@.ximian
http://lists.ximian.com/mailman/listinfo/mono-list
--
View this message in context:
http://mono.1490590.n4.nabble.com/Why-Gnome-prefer-JavaScript-tp4658473p4658482.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Performance of Mono 2.10 vs. Mono 3.0
I think you should file a bug on bugzilla, and attach your benchmark on it. Charles Esterbrook-2 wrote Hi, I have a benchmark for my project which takes the following number of milliseconds to run based on System.Diagnostics.Stopwatch, expressed in ranges: Mono JIT compiler version 2.10.9 (tarball Mon May 7 20:25:51 EDT 2012) 6888 - 6943 - default gc / boehm 5850 - 5932 - sgen Mono JIT compiler version 3.0.3 (master/39c48d5 Tue Jan 8 12:12:24 EST 2013) 9815 - 9892 - default gc / boehm 8454 - 8502 - sgen My system is Mac OS X 10.6.8, Intel Xeon. I shut down web browsers, cloud services and other apps to reduce interference, and I also ran multiple times, hence the ranges. The slowdown is about 40%. My program does a variety of things including loading assemblies, reflection, file i/o, string processing, data structures, etc. I have not yet investigated to see if some parts are slowing down more than others. What about other people on this list? If you test the performance of your apps between Mono 2.10 and 3.0, is there a change? How much and in what direction? For your convenience: https://www.google.com/search?q=.net+stopwatch -- Charles Esterbrook http://charles-esterbrook.com ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Performance-of-Mono-2-10-vs-Mono-3-0-tp4658182p4658183.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Absolute beginner
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-list] Windows Forms App under Mac OS X Mono
WinForms works the worst on Mac. Although I don't have a Mac, I recommend the users of my WinForms app to run their app this way, and it seems to work fine for them: MONO_MWF_MAC_FORCE_X11=1 mono yourapp.exe That makes it so it runs the app using the X11 driver rather than the Mac (Carbon) one, which means the app should work as well as on Linux. The only problem is that it requires an X11 server to be installed on the Mac. jeff clausius wrote I'm investigating Mono as a possible solution for porting a Windows Forms based app to OS X. As a test, I've created a small C# app. The Main form contains a button which invokes another window with the following code in the _Click() event: Form2 f2 = new Form2(); f2.ShowDialog(); f2.Dispose(); Form2 has a button which just calls Close(); No other real code in the test app. I'm running into problems on a Mac OS X Lion (10.7.5) computer, I've installed/tested the app against Mono SDK 2.10.9 and 3.0.1. I've also tried binaries compiled with MonoDevelop (3.0.5) as well as one from VS 2010. Testing involves clicking Form1's Button #1 (to show Form2) and Button #2 (on Form 2) to close Form2. Clicking these buttons over and over eventually causes the mono app to bring up 3 to 5 simultaneous Form2s. The topmost Form2 is the normal one w/ default coloring and Button #2. However, the underneath dialogs are blank windows w/ a white background and no layout of any kind for Button #2. You cannot even close these forms w/ the X close button. After this occurs, if I close Form1, the mono process hangs, and Ctrl-C is req'd to kill the process. Also, the following is displayed in the shell which launched the app: user$ mono WindowsFormsMonoTest.exe Nov 27 18:35:16 comp-lion.local mono[210] Error : kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection Nov 27 18:35:16 comp-lion.local mono[210] Error : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. ^C Has anyone seen this before? Seems like a simple case which should work under Mac OS X. Can anyone suggest possible solutions? Is it a mismatch between X11 and/or GTK versions and Mono? Any other possibilities? BTW, I have the sample source if anyone would like to see this firsthand. TIA, Jeff Clausius ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Windows-Forms-App-under-Mac-OS-X-Mono-tp4657557p4657560.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Installing mono to cygwin
That sounds too complicated and twisted, especially if you're trying to get people to use the app. If Tomboy has to be fixed, then you should get in touch with one of the maintainers. I found this related 4-year old article: http://automorphic.blogspot.fr/2008/10/tomboy-preview-for-windows-and-mac.html apollothethird wrote I'm not totally sure what you mean. If you mean what I think you mean, that was what I tried first. I'll explain my objective. I'm trying to use Tomboy notes on a Windows machine. I discovered Tomboy notes with my Linux machine... Linux of which I personally run exclusive. Now what I'm trying to introduce this jewel to my friends, family, and associates who I haven't converted to Linux yet. In this effort I installed Windows on a support machine of which I'm trying to get Tomboy notes functioning. I spent two weeks trying to get Tomboy to install on Windows 7. I couldn't get past the error message of the Tomboy installer not recognizing mono is installed, even though I have installed it numerous times and added the bin directory to the OS' path in such that mono brings up the help screen from any window. So I have installed almost 2gigs of Cygwin to try to get Tomboy working this way. Thus I'm at the point of trying to get the Mono dependency installed. I'm only on Cygwin for two days. I appear to be making progress faster here with Cygwin than I was making on Windows. -- L. James -- L. D. James lja...@apollo3.com www.apollo3.com/~ljames -- View this message in context: http://mono.1490590.n4.nabble.com/Installing-mono-to-cygwin-tp4657535p4657545.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Parallel.ForEach MaxDegreeOfParallelism
You're aware we're not supposed to look into the .NET code, because then that
prevents us from contributing to Mono, yes?
Because of you, I guess I cannot contribute to Mono anymore. :p
Karol wrote
ok i found solution to this problem
after digging a little with ILSpy i found out that there is difference in
implementation of TaskScheduler.MaximumConcurrencyLevel between MS.NET and
Mono:
MS.NET :
public virtual int MaximumConcurrencyLevel
{
get
{
return 2147483647;
}
}
MONO:
public virtual int MaximumConcurrencyLevel
{
get
{
return Environment.ProcessorCount;
}
}
(this difference was making my app work like 10 times slower on Mono than
it was on MS.NET)
i dont know if this should be considered a bug ?
i think portability of .NET code between windows and other OS'es should be
threated as main feature of Mono
--
View this message in context:
http://mono.1490590.n4.nabble.com/Parallel-ForEach-MaxDegreeOfParallelism-tp4657494p4657496.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Newbie question - not sure which path to take
I don't know what's GDI2 (GDI+?), but if your C# assembly is fully managed (doesn't call native code), then you don't need to convert anything, and can just directly run your assembly with Mono. mettafort wrote Hi, I currently have a windows C# assembly that generates computer graphics using GDI2. I need this to run on a web server that is Linux, so my assumption here is that I need to convert it to mono. If Mono is the only way I can get this to run, which path do I take? I need to generate image files basically, whcih can be served up by the main perl/php website. So I just need to be able to call onto my code, I generate the image file to some location, and the website serves it up. Sounds simple, and I hope it is :-) Thanks for any advice, MF. -- View this message in context: http://mono.1490590.n4.nabble.com/Newbie-question-not-sure-which-path-to-take-tp4657011p4657013.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, do NOT run after Microsoft !!
It's obvious you're the OP under another nickname. Go troll elsewhere. unistd wrote So many stupid new programmers... You all are just slaves of Microsoft and .net. I find other programmers in other platform like Java, c++ get more respect and more salary than programmers in .net platform. Now, I find the reason. -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-do-NOT-run-after-Microsoft-tp4656785p4656911.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] GTKsharp 3
I believe the answers you're looking for are in the link I gave. Daniel Hughes wrote XWT although interesting is irrelevant to the question at hand. XWT will use GTK on linux and so will still require working GTK 3 bindings. So can we get back to the topic, I would love answers to my questions regarding GTK Sharp 3 Who is working on it? Where is the code? When should we expect a release? Sincerely, Daniel On Wed, Sep 12, 2012 at 5:50 AM, Stifu lt;stifu@gt; wrote: Yes, eventually it has to use native code. But I guess the difference is whether the GUI toolkit is made using solely the .NET / Mono framework, or by shipping extra native code. Mono WinForms, as I mentioned, mostly relies on the framework (using System.Drawing rather than calling an extra library to draw on screen, for example). It still has some native calls (platform-specific code), so it's not 100% managed, but close enough. Ian Norton-Badrul-2 wrote How do you expect to put anything on the screen or read the mouse, keyboard etc without eventually using a native toolkit :) XWT is very cool, not 100% working for me yet but a very good start. On 11/09/2012 16:34, Stifu wrote: XWT is still a set of bindings. It calls native code / GUI toolkits underneath. So that's not what he was asking for. I guess there is just not enough money / motivation behind having a fully-managed GUI toolkit. On the other hand, Mono WinForms is one, technically. Slide wrote There is this one that is being developed https://github.com/mono/xwt and will be the foundation of MonoDevelop in the future from what I understand. On Tue, Sep 11, 2012 at 8:19 AM, 殷启聪 lt;seamlikok@gt; wrote: Why there's no any cross-platform GUI toolkit that's written natively in C#? I'm tired of using bindings. Is it possible to develop a C# GUI toolkit that's OpenGL accelerated (like WPF and Clutter), cross-platform (like wxWidgets and Qt) and uses native widgets in different desktop environment? Then GTK+, Qt etc. will be used as low level components. 2012/9/11 Stifu lt;stifu@gt;: The most recent bit of news I've read about GTK# 3: http://mono.1490590.n4.nabble.com/Towards-GTK-3-0-tp4650597.html Daniel Hughes wrote GTK 3 was released 10 Feb 2011. That's a long time ago. During that time .net bindings have failed to eventuate. Information on what has been happening has been very hard to find, despite a large number of .net applications on linux using these bindings. As the author of an opensource application dependent on these bindings I find this lack of information very concerning. And I'm starting to ask myself questions like, Am I now dependent of a dead or dieing library? Banshee was removed from the default ubuntu install, officially because of lack of GTK 3 support. I have the following questions: Where is the source code for GTK 3 support? As far as I can establish the GTK sharp code is hosted here: https://github.com/mono/gtk-sharplt;https://github.com/mono/gtk-sharp/branchesgt ; However there is no branch in there labelled as GTK3 Who supports GTK sharp? If it is community maintained, who are the main contributors? Is there a projected or planned release date for GTK 3 support? Developers dependent on GTK sharp need this information in order to plan the future of there applications. If GTK sharp is really dying then application developers dependent on it need to know, so they can either contribute to it or move there applications on to something else. If the bindings are struggling, how come there has been no call for contributors, or at least transparent information about what is going on. Rather then the current back whole of information. Recently ubuntu held an app competition, it was hugely successful and while it was on people where asking questions like this: http://askubuntu.com/questions/154373/use-primary-toolbar-with-mono And all we could do was advice that they use another language. If we lose GTK# bindings where does that leave mono on desktop linux? We have no QT bindings, no clutter bindings and no GTK# 3 bindings. in sort we have no bindings available (by that I mean packaged in debian or similar) for the latest version of any native linux GUI tool kit. I'm going to say this again, mono developers cannot use the latest version of any native linux GUI tool kit. Now maybe the GTK# bindings are alive and well and are about to issue a release. However if that is true then the developers have a lot of room for improvement with there communications. Sincerely, Daniel Hughes ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/GTKsharp-3
Re: [Mono-list] GTKsharp 3
Err, you can't do that. Daniel Lo Nigro wrote How would you use native widgets without using bindings of some sort? On Wed, Sep 12, 2012 at 1:19 AM, 殷启聪 lt;seamlikok@gt; wrote: Why there's no any cross-platform GUI toolkit that's written natively in C#? I'm tired of using bindings. Is it possible to develop a C# GUI toolkit that's OpenGL accelerated (like WPF and Clutter), cross-platform (like wxWidgets and Qt) and uses native widgets in different desktop environment? Then GTK+, Qt etc. will be used as low level components. 2012/9/11 Stifu lt;stifu@gt;: The most recent bit of news I've read about GTK# 3: http://mono.1490590.n4.nabble.com/Towards-GTK-3-0-tp4650597.html Daniel Hughes wrote GTK 3 was released 10 Feb 2011. That's a long time ago. During that time .net bindings have failed to eventuate. Information on what has been happening has been very hard to find, despite a large number of .net applications on linux using these bindings. As the author of an opensource application dependent on these bindings I find this lack of information very concerning. And I'm starting to ask myself questions like, Am I now dependent of a dead or dieing library? Banshee was removed from the default ubuntu install, officially because of lack of GTK 3 support. I have the following questions: Where is the source code for GTK 3 support? As far as I can establish the GTK sharp code is hosted here: https://github.com/mono/gtk-sharplt;https://github.com/mono/gtk-sharp/branchesgt ; However there is no branch in there labelled as GTK3 Who supports GTK sharp? If it is community maintained, who are the main contributors? Is there a projected or planned release date for GTK 3 support? Developers dependent on GTK sharp need this information in order to plan the future of there applications. If GTK sharp is really dying then application developers dependent on it need to know, so they can either contribute to it or move there applications on to something else. If the bindings are struggling, how come there has been no call for contributors, or at least transparent information about what is going on. Rather then the current back whole of information. Recently ubuntu held an app competition, it was hugely successful and while it was on people where asking questions like this: http://askubuntu.com/questions/154373/use-primary-toolbar-with-mono And all we could do was advice that they use another language. If we lose GTK# bindings where does that leave mono on desktop linux? We have no QT bindings, no clutter bindings and no GTK# 3 bindings. in sort we have no bindings available (by that I mean packaged in debian or similar) for the latest version of any native linux GUI tool kit. I'm going to say this again, mono developers cannot use the latest version of any native linux GUI tool kit. Now maybe the GTK# bindings are alive and well and are about to issue a release. However if that is true then the developers have a lot of room for improvement with there communications. Sincerely, Daniel Hughes ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/GTKsharp-3-tp4656569p4656570.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/GTKsharp-3-tp4656569p4656590.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] GTKsharp 3
The most recent bit of news I've read about GTK# 3: http://mono.1490590.n4.nabble.com/Towards-GTK-3-0-tp4650597.html Daniel Hughes wrote GTK 3 was released 10 Feb 2011. That's a long time ago. During that time .net bindings have failed to eventuate. Information on what has been happening has been very hard to find, despite a large number of .net applications on linux using these bindings. As the author of an opensource application dependent on these bindings I find this lack of information very concerning. And I'm starting to ask myself questions like, Am I now dependent of a dead or dieing library? Banshee was removed from the default ubuntu install, officially because of lack of GTK 3 support. I have the following questions: Where is the source code for GTK 3 support? As far as I can establish the GTK sharp code is hosted here: https://github.com/mono/gtk-sharplt;https://github.com/mono/gtk-sharp/branchesgt; However there is no branch in there labelled as GTK3 Who supports GTK sharp? If it is community maintained, who are the main contributors? Is there a projected or planned release date for GTK 3 support? Developers dependent on GTK sharp need this information in order to plan the future of there applications. If GTK sharp is really dying then application developers dependent on it need to know, so they can either contribute to it or move there applications on to something else. If the bindings are struggling, how come there has been no call for contributors, or at least transparent information about what is going on. Rather then the current back whole of information. Recently ubuntu held an app competition, it was hugely successful and while it was on people where asking questions like this: http://askubuntu.com/questions/154373/use-primary-toolbar-with-mono And all we could do was advice that they use another language. If we lose GTK# bindings where does that leave mono on desktop linux? We have no QT bindings, no clutter bindings and no GTK# 3 bindings. in sort we have no bindings available (by that I mean packaged in debian or similar) for the latest version of any native linux GUI tool kit. I'm going to say this again, mono developers cannot use the latest version of any native linux GUI tool kit. Now maybe the GTK# bindings are alive and well and are about to issue a release. However if that is true then the developers have a lot of room for improvement with there communications. Sincerely, Daniel Hughes ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/GTKsharp-3-tp4656569p4656570.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] GTKsharp 3
XWT is still a set of bindings. It calls native code / GUI toolkits underneath. So that's not what he was asking for. I guess there is just not enough money / motivation behind having a fully-managed GUI toolkit. On the other hand, Mono WinForms is one, technically. Slide wrote There is this one that is being developed https://github.com/mono/xwt and will be the foundation of MonoDevelop in the future from what I understand. On Tue, Sep 11, 2012 at 8:19 AM, 殷启聪 lt;seamlikok@gt; wrote: Why there's no any cross-platform GUI toolkit that's written natively in C#? I'm tired of using bindings. Is it possible to develop a C# GUI toolkit that's OpenGL accelerated (like WPF and Clutter), cross-platform (like wxWidgets and Qt) and uses native widgets in different desktop environment? Then GTK+, Qt etc. will be used as low level components. 2012/9/11 Stifu lt;stifu@gt;: The most recent bit of news I've read about GTK# 3: http://mono.1490590.n4.nabble.com/Towards-GTK-3-0-tp4650597.html Daniel Hughes wrote GTK 3 was released 10 Feb 2011. That's a long time ago. During that time .net bindings have failed to eventuate. Information on what has been happening has been very hard to find, despite a large number of .net applications on linux using these bindings. As the author of an opensource application dependent on these bindings I find this lack of information very concerning. And I'm starting to ask myself questions like, Am I now dependent of a dead or dieing library? Banshee was removed from the default ubuntu install, officially because of lack of GTK 3 support. I have the following questions: Where is the source code for GTK 3 support? As far as I can establish the GTK sharp code is hosted here: https://github.com/mono/gtk-sharplt;https://github.com/mono/gtk-sharp/branchesgt; However there is no branch in there labelled as GTK3 Who supports GTK sharp? If it is community maintained, who are the main contributors? Is there a projected or planned release date for GTK 3 support? Developers dependent on GTK sharp need this information in order to plan the future of there applications. If GTK sharp is really dying then application developers dependent on it need to know, so they can either contribute to it or move there applications on to something else. If the bindings are struggling, how come there has been no call for contributors, or at least transparent information about what is going on. Rather then the current back whole of information. Recently ubuntu held an app competition, it was hugely successful and while it was on people where asking questions like this: http://askubuntu.com/questions/154373/use-primary-toolbar-with-mono And all we could do was advice that they use another language. If we lose GTK# bindings where does that leave mono on desktop linux? We have no QT bindings, no clutter bindings and no GTK# 3 bindings. in sort we have no bindings available (by that I mean packaged in debian or similar) for the latest version of any native linux GUI tool kit. I'm going to say this again, mono developers cannot use the latest version of any native linux GUI tool kit. Now maybe the GTK# bindings are alive and well and are about to issue a release. However if that is true then the developers have a lot of room for improvement with there communications. Sincerely, Daniel Hughes ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/GTKsharp-3-tp4656569p4656570.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- Website: http://earl-of-code.com ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/GTKsharp-3-tp4656569p4656579.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] GTKsharp 3
Yes, eventually it has to use native code. But I guess the difference is whether the GUI toolkit is made using solely the .NET / Mono framework, or by shipping extra native code. Mono WinForms, as I mentioned, mostly relies on the framework (using System.Drawing rather than calling an extra library to draw on screen, for example). It still has some native calls (platform-specific code), so it's not 100% managed, but close enough. Ian Norton-Badrul-2 wrote How do you expect to put anything on the screen or read the mouse, keyboard etc without eventually using a native toolkit :) XWT is very cool, not 100% working for me yet but a very good start. On 11/09/2012 16:34, Stifu wrote: XWT is still a set of bindings. It calls native code / GUI toolkits underneath. So that's not what he was asking for. I guess there is just not enough money / motivation behind having a fully-managed GUI toolkit. On the other hand, Mono WinForms is one, technically. Slide wrote There is this one that is being developed https://github.com/mono/xwt and will be the foundation of MonoDevelop in the future from what I understand. On Tue, Sep 11, 2012 at 8:19 AM, 殷启聪 lt;seamlikok@gt; wrote: Why there's no any cross-platform GUI toolkit that's written natively in C#? I'm tired of using bindings. Is it possible to develop a C# GUI toolkit that's OpenGL accelerated (like WPF and Clutter), cross-platform (like wxWidgets and Qt) and uses native widgets in different desktop environment? Then GTK+, Qt etc. will be used as low level components. 2012/9/11 Stifu lt;stifu@gt;: The most recent bit of news I've read about GTK# 3: http://mono.1490590.n4.nabble.com/Towards-GTK-3-0-tp4650597.html Daniel Hughes wrote GTK 3 was released 10 Feb 2011. That's a long time ago. During that time .net bindings have failed to eventuate. Information on what has been happening has been very hard to find, despite a large number of .net applications on linux using these bindings. As the author of an opensource application dependent on these bindings I find this lack of information very concerning. And I'm starting to ask myself questions like, Am I now dependent of a dead or dieing library? Banshee was removed from the default ubuntu install, officially because of lack of GTK 3 support. I have the following questions: Where is the source code for GTK 3 support? As far as I can establish the GTK sharp code is hosted here: https://github.com/mono/gtk-sharplt;https://github.com/mono/gtk-sharp/branchesgt; However there is no branch in there labelled as GTK3 Who supports GTK sharp? If it is community maintained, who are the main contributors? Is there a projected or planned release date for GTK 3 support? Developers dependent on GTK sharp need this information in order to plan the future of there applications. If GTK sharp is really dying then application developers dependent on it need to know, so they can either contribute to it or move there applications on to something else. If the bindings are struggling, how come there has been no call for contributors, or at least transparent information about what is going on. Rather then the current back whole of information. Recently ubuntu held an app competition, it was hugely successful and while it was on people where asking questions like this: http://askubuntu.com/questions/154373/use-primary-toolbar-with-mono And all we could do was advice that they use another language. If we lose GTK# bindings where does that leave mono on desktop linux? We have no QT bindings, no clutter bindings and no GTK# 3 bindings. in sort we have no bindings available (by that I mean packaged in debian or similar) for the latest version of any native linux GUI tool kit. I'm going to say this again, mono developers cannot use the latest version of any native linux GUI tool kit. Now maybe the GTK# bindings are alive and well and are about to issue a release. However if that is true then the developers have a lot of room for improvement with there communications. Sincerely, Daniel Hughes ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/GTKsharp-3-tp4656569p4656570.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- Website: http://earl-of-code.com ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com
Re: [Mono-list] Which GUI?
On the other hand, note that both MonoDevelop and Banshee teams plan to replace their application GUI. Banshee: GTK# 2 to GTK# 3 (not released yet) MonoDevelop: GTK# 2 to XWT (not released yet either: https://github.com/mono/xwt) Daniel Lo Nigro wrote I'd suggest trying out GTK# if you're developing a desktop application. This is the same toolkit used by most Mono applications on Linux, like MonoDevelop and Banshee media player. If you want a very custom UI, you could probably use an OpenGL wrapper like OpenTK for the UI rendering. If it's a web application, I'd suggest using ASP.NET MVC. It's open-source and works fine on Mono. ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Which-GUI-tp4656530p4656562.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Questions about coding style
To add to what Jonathan said, trying to reuse the same connection for
everything can also lead to concurrent access issues, if more than one
thread accesses the connection at a given time. I've seen such issues when
using Entity Framework. Besides, creating a new connection is really cheap.
Jonathan Pryor wrote
On Aug 20, 2012, at 3:28 PM, Philippe Grohrock lt;philippe.grohrock@gt;
wrote:
Thanks for the reply already and I'm sorry, I should've added the lines
of code.
static class GlobalVariables
{
public static MySqlConnection connection = new connection();
}
This way the whole program has access to it and can modify/query the DB
when needed (this is what I meant with global).
I believe that this is a Bad Idea™.
Firstly, this is counter to ~every MSDN example on using connections,
which always scopes the Connection instance:
//
http://msdn.microsoft.com/en-us/library/ff647768.aspx#scalenetchapt12_topic9
using (SqlConnection conn = new SqlConnection(connString))
{
conn.Open();
// ...
}
This implies that you should instead do:
static class Database {
internal static MySqlConnection CreateConnection ()
{
return new connection ();
}
}
And narrowly scope your use:
using (var c = Database.CreateConnection ()) {
c.Open ();
// ...
}
Now, _why_ should you do this? Unfortunately I can't find anything to
confirm or deny the following, but this is my recollection from using SQL
many years ago...
The reason why is connection-related errors: if (when) you hit a network
interruption, the DbConnection instance is unusable afterward, even if the
network came back. (Though maybe I needed to .Close() and .Open() to
repair the instance? I no longer remember.) I found that the
easiest/sanest way to go was to just recreate the Connection instance when
needed, and Dispose() of it as soon as possible (relying on lower-level
connection pooling if possible).
- Jon
___
Mono-list maillist - Mono-list@.ximian
http://lists.ximian.com/mailman/listinfo/mono-list
--
View this message in context:
http://mono.1490590.n4.nabble.com/Questions-about-coding-style-tp4656301p4656333.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Patches for mono-winforms
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
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
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 lt;ulatekh@gt; To: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt; 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
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 lt;ulatekh@gt; To: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt; 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
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-list] .Net versions ... compatibility history
Sounds good. Even better if the tests are automated, so you can just run them on each OS (using NUnit and/or other test frameworks). Note that the application doesn't have to be a separate product for each OS. It depends on your app. Just check first that you're not planning to use big .NET APIs that are not supported in Mono. Another idea if you want to be safer and minimize possible surprises: develop with Mono, then test with .NET. Again, whether this is a good idea or not depends on your app. edward.harvey.mono wrote From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. Ahh. I was understanding before, that any given mono version is not 100% compatible with any particular .Net version, but perhaps I wasn't understanding well enough... Here's my new perception - The goal is to develop some applications cross-platform compatible (specifically, windows, mac, ubuntu, centos). It is understood that the application for each platform will be a separate product, we can't just reuse all the code and expect it to work on another platform.But we'd like to maximize the code reuse. It's understood, the only way to do this is to start developing on one platform, and obsessively frequently test the code on multiple platforms. The goal is to minimize the incompatibilities between platforms... So I guess the best approach is ... First of all, start with .Net 3.5 on windows. Expect most of it to work on mac, ubuntu, and centos 6. But don't hold high hopes for centos 5. Test obsessively, with every little change. Sound about right? ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650786.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
For the record: Entity Framework has been open sourced, and Mono will probably support it soon. Dave Curylo wrote In my experience, if you don't stray to far away from the core framework, you are in very good shape with API support. Stay away from things like Entity Framework and WPF (completely unsupported), use things like WCF and server components should be done with caution, but LINQ, TPL, or other parts of the core framework have very robust and well-tested implementations and you are much less likely to encounter issues. Of course you should test, and particularly load test, across platforms as some of the internals work a little differently and bugs can pop up in unexpected scenarios. As far as the runtime version included in various Linux distributions, in many cases it is better to package the runtime with your application. RHEL / CentOS have an old mono distribution by way of the EPEL repository and by nature, that distribution uses older software versions. This isn't just a mono constraint; if you have a python application that relies on python 2.4 (which is from 2006), then you need to package your own python to distribute to RHEL / CentOS. I wouldn't let the OS dictate the runtime you should use if it is simply a matter of packaging a newer runtime with your application. The OS can only really dictate the shared runtime version. On Aug 7, 2012, at 7:41 AM, edward.harvey.mono wrote: From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. Ahh. I was understanding before, that any given mono version is not 100% compatible with any particular .Net version, but perhaps I wasn't understanding well enough... Here's my new perception - The goal is to develop some applications cross-platform compatible (specifically, windows, mac, ubuntu, centos). It is understood that the application for each platform will be a separate product, we can't just reuse all the code and expect it to work on another platform.But we'd like to maximize the code reuse. It's understood, the only way to do this is to start developing on one platform, and obsessively frequently test the code on multiple platforms. The goal is to minimize the incompatibilities between platforms... So I guess the best approach is ... First of all, start with .Net 3.5 on windows. Expect most of it to work on mac, ubuntu, and centos 6. But don't hold high hopes for centos 5. Test obsessively, with every little change. Sound about right? ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650789.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
Keep in mind that just because a certain Mono version supports a certain .NET profile, doesn't mean it fully supports everything in that profile. For example, Mono 2.0 supports .NET 2.0 and 3.5, but has many missing 3.5 bits. Even the latest Mono versions do not support all the APIs .NET does. So things are not as simple as deciding which .NET version you want to support. By the way, check out the Mono wikipedia page: http://en.wikipedia.org/wiki/Mono_%28software%29#History It may give you the overview you're looking for. It says Mono 1.2 supports C# 2.0, but that the APIs are not on par with .NET 2.0 until Mono 2.0. edward.harvey.mono wrote From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu I don't know of documentation for this, but Mono 2.4 is old, and I wouldn't bother trying to support anything older. If we wish to develop distribute a server product using mono... It would be good to support rhel 5 6, as well as the various ubuntu LTS. Right now, ubuntu LTS all seem to have mono 2.10, which is good. But ... But centos 5 (epel5) has mono 1.2.4, and centos 6 (epel6) has mono 2.4.3. Maybe we'll just have to drop centos5 as a supported platform, but if you are a business distributing a product, telling your customers that you can only support the very latest OS, it makes it difficult for the customers to accept your product... Just ask any sysadmin who supports apple products. ;-) The day a new OS is released, the old OS is unsupported, so you as a company are forced to immediately drop what you're doing and test the new OS, as if the mac product release cycle is the only important thing in your life. ;-) Anyway... I know mono 1.2.4 is old. But what version of .Net is it compatible with? We may decide we're able to develop everything we need to develop, using that version... Or we may just drop support for centos5. I can't envision us saying we'll support ubuntu only and not redhat... Which means we're already limited to a maximum .Net 3.5. Thanks again... ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650765.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
Mono 2.4.x is compatible with .NET from 1.0 to 3.5. With Mono 2.8, the .NET 1.x profile was dropped, and the 4.0 one was added. edward.harvey.mono wrote I see on the compatibility page, that the current release is 2.10.8, and it is compatible with .Net 4.0. But what about older versions? The current mono distributed with amazon linux is 2.4.3.1-4... Is it also compatible with .Net 4.0? Or perhaps something older? I'm basically looking for the history of the Compatibility page. Thanks... ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650747.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .Net versions ... compatibility history
I don't know of documentation for this, but Mono 2.4 is old, and I wouldn't bother trying to support anything older. Besides, it'd be a pain to test compatibility with so many frameworks, many bugs got fixed since then, etc. Mono developers and users tend to use recent versions of the framework. Just ask your users to upgrade if necessary. Otherwise, your development costs will skyrocket, and your development team will be frustrated. :) Anyway, from what you're saying, it sounds like you'd like to go for either the 2.0 or 3.5 profile. edward.harvey.mono wrote From: mono-list-bounces@.ximian [mailto:mono-list- bounces@.ximian] On Behalf Of Stifu Mono 2.4.x is compatible with .NET from 1.0 to 3.5. With Mono 2.8, the .NET 1.x profile was dropped, and the 4.0 one was added. Thank you. But I expect we'll want to know which platforms our application will run on, and we'll want to be designing with these considerations in mind... Is this documented somewhere? What if I want to find this answer for ubuntu, or an older version of redhat, or fedora, etc...? I am guessing, somewhere in the source code, there's a readme that says compatible with .Net version ___ And I can certainly go fetch all the different versions of source code and create an index... But I'm guessing there's a summary already written somewhere, or an easier way to do it, right? Thanks again... ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Net-versions-compatibility-history-tp4650745p4650757.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] 6198, Opinion? (not a fix)
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] Newly broken WinForms unit tests
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 lt;stifu@gt; 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] Patches for mono-winforms
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] Patches for mono-winforms
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] Patches for mono-winforms
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] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Entity Framework goes to opensource
That's certainly what it sounds like. Gabriel Ibanez wrote Hi, Does it means that we can expect the entity framework working on mono sometime ? Cheers /Gabriel -Original Message- From: Alan lt;alan.mcgovern@gt; Date: Fri, 27 Jul 2012 18:15:22 To: lt;binhara@.comgt; Cc: lt;mono-list@.ximiangt; Subject: Re: [Mono-list] Entity Framework goes to opensource We have already cloned this into the Mono organisations github repository: http://github.com/mono/entityframework Alan On 27 July 2012 19:13, Alessandro Binhara lt;binhara@.comgt; wrote: http://entityframework.codeplex.com/ ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Entity-Framework-goes-to-opensource-tp4650600p4650617.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Patch for bug 6198/2263(Revision)
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
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 lt;stifu@gt; 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
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 lt;stifu@gt; 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
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 lt;stifu@gt; 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 lt;stifu@gt; 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
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 lt;ulatekh@gt; To: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt; 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 lt;ulatekh@gt; To: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt; 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 lt;monkey@gt; To: Steven Boswell II lt;ulatekh@gt; Cc: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt; 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] Mono and Microsoft open sourced Entity Framework
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 lt;monodanmorg@gt;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
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] 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. 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 lt;stifu@gt; 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
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-list] KeePass v2.19 portable crashes when unlocking database
Sounds like it's this bug: https://bugzilla.xamarin.com/show_bug.cgi?id=5796 knocte wrote On 05/07/12 16:35, iandunn wrote: I posted a message on the KeePass forums, and one of their developers looked at the stack trace and said that there wasn't any KeePass code involved, so he thought that the problem was with Mono. There have been some fixes in Mono WinForms recently. Try to run this with Mono 2.11.2 and if you still find the problem, file a bug in http://bugzilla.xamarin.com/ ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/KeePass-v2-19-portable-crashes-when-unlocking-database-tp4650311p4650316.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] Integration program failed while deployed on mono server
The correct way to fix this is not try to try and get the ole32.dll file to run on Linux. It'd be to replace this dependency with something managed (or if not possible, Linux-native). Start by checking which part of your code relies on this DLL (assuming it's indeed your code). kumaran wrote is there any way to use ole32.dll in linux. pls guide me to overcome the issue -- View this message in context: http://mono.1490590.n4.nabble.com/Integration-program-failed-while-deployed-on-mono-server-tp4650119p4650286.html Sent from the Mono - ASP.NET mailing list archive at Nabble.com. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-dev] Patches for mono-winforms
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 lt;stifu@gt;
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
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 lt;stifu@gt;
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
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
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
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] Patches for mono-winforms
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] Win Patches for Datagrid (first here) then idle
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
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
Re: [Mono-dev] Patches for mono-winforms
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 lt;stifu@gt; 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 lt;stifu@gt; 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] Win Patches for Datagrid (first here) then idle
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 lt;robwilkens@gt; To: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt;; Stifu lt;stifu@gt; 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] Win Patches for Datagrid (first here) then idle
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 lt;robwilkens@gt; To: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt;; Stifu lt;stifu@gt; 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
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://bugzilla.novell.com/show_bug.cgi?id=322563 What this accomplishes is that it hides the non browsable columns (columns that were not part of the original dataset, in the test case) from view in the DataGrid. Unfortunately, i can't see an obvious way to hide the'parent rows' display of those non browsable columns value. That is if You viewed a subtable off hidden field pb_Id=0 it would show that value (pb_Id=0) on the top of the datagrid where
Re: [Mono-dev] Win Patches for Datagrid (first here) then idle
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. 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://bugzilla.novell.com/show_bug.cgi?id=322563 What this accomplishes
Re: [Mono-dev] Win Patches for Datagrid (first here) then idle
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 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
Re: [Mono-dev] Win Patches for Datagrid (first here) then idle
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
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
Re: [Mono-dev] Win Patches for Datagrid (first here) then idle
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
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
Re: [Mono-dev] Win Patches for Datagrid (first here) then idle
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
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
Re: [Mono-dev] Win Patches for Datagrid (first here) then idle
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.. 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
Re: [Mono-dev] Win Patches for Datagrid (first here) then idle
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
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
Re: [Mono-dev] Patches for mono-winforms
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 lt;robwilkens@gt; 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 lt;stifu@gt; 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 lt;robwilkens@gt; 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
Re: [Mono-dev] Patches for mono-winforms
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 lt;robwilkens@gt; 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 lt;stifu@gt; 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 lt;robwilkens@gt; 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
Re: [Mono-dev] Patches for mono-winforms
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 file' 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 lt;robwilkens@gt; 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 lt;stifu@gt; 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 lt;robwilkens@gt; 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
Re: [Mono-dev] Patches for mono-winforms
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 file 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 file' 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 lt;robwilkens@gt; 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 lt;stifu@gt; 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
Re: [Mono-dev] Patches for mono-winforms
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 file 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 file' 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 lt;robwilkens@gt; 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
Re: [Mono-dev] Restart my fork?
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] Restart my fork?
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 commit just before first commit last commit 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?
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 commit just before first commit last commit 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?
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 commit just before first commit last commit
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
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. 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 lt;ulatekh@gt; To: mono-devel-list@.ximian lt;mono-devel-list@.ximiangt; 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 lt;robwilkens@gt; 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 lt;stifu@gt; 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
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 lt;stifu@gt; 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
