We need WinForms bugfixes

Lately I was mostly spending my time on bugfixing core libraries such as corlib and System.dll. Yesterday I got to know that we need a lot of bugfixes in our MWF (managed win forms).

So I have started to look around existing bug list and work on it. At first I thought that it is highly difficult task: to extract simple reproducible code from problematic sources, and of course, to fix bugs. Turned out that it is not that difficult.

Actually, it is very easy to find MWF bugs. If you run your MWF program, it will immediately show you some problems. What I don't want you to do at this stage is just to report it as is. We kinda know that your code does not work on Mono. It's almost not a bug report. Please try to create good bug report. Here I want to share my ideas on how you can try creating good MWF bug reports and bugfixes.

(Dis)claimer: I'm far from Windows.Forms fanboy. Don't hit me.

the background

Mono's Windows Forms implementation is WndProc based, which is implemented on top of XplatUI framework. For drawing we have Theme engine which is implemented on top of System.Drawing which uses libgdiplus on non-Windows and simply GDI+ on Windows.

Thanks to this architecture, if you have both Windows and Linux (and OSX) boxes, you can try them and see if all of them fail or not. In general we have XplatUI implementation and Theme implementation for each environment (XplatUIWin32, XplatUIX11, XplatUIOSX and ThemeClearLooks, ThemeGtk, ThemeNice, ThemeWin32Classic), so the bug you are tring to dig might be bugs in there (well, also note that if you have wrong code such as Windows-path dependent code, it won't work. Here I continue winforms-related topic). To find out the culprit layer:

• If only non-Windows box fail, then it might be bugs in libgdiplus or Cairo as its background. If Only OSX fail, then it is likely to be some architecture (big endian etc.) related bug.
• Otherwise it is likely to be misimplementation of our class libraries including MWF controls. System.ComponentModel and System.*Design classes are also likely to be culprit.

See our WinForms page for more backgrounds.

find the culprit

The first stage is to find out the problematic component.

• We fix several bugs everyday. So always try the latest mono, mcs and libgdiplus from svn. Trying MWF on stable releases (1.1.13.x) is almost helpless. The code is rapidly improved by the MWF team.
• Compile your code with -debug option. It will result in more informative stack trace (file and line).
• Check existing bugs. When you hit a problem, there would be the same or similar problem.
• Reproducible bugs are much better than non-reproducible bugs. Try to find a consistent way to reproduce the bug. On bug report, having the procedure is much more helpful. It is also nice if you can provide reproducible steps for existing bug reports that do not have repro steps.
• Try simpler controls for whatever you found bugs as well. For example, if ComboBox focus does not work, there is likely another bug on focus handling.
• sometimes trying indifferent controls also helps. It might not be a bug in the exact control you are touching, but might be a bug in the container, MDI, Form or drawing in general.

create a simple repro code

Once you think you found the culprit control, try to create a simpler reproducible code. It does not only help debugging (those bugs without "readable" code are not likely be fixed soon), but also avoids your mistaken assumption on bugs.

When you try to create simple repro code, you can reuse existing simple code collection.

If you are not accustomed to non-VS.NET coding, Here is my example code:

using System;
using System.Windows.Forms;

public class Test : Form
{
	public static void Main ()
	{
		Application.Run (new Test ());
	}

	public Test ()
	{
		#region You can just replace here.

		ComboBox cb = new ComboBox ();
		cb.DropDownStyle = ComboBoxStyle.DropDownList;
		cb.DataSource = new string [] {"A", "B1", "B2",
			"C", "D", "D", "Z", "T1", "B3", "\u3042\u3044"};
		Controls.Add (cb);

		#region
	}
}

Compile it with mcs -pkg:dotnet blah.cs.

bugfixing

After you create good bug reports (also note that we have a general explanation on it), it wouldn't be that difficult to even fix the bug :-) Actually we receive a lot of bug reports, while we have relatively few bugfixors.

As Ximian used to be GNOME company, external skilled Windows developers would know much better on how to implement MWF controls and fix bugs. In my case I even had to start bugfixing from learning what kind of WindowStyles there are (WS_POPUP etc. that we define in XplatUIStructs.cs).

My way of debugging won't be informative... Anyways. When I try to fix those MWF bugs, I just use a text editor and mono --trace. My frequently used option is --trace=T:System.Windows.Forms.blahControl. I mostly spend time on understanding the component I'm touching.

When you created a patch (hooray!), adding [PATCH] prefix on the bug summary would be nicer so that we can find possible fixes sooner.

|