Default behaviour/WMP control

When I was an MVP, one of the first things I did was ask the C# team for default values on variables, like C++ has, and VB.NET has. They would get tied in knots over how complex it would be. We are finally getting this feature. In the meantime, if I had a method and I wanted to extend it, I'd do something like this:

old method :

bool DoSomething(string name, int age)

new methods:

bool DoSomething(string name, int age, bool doSomethingExtra)
{
...
}


bool DoSomething(string name, int age)
{
return DoSomething(name, age, false);
}

In other words, you need to keep your default behaviour for existing clients of the code, and then allow changes of the code for any client who wants to use the new functionality. In any situation, if you want to extend something that exists, you need to make sure you don't break it for people already using it, right ?

Our WPF application uses the Windows Media Player control, I've already explained why in the past. We just wrapped up our installer for our new version and shipped it. Shortly after release, we started to get reports from people that the player in our app was showing the WMP controls. It turns out the person who wrote that code, never added code to set the uiMode. I have searched and can't find any way to set the default value for that, but I have had it happen on one machine, further confirming that a windows update has changed windows media player so that if you don't set a uiMode, the default is no longer none. This is major for us because it also means the control catches right clicks, which we use when we put the control in full screen mode.

On top of that, a video which plays fine on all of my test machines, some of which are completely virgin, is reporting that 'Windows Media Player cannot open files of type wmv'. Now, all our videos are WMVs, but either way, WMP can't play WMVs ? Again, it's clear by the fact this is happening on computers where before everything was fine, that a windows update has basically changed how the windows media player control behaves, and broken our app. I am shipping an update that sets the uiMode, and we should have done that in the first place, but either way, if you do an update, you should make sure you're not going to break existing clients. That's just common sense.

Update: I installed IE8 ( I actually asked it to install 5 times, it would not install until I selected to participate in the customer experience improvement program ), and now I can reproduce the UI issue. The video in question still plays fine, but it looks to me like IE8 is the cause of the other issue. I need still to install XP SP3, I've avoided that since it completely trashed one of my AMD based machines, I'll install that next ( my Mac is Intel based ), and see if that creates the issue with the file not playing.

(update) I have updated my Vista machine to the hilt ( 100+ updates, took an evening and a morning to do ), and I can't repro the issue with the file not playing, so I assume that was actually an issue with a single install, and not a Microsoft issue at all. As I updated my Vista machine, I once again saw our UI change from no UI over WMP to the full UI, as reported above. I am just rolling out the patch now to fix this issue for our users.

Breaking Visual Studio is too easy

My first real WPF app started out fine, but over time, I found that I could build it perhaps once, then I'd get an out of memory exception and have to restart the IDE, or sometimes even reboot. You can imagine what a pain this was. I did some research and found that this is quite a common issue for a lot of people. There are other issues, for example, someone I know tells me that for him the linker crashes with an internal error inside the "IncrBuildImage" function, every second build. He's building native code. I don't know the answer to his issue, but I know how I solved mine.

The issue is that the compiler often can't deal with a WPF app that has a lot of resources in it ( my exe was 32 MB which included a lot of UI elements as PNGs ). There's two solutions here:

1 - make your UI elements XAML. This just makes sense, they take up less space, and scale to any size. Expression Design is actually awesome at taking Adobe Illustrator and other formats and turning them in to XAML. This is the approach I am taking going forward

2 - put all your resources in a dll. If you're showing big images, as I invariably am given the apps I write, then you may not want or be able to convert them to XAML. So, put them in a dll, which you never change, and therefore do not have to build more than once.

I would prefer not to have my images in a resource dll, but it's made me a lot more productive. If they fix this bug in VS2010, I may go back to how it was, but certainly this works, and it is an effective workaround for yet another Visual Studio bug.

I am actually travelling to the US for a couple of weeks starting tomorrow, so my post frequency may slow down, although I do have at least 10 other .NET issues bookmarked to write about, so with some luck I may manage to keep up my current post frequency of a couple every now and then. Doesn't sound too challenging, but if this post is two weeks old and it's on top, that's my excuse, and I'll be posting again for sure when I get back.