Belfry Images

Today I needed a graphing control, and with a bit of searching found ZedGraph. This has got to be the best open source .NET component I’ve ever used. All you need to do is reference the .DLL, drop a ZedGraph control onto your form or control, and add some code to load in a data range. It’s even easier to make a pie chart and the colours, gradients, etc., are all customisable. Out of the box the control automatically has zooming, scaling, printing and exporting features accessible to the user, and it looks nice and clean. There’s also a ZedGraphWeb control built in which is for use in ASP.NET apps (although I haven’t tried that out).

There are two concurrent versions for both .NET 1.1 and .NET 2 (which is very handy since I’m limited to .NET 1.1 at work). The only difference between the versions is apparently use of templates for collections.

There’s a CodeProject article that gives a pile of simple demo code, and the main site is a Wiki with what looks like plenty of documentation. The library is licensed under the LGPL license, which means that derivative works must be LGPLed, but as long as the library’s DLLs are dynamically linked they can be included in commercial software.

For reference the logical XOR operator in C# is the same as the bitwise XOR operator: ^. This always gets me because usually the logical boolean operators are like && and || versus the bitwise operators (& and |). I guess it’s the same thing anyway, just a bitwise XOR operation on two booleans. Fascinating.

I changed the name of a form class and added a new class at the top of the class file with the same name of the old form class, descending from the renamed class to avoid breaking old code. Then when I ran the app I got an exception saying that the form’s resources couldn’t be loaded. When I had a look at the resources file for the form (<project folder>\obj\Debug) a resources file was still being created for the old class name instead of the new one. Since this resources file is the one that gets linked into the DLL or exe, this meant that the new form class couldn’t find its resources. According to Microsoft KB318603 this is because other class definitions located before the form class definition will be picked up when naming the resources file. So if this happens, move the other class to after the form class (ie the MyForm.cs file should contain first the MyForm class then any other classes).

Of course the best thing would be to move the other classes into another file but that sounds like work

This doesn’t come up too often but can be useful. Sometimes, when using inheritance, it can be difficult to get the right implementation of a virtual method called. This is the kind of model I had today:

namespace InheritanceTest
{

	public class BaseClass
	{
		public BaseClass() {}

		public virtual void A(int count)
		{
			for (int i = 0; i < count; i++)
				B(string.Format("{0} Base Hello", i));	// This calls DerivedClass.B(string)
		}

		public virtual void B(string s)
		{
			Console.WriteLine("Base: "+s);
		}
	}

	public class DerivedClass : BaseClass
	{
		public DerivedClass() : base() {}

		public override void A(int count)
		{
			base.A(count);	// call BaseClass.A(int)
		}

		public override void B(string s)
		{
			Console.WriteLine("Derived: "+s);
		}
	}

	class MainClass
	{
		public static void Main(string[] args)
		{
			Console.WriteLine("Test begins:");

			DerivedClass obj = new DerivedClass();
			//obj.B(10);

			Console.WriteLine("Test ends.");
		}
	}
}

When this is compiled and run, the method called in BaseClass.A() is DerivedClass’s implementation of B(). The series of method calls will look like this:

1. DerivedClass.A()
2. BaseClass.A()
3. DerivedClass.B() ten times

So when BaseClass.A() makes the call to B(), the derived class’s B() method is found and executed, rather than BaseClass.B(). This is exactly how you would usually want the inheritance to work; the derived class has methods that override the base class, and the base class calls fall through to the child’s implementation of the virtual methods.

The problem with this is if you want to be able to use the base class’s implementation of B() in BaseClass.A()’s call to B(). BaseClass.B()’s implementation may contain code required in BaseClass, but DerivedClass.B()’s implementation is not appropriate for use in BaseClass. Basically you want the following series of method calls:

1. DerivedClass.A()
2. BaseClass.A()
3. BaseClass.B() ten times

We need to indicate to the compiler that, although DerivedClass.B() implements B(), it doesn’t necessarily override BaseClass’s implementation of B(). That is done by changing the override keyword in DerivedClass.B()’s declaration to new:

Change:
   public override void B(string s)
to:
   public new void B(string s)

The effect of this is that when B() is called in BaseClass, it will be BaseClass.B() that will be executed, because DerivedClass.B() is flagged as a new implementation of the B() method that does not override the existing one. The new DerivedClass.B() method is still visible in DerivedClass and beyond:

DerivedClass obj = new DerivedClass();
obj.B("Test");   // This will execute DerivedClass.B(), not BaseClass.B()

will execute DerivedClass.B().