I sat down to write a new Windows Forms application in .NET 1.1 the other day, but the Visual Studio 2005 beta 1 called to me with its “menu strips” and its “user settings” and most especially its “generics,” and I just couldn’t resist.
To start with, it was such a pleasure to add a menu strip, add in the standard menu items (including graphics), then just strip it down to just the menu items I wanted. Then, as I added new menu items, the menu item object names were set for me based on the menu item text, e.g. startRetrievalToolStripMenuItem instead of menuItem1, which was fabulous. Not everything was wonderful, e.g. I couldn’t drag and drop menu items or use Alt+arrows to rearrange them , but overall the new menu control was a pleasant experience.
Even more pleasant was the app/user settings model. To add a setting to my application, all I had to do was bring up the properties of my project, add a named setting of whatever type I wanted (more on this later) and choose whether it should be an Application setting or a User setting. Both kinds of settings are loaded automatically when the app starts and all I had to do to save them was call Properties.Settings.Value.Save() when my main form shut down. Then, with the settings in place, e.g. MyUserSetting, I could get to it after the app started from anyone in my app with a type-safe access, e.g. Properties.Settings.Value.MyUserSetting.
And this didn’t just work for built-in simple strings and ints and such like. Oh, no. I was allowed to add custom and collection types like System.Collections.Generic.List<MyNamespace.MyType> as well. Plus, using generics, the underlying XML serialization mechanism worked great, because all of the types are known at compile-time (settings are stored in standard XML .config files @ c:\documents and settings\<user name>\Local Settings\Application Data\<company name>\<product name_hash>\<product version>\user.config). Being able to declaratively set app and user settings of any type and then just use them in a type-safe manner, saving them with one line of code, loading them with zero lines of code and not having to flatten my collections into comma-separated lists made things so pleasant until I hit the ugly realities of beta software, especially as new features interact with existing features and each other.
For example, because the default AssemblyVersion attribute is set to “1.0.*” in AssemblyInfo.cs (which has moved to below the Properties folder of your VS05 project), every time I compiled, all of my settings were lost. That seems very counterintuitive to me. Why should a user lose all of their settings with the new version of the application? To work around this, I changed my AssemblyVersion attribute to a hard-coded string that I now have to remember to change manually, blowing the benefit of having a version number that changes automatically with each build.
As another example, like C++ “const” of old, generics infect your code; use them in one place and you find yourself using them all over. That was fine with me (the generic Predicate<T> for finding things in a List<T> was so handy!) except that as of b1, the Windows Forms Designer gets all unhappy when you use generics. I have every hope that this will be fixed by b2, but as of right now, if I wanted to use the Designer (and it’s so sweet, how could I not want to use it?!?), I had to strip out any methods or properties in my visual code that exposed generics (although method and property implementations with generics works just fine).
Stripping out List<T> brought me to the use of ArrayList instead. That worked just fine (System.Collections.ArrayList is even available via the Browse button when setting up app/user settings) until the XML serializer couldn’t serialize instances of the custom type that I was using to populate my ArrayList. The error looked like this:
Could not use Xml serialization for setting: SelectedExchanges. --->
System.InvalidOperationException: There was an error generating the XML document. --->
System.InvalidOperationException: The type MyNamespace.MyType was not expected.
Use the XmlInclude or SoapInclude attribute to specify types that are not known statically.
When I start up the debugger to see the line of code where the error is happening, I ended up in Main because the code is part of the Application start-up for which there is no source code, making this even more difficult to debug. The problem was that the underlying serialization engine didn’t know what to do with this custom type. The clue was the mention of the XmlInclude attribute, which you can use to tell the serializer what types may be in the ArrayList, but you have to have somewhere to hang the attributes. In this case, that lead to a custom ArrayList type for the express purpose of informing the serializer (making me really miss the use of generics, where all of the types were specified at compile-type for me automatically):
[System.Xml.Serialization.XmlInclude(typeof(MyNamespace.MyType))]
public class MyList : System.Collections.ArrayList {
public override object Clone() {
MyList newList = new MyList();
newList.AddRange(this);
return newList;
}
}Notice also the Clone method. I added this later because the base ArrayList Clone method creates an instance of ArrayList, not my custom MyList type. Of course, since this was all run-time type errors, I couldn’t let the compiler tell me about these problems; I had to run my app and find them. Very frustrating, especially when generics makes these problems all go away.
Still, I’m very much enjoying the new productivity features in VS05 and Windows Forms 2.0 and when they work better together, I’ll be even more happy.
