What I hate about Silverlight

Don't get me wrong, I like silverlight. It is great. It is fast. It is different.
However some things really drive me crazy.
Silverlight 1.0 was just an advertising campaign. Its purpose was only to make developers anxious for the upcoming versions. I understand that.
I haven't used much of silverlight 1.1 but I know it was a huge leap forward.
Then came 2.0 that was announced as the first version that can be used to write sensible and powerful solutions.
Then came 3.0 which was expected to be also a major release.
I started to use silverlight just after version 2.0 was released. There were some things that were irritating me in 2.0. Those things still irritate me in 3.0. Actually I thing the difference between 2.0 and 3.0 is not so big that I expected.
I read somewhere that 3.0 introduces support for using the 3D power of your video card and also support of using the wheel of the mouse. Hello! Is this the most important.
But what really drove me crazy was that just a few months after releasing SL 3.0 Microsoft announced 4.0 beta. What to expect from this new version?! Maybe voice recognition, which will totally smash the Adobe rival.

So let me point some features I miss in Silverlight.

1) The designer. I miss a designer for silverlight in VS2008. How to create my GUI without designer. Hot to compute the margins? I heard that a powerful XAML designer will be available in VS2010. I'm waiting for it. As designer I use MS Expression Blend, which is very very good tool and even I can work with it. About Blend I will write a separate post.

2) Can reference only silverlight library projects. What about the whole bunch of code that you have. In my case we have some code dll-s that all the other projects use.I have some clues about this restrictions, but they are not worth sharing. However you can always link a file if you need. That btw, I mean the restriction of referencing dll-s != silverlight, has also a good side. Because it is vital to reference as less as possible dll-s. Because every single referenced assembly is then added to the package that every single user of you silverlight control downloads. Also I think there might be some performance penalty when having many assemblies, but I haven't tested that. Also I think here's the place to mention that you must be very careful with memory usage. Try not to hold references to huge collections and objects. Make sure you don't prevent the garbage collector to dispose them.

3) The most annoying one. The design time exceptions. You write some code, compile.Everything seems good. And then when you run it you get AG_E_UNKNOWN_ERROR or G_E_PARSER_BAD_PROPERTY_VALUE. Then you see some line and some position. It took me quite a time to start getting some hints on where the problem is. Was it so hard to make exceptions more detailed? Btw the majority of the exceptions I get are because I omit to implement a event handler in the .xaml.cs file. And I have declared it in the markup. This is a design time exception. Was it so hard to catch it design time? So to sum up I think Silverlight exceptions suck and Microsoft should do something about it instead of dealing with the mouse wheel.

4) Inheritance (of silverlight controls)- there is a workaround to do this. I admit that. But it is not as straightforward as it has to be. To inherit from other "form" you need to mark this in the codebehind file and also in the markup file. There are some other details that are however not relevant. Lets say, yes inheritance is possible. But, as "forms" are not meant to support inheritance there a lots of bugs in the whole thing. I needed all my forms to have some common behavior. For this I needed to handle 3 events. I wanted to hook for the events and write the handlers in the base form. And then all other forms to inherit from the base and to share the base behavior. But I failed. That was not supported. I got exceptions. And yes they were "AG_E_UNKNOWN_ERROR" like :). So I needed to hook in every single form and also needed event handlers for all the 3 events. In those handlers I called the three methods that I had written in the base class. What a mess. So to sum up: Microsoft guys, please do some work on inheritance.

5)And last. Some framework classes omit some of their methods. For example I will point the Enum.GetNames and the Color structure. And you can't use System.Drawing.Color, because System.Drawing is not a silverlight library.

Below is a workaround I use to get the names of all members of particular enum and also a method to get a color from its hex representation. To be honest the second one is not available in System.Drawing.Color too.

public static List GetEnumNames(Type enumType)
{
List enumMemberNamesFuckSilverlight = new List();
System.Reflection.FieldInfo[] fiArray = enumType.GetFields(
System.Reflection.BindingFlags.Public |
System.Reflection.BindingFlags.Static);
foreach (System.Reflection.FieldInfo fi in fiArray)
{
enumMemberNamesFuckSilverlight.Add(fi.Name);
}
return enumMemberNamesFuckSilverlight;
}

public static Color ConvertStringToColor(string source)
{
Color blackDefaultColor = Color.FromArgb(255, 0, 0, 0);

try
{
if (string.IsNullOrEmpty(source))
{
return blackDefaultColor;
}
else
{
source = source.Trim(new char[] { '#' });
if (source.Length != 8)
{
if (source.Length == 6)
{
//Correct color representation, omitting the alpha.
source = "FF" + source;
}
else
{
//Incorrect color...Sorry!
return blackDefaultColor;
}
}

byte a = (byte)Int32.Parse(source.Substring(0, 2), System.Globalization.NumberStyles.HexNumber);
byte r = (byte)Int32.Parse(source.Substring(2, 2), System.Globalization.NumberStyles.HexNumber);
byte g = (byte)Int32.Parse(source.Substring(4, 2), System.Globalization.NumberStyles.HexNumber);
byte b = (byte)Int32.Parse(source.Substring(6, 2), System.Globalization.NumberStyles.HexNumber);

return Color.FromArgb(a, r, g, b);
}
}
catch (Exception exc)
{
return blackDefaultColor;
}
}