Megatheriums for Breakfast

Well, last week I was back doing some Flash programming, creating an on-line game for one of our corporate clients.

I must say that Flash’s Action Script 3 is a much better way to do this kind of work than the old days of AS2 (yeah, I know that is a long while ago now, but I’m old and I’ve been working in Flash since Flash 4, so I still think of AS3 as new).

But I do find the problem with moving between all of these C-like languages is keeping them all straight in my head, they are all so similar these days. So similar that it’s really easy to forget the differences until you are brought up short by something going wrong. With luck, this will occur at compile time. If you’re not so lucky, it will happen at run time, in certain circumstances only.

The languages I’m thinking of are:

• C#
• Action Script 3
• Javascript
• PHP
• Objective C

I program in these languages pretty much all the time (though mostly in C#, and with Objective C very much the newcomer to my experience).

You could also add:

• Java
• …and probably several other languages

They all have essentially the same structures – a switch statement, a for statement or an if-then-else is pretty much identical in them all. It’s as though the whole world had converted to speaking English – but with various regional dialects. And you have to keep straight in your head which country you are in at the moment so you get the dialect right.

So changing from C# back to AS3 requires a fair bit of concentration.

Where they don’t compare, though, is in their respective IDEs (Integrated Development Environments). I should probably be using Flex, rather than Flash, and the Eclipse IDE, which isn’t bad, as the tools inside Flash itself are absolute rubbish. I actually find myself using Dreamweaver as a better AS3 code editor than what is available inside Flash CS3.

The Objective-C IDE on the Mac (XCode) is pretty good, in comparison, but still not a patch on Microsoft’s Visual Studio, in my humble opinion.

Microsoft do a lot of things very poorly, but developer tools they still do extremely well. If only they would stop fiddling with C# and not keep issuing new versions of it, each new version requiring a yet bigger .NET Framework to be downloaded by my end-users. I have to say that I’m yet to spend much coding time using the additional features in C# version 3, such as LINQ, let alone the new features which are planned for C# version 4, out real soon now. Most of the time I still target the .NET Framework 2, which is nice and small. Well, 20 MB is small by today’s standards.

What’s the best way to store and retrieve optional settings or preferences for users for your C# application? For simple stuff, there’s no easier way than creating settings in Visual Studio:

Note that you can use settings for both simple values like bool and string, and for more complex values like colors.

These settings get persisted in a file called [your program name].exe.config.

And you can refer to them in code like this:

    private void GetBackgroundColor()
   {
         this.BackColor = Properties.Settings.Default.BackgroundColor;
    }
 
    private void SetBackgroundColor(Color backcolor)
    {
          Properties.Settings.Default.BackgroundColor = backcolor;
          Properties.Settings.Default.Save();
    }

Well, that’s all very well, simple, and very useful. But it gets messy if you want to set up a lot of options and particularly if you need options using your own enums, in various categories or for different states or objects in your application – the Settings dialog is just a very simple, line by line set of options with no structure.

My own preference* is to create one or more Options classes, and to use the nifty Xml Serialization stuff which I talked about previously on this blog to load and save the class.

Here’s a considerably cut-down version of my Options class from my software Chapter Master:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

public class Options
{
	public enum ImageGrabOptions
	{
	    None,
	    CropFromTop,
	    CropFromLeft,
	    CropFromRight,
	    CropFromBottom,
	    CropFromCentre,
	    Pad
	}
 
	public enum SaveOptions
	{
	    None,
	    RenameOriginal,
	    PromptForNew
	}
 
	[System.Xml.Serialization.XmlElement()]
	public ImageGrabOptions ImageGrab = ImageGrabOptions.CropFromTop;
 
	[System.Xml.Serialization.XmlElement()]
	public SaveOptions SaveOption = SaveOptions.PromptForNew;
 
	[System.Xml.Serialization.XmlElement()]
	public int PadColorAsInt = Color.White.ToArgb();
 
	[System.Xml.Serialization.XmlIgnore]
	public Color PadColor
	{
	    get {
	        return Color.FromArgb(PadColorAsInt);
	        }
 
	    set {
	        PadColorAsInt = value.ToArgb();
	    }
	}
 
	public Options()
	{
	}
 
	public bool Save(string filename)
	{
	    return Seralize.ToXmlFile(filename, this);
	}
 
	public static Options Load(string filename)
	{
	    return opts = (Options) Seralize.FromXmlFile(filename, typeof(Options));
	}
}

Where Serialize is a class containing just the Xml serialization routines I wrote based on this Code Project article.

Note the way that the Color is serialized in lines 27-40, the same sort of workaround as is needed for TimeSpan values.

I like this approach because among other things, it allows different sets of preferences to saved and loaded as required.

Accessing these option values is very simple (this code is a fudge written just to demonstrate my general approach):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

private readonly string MySettingsFolder = 
      System.Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
      + @"\ProgramName";
 
private OptionClass MyOptions;
 
private void GetOptions()
{
     MyOptions = Options.Load(MySettingsFolder  + @"\Default Options.xml");
}
 
//....and thus code like:
 
picCover.BackColor = MyOptions.PadColor;
if (MyOptions.ImageGrab.CropFromBottom)
{
     //........
}
 
private bool SaveSpecialOptions()
{
    return MyOptions.Save(MySettingsFolder  + @"\Special Options.xml");
}

* I’m happy to have others tell me why there are better ways. As always, I certainly don’t claim to be any kind of expert. This is just the way I like to do it. If you think it’s dumb, tell me so.

I know that Jeff Atwood over at Coding Horror isn’t very fond of XML, but personally, I have grown to love it. Well, not XML as such, but the ease of serializing and de-serializing C# classes to XML and back provided by Visual Studio.

Jeff’s complaints seem to be all about the difficulty that humans (well, programmers, anyway) have in reading all those angle brackets. To me, this seems to be beside the point, since humans aren’t really supposed to be reading XML anyway – computers are. It’s just a nice side-benefit that we programmers can look at XML files with a text editor and generally get a pretty good sense of what is going on.

Anyway, what I love about serializing to XML is the way that in C# you can build up a very complex object, with nested lists of diverse objects and such, and yet just blatt it all out to a file, or send it by MSMQ, and just magically read it back and have that fully complex object back again, without any need to spend time coding to parse it all in or out.

For example, in one of the applications I built for Kaleidio, we are simulating electronic transactions between companies. So I have a class called ‘Company’, name, address, etc, as you would expect it; but among other complexities, the company class also includes an array of storage locations. Each storage location has a list of products being stored, each with its own information about price, unit size, bar-code, etc. Obviously, these are ‘toy’ companies with far less complexity than the real thing; but nevertheless, they are complex objects.

With serialization, I can just set up and save an entire company object to disk, or pick it up and despatch it to another computer via MSMQ (or SOAP, or whatever).

There’s a great article with some really good utility routines for reading and writing serialized XML here at Code Project. If you base your code on these routines, you can write code like this:

	var myCompany = new Company();
 
	//fill in company details, add storage locations, 
	//fill locations with products, etc.
 
	ToXMLfile(@"C:\temp\company.xml", myCompany);
 
	//then, later:
 
	var loadedCompany = (Company)FromXMLfile(@"C:\temp\company.xml", 
						typeof(Company);
 
	//now work with the company again.

To make this all work well you generally have to assign attributes to members of your classes to give the serializer hints as to how you want the XML to work.

	public class Company
	{
		[System.Xml.Serialization.XmlAttribute()]
		public string Name = "MyBusiness";
 
		[System.Xml.Serialization.XmlElement()]
		public string Address= "41 Smith Street, Collingwood, Vic 3066";
	//....

This creates XML like:

	<Company Name="MyBusiness">
	<Address>41 Smith Street, Collingwood, Vic 3066</Address>
		....
	</Company>

 
I have used this a lot in the last 6 or 7 years, but I have to admit that it’s a feature of Visual Studio that I have basically taken for granted, and only rarely had to worry about the implementation. In other words, I haven’t really researched it and thought about it in any detail, just used it at a basic level. I’m guessing that most practicing programmers use many such language features in the same way.

But it’s when what you have taken for granted suddenly causes you grief that you have to start hitting the F1 key (or, more usefully, googling) to get some answers.

For example, there are some kinds of data type which you can’t serialize directly, such as TimeSpan. So you have to use a workaround like this:

        [System.Xml.Serialization.XmlElement]
        public long DurationTicks;
 
        [System.Xml.Serialization.XmlIgnore]
        public TimeSpan Duration
        {
            get { return new TimeSpan(DurationTicks); }
            set
            {
                DurationTicks = value.Ticks;
            }
        }

Note that one of the disadvantages of serialization is that any value to be serialized must be marked as public, so DurationTicks above is visible as a member of the class to which it belongs, even though you don’t really want it messed with directly.

Where I have gotten myself into difficulties in the past is where you want a class to be able to have a member which may be of various different kinds of object. They are different, but they do all inherit from a base class.

You can use a construct like this, which uses an additional class member to indicate to the serializer the type of object being included:

        [System.Xml.Serialization.XmlChoiceIdentifier("ControlType")]
        [System.Xml.Serialization.XmlElement(Type = typeof(VideoControl))]
        [System.Xml.Serialization.XmlElement(Type = typeof(ImageControl))]
        [System.Xml.Serialization.XmlElement(Type = typeof(FlashControl))]
 
        public Control ControlObj = null;
 
        /// <summary>
        /// Identifies the type of control being sent.
        /// </summary>
        [System.Xml.Serialization.XmlIgnore]
        public ControlTypes ControlType = ControlTypes.None;

Note the XmlIgnore tag, which tells the serializer not to explictly include this property in the XML.

But I struggled for a while to figure out what to do when the class I was trying to serialize had a member which was a list of such variable objects.

For example in one of my shareware projects, I have an object which includes such a list (a List<FileRecord>, to be specific). Mostly this list contains plain FileRecord objects, but I also have a class called CDTrackRecord which inherits from FileRecord. For quite a while I couldn’t figure out how to correctly serialize a class with a list which included one or more such inherited objects.

I’m still not sure if this is the best solution, but I discovered that you can use an XmlInclude attribute on the base class of list members, like this, to show it also includes the possibility of the inherited object:

        [System.Xml.Serialization.XmlInclude(typeof(CDTrackRecord))]
        public class FileRecord
        {
                //class members
        }

The class including a List<FileRecord> now serializes nicely.

Disclaimer: I don’t claim to be any kind of programming expert, just a dumb old programmer with a passion for coding. Bear this in mind if you comment!