WPF

Bug fix: WPF4 project template for #MVVMLight V3

Laurent Bugnion — Tue, 24 Jan 2012 23:40:09 GMT

Ironically, my last release of MVVM Light V3 was about fixing bugs in templates and making them better. In the process however, seems that I introduced a regression bug in the WPF4 project templates. Yep shit happens.

How do I know if I have the bug?

Check the Programs and Features control panel, and look for MVVM Light. If the “Version” column shows 3.0.2.19, you have the bug. If it shows anything higher, you don’t. For instance, the new version with the bug correction is 3.0.3.19. Also, any version 4.*.*.* does not have this bug.

Alternatively, simply try to create a new WPF4 MVVM Light application in Studio. If you see the following warning, you have the bug.

Upgrading

To fix the bug, simply download V3.0.3.19 from Codeplex and install. You don’t need to uninstall the previous version.

What’s next?

I am working hard on V4 and have some nice improvements coming up. Many people have asked me when the “beta” will come out of MVVM Light, and the answer is “soon”. In the coming few days, I will publish a temporary release that corrects a few memory leaks, notably in the Messenger and in the RelayCommand. This will give expert users time to test and report issues. Then I still have a couple of fixes and I will release a release candidate. I won’t add any new feature after the RC, but will merely fix bugs if people find some. Once the RC is deemed stable, I will release V4 and take a deep breath!

And yes, there will be a V5

Happy coding,
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

New MVVM Light templates with bug fixes

Laurent Bugnion — Mon, 02 Jan 2012 20:13:28 GMT

The current version of MVVM Light had a couple of issues in the project templates. The most annoying one was causing a problem when creating new projects: The GUIDs used to uniquely identify the project were in fact not re-generated properly every time, and we ended up with the same GUID in every new project. The symptoms are the following: If you side-load an MVVM Light application, and then side-load another one, you will see that the first one is overwritten. Note however that this is only an issue when side-loading applications: The GUIDs are properly re-generated and overwritten by Microsoft during the app approval process.

This was not really an issue with WPF and Silverlight applications (which is why the bug was never found until now), however the Windows Phone uses these GUIDs to check if the application is already installed on the Windows Phone device or not.

I also took this occasion to update the templates with some information in the AssemblyInfo.cs, so that should make it even easier to fill the assembly information.

I just published a new MSI that corrects the issue. You can install the new MSI on top of the existing one. As usual, there is an MSI for MVVM Light V3 and one for MVVM Light V4 beta.

Fixing the issue in existing applications

If you encounter this issue in existing application, you can use the following steps to correct it. Note that I recommend you to follow these steps for every MVVM Light application.

Start the GUID generator installed with Visual Studio (open the Start menu and type GUID to find it).
In the GUID generator, select the Registry Format.
Press the New GUID button and then the Copy button.

Open the CSPROJ file in Notepad (or any text editor).
Locate the <ProjectGuid> attribute.
Select its content and paste the GUID you previously copied.

For Windows Phone projects only, in addition:

In the GUID generator, press the New GUID button and then the Copy button.
Open the file WMAppManifest.xml (in the Properties folder).
Find the ProductID attribute and replace its content with the GUID you previously copied.

Projects exposed to COM

Some project also have a GUID in the AssemblyInfo.cs. Open this file in Visual Studio or in Notepad and check if you can see a GUID there. If there is one, copy a new GUID from the GUID generator and replace the old one with the one you just copied. Be careful to remove the opening ‘{‘ and closing ‘}’.

That’s it

Apologies for this bug, and thanks to everyone who reported it and helped make MVVM Light better.

Cheers,
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

MVVM Light installers and Nuget (including Silverlight 5) #mvvmlight

Laurent Bugnion — Sun, 18 Dec 2011 21:10:12 GMT

I just pushed two big updates to MVVM Light setup components.

MSI installers with Silverlight 5 support

The MSI installers are available on Codeplex. The current version supports Silverlight 3, Silverlight 4, Silverlight 5 (new), WPF 3.5 SP1, WPF 4, Windows Phone 7.0 and Windows Phone 7.1. The installer for V3 is available, as well as the one for V4 beta.

NuGet support including Silverlight 5

I also pushed a new version of the NuGet packages which includes Silverlight 5. To install MVVM Light into an existing application with the help of the NuGet package manager in Visual Studio, check the instructions.

If you look for “mvvmlight” on NuGet, you will find four packages:

MVVM Light: The whole package, libraries + ViewModelLocator + MainViewModel. Installing this also modifies App.xaml to install the ViewModelLocator. This package is for V3 of MVVM Light!
MVVM Light libraries only: Installs only the DLLs and references them. This package is for V3 of MVVM Light!
MVVM Light [Preview]: This is the whole package too, but for V4 beta.
MVVM Light libraries only [Preview]: Just the DLLs, for V4 beta.

Update on V4’s availability

One of the most annoying issues in V3 is a memory leak that can appear in the Messenger component in certain circumstances. I will post details in due time, but there is indeed a risk that an instance is not garbage collected if it is registered with the Messenger with a non-static method, and if the developer omits to unregister the instance before deleting it.

Because of the promise of a “weak” registration, I really want to solve this issue. Currently, I am able to completely solve it in WPF, and to solve it in most cases in Silverlight (including Windows Phone). There is still one special case in Silverlight where a memory leak may remain, and I am currently working on handling this. I am not sure that there is a solution for this last scenario, but there are other alternatives that it is not a blocking issue anymore.

Once this fix is fully tested, I still have a few things I would like to add in V4. However I am also aware that we have been in beta (and alpha) for quite some time already, and it is very possible that I procrastinate some of these features into V5.

Happy coding!
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Quick tip: Select the correct INotifyPropertyChanged in Windows 8 / WinRT

Laurent Bugnion — Sun, 25 Sep 2011 20:47:24 GMT

Microsoft loves MVVM and INotifyPropertyChanged so much that they included this very useful interface twice in the new WinRT framework. Unfortunately, only one of these is working correctly (and the other one is likely a bug, remnant from the past )

When implementing INotifyPropertyChanged, make sure that you select the correct one! The one you want to use is into Windows.UI.Xaml.Data. The old one, the one you DON’T WANT is into System.ComponentModel (the same namespace it was in WPF and Silverlight). If you select the wrong one, the Bindings will not be updated and the UI will remain dead as a dead fish.

I mentioned before that Microsoft took the “once in a lifetime” opportunity (well, 5-10 years is a lifetime in the world of computers) to clean up and rearrange classes within the framework. This is one of the signs right here. As for the System.ComponentModel.INotifyPropertyChanged, I guess it will be removed in a later release of the WinRT framework.

Update: Indeed I was just told by the excellent and always vigilant Tim Heuer that this bug has already been fixed. I guess we will see the fix in the next release to developers of Windows 8.

Cheers,

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

My thoughts about Build, Windows 8, WinRT, XAML and Silverlight

Laurent Bugnion — Sat, 17 Sep 2011 19:32:12 GMT

Last week, Microsoft held their long awaited Build Windows (or simply "Build") conference in Anaheim CA. About 5000 people packed the convention center to discover the latest version of the Windows operation system: Windows 8.

This is a very major iteration (much more than the Windows Vista –> Windows 7 transition) (and also, it is an early preview so it is quite unfinished ;) As such, we will definitely need a bit more time to play with it before we can express a truly informed opinion. Of course that didn't stop tech journalists and dumbasses all over the world to (again) express complex thoughts such as "Microsoft is abandoning Flash/Silverlight in Windows 8" or to ride again the "Silverlight is dead" roller coaster.

Side note: Did I just call you a dumbass? Well if you are on this blog, reading, the answer is most probably NO. I want to be very clear: This comment was not targeted at Scott Barnes either (though, why would he think it was? mmm food for thoughts there) ;) The dumbasses are the haters, the people who keep taking any occasion to spread FUD because they do not know it, understand it, or simply because it has the name Microsoft on it. So no, I did not call YOU a dumbass. Apologies for not making that super clear from the start. After all, you read my blog, that makes you my best friend (or something ;)

Of course, as usual (it is starting to get annoying, right?), these opinions are far from the truth and attempt to put a negative spin on everything Microsoft does. I won't even speculate why that is, but based on track records, it is safe to say that this kind of prediction is not very accurate or rational (remember when we were told that we would not be able to use anything else than HTML to build Windows 8 apps? Yeah those were the days ;)

So what is the reality now? Here is what we know:

(disclaimer: this is based on what I understand after many discussions with experts. However, I am not a Windows 8 expert, I just played with it for 5 days now. If anything here is incorrect, it is my own fault and not the experts')

Desktop vs Metro style

Windows 8 has two modes, one named "Desktop" and one named "Metro style". These names are temporary and may very well change before release. The "Metro style" applications are also referred to as "immersive apps".
Silverlight and WPF will continue to run as is on Windows 8 in Desktop mode. You can think of the Desktop mode as Windows 7++, an improved version especially optimized for touch operation. Honestly using the Desktop mode with the fingers is an amazing pleasure now, while it was a pain in Windows 7.
All applications (as far as I tested) that run in Windows 7 also run on Windows 8 Desktop mode. I installed Silverlight and Flash already on mine, OneNote, Live Writer, Live Messenger, Skype and more. No issues at all so far (apart from an occasional instability because "it's an early preview" (TM)).
Metro style applications (aka "immersive apps") are a new class of apps altogether. They are in fact much more similar to a Windows Phone 7 app than to a classic Windows application. They are optimized for Touch and can also be actuated with keyboard and mouse, though the experience is better with the fingers.
Metro style apps are sandboxed for security. Again, this is very similar to the Windows Phone 7 model.
Metro style apps can be developed with 3 possible stacks: XAML/C++, XAML/C# or HTML/CSS/JavaScript. They rely on a set of API named "WinRT" which is exposed in a very consistent manner for the three stacks.

This last point is important. It means that there is no reason to choose one or the other stack based on WinRT features that you want to address. Because of the chosen architecture, the features will automatically be available to the three stacks. In some cases however, some features will be hidden on purpose from one stack or the other, because they might simply not make sense.

The Windows 8 programming model: The blue side is largely unchanged (.NET 4.5, Silverlight 5, Win 32) and everything runs as usual. The green side is new (see the next section).

Programming stacks for WinRT

Amongst the three stacks, there will be some differences due to the languages. For instance, JavaScript and C# don't address asynchronous programming in a similar manner (by the way Windows 8 is sporting C# 5, so you have the great "await" and "async" keywords that are making asynchronous programming much more similar to synchronous coding). Similarly, JavaScript is more dynamic than C#, but C# is easier to code and to debug, etc.
All three stacks talk to unmanaged code (the WinRT libraries). For C++, this is a direct unmanaged call. For C# and JavaScript, there is a thin managed layer to "map" the calls into WinRT. However, the managed layer is much thinner than before. It is simply because most of the previous .NET libraries are now WinRT libraries, and these are unmanaged.
For the C# developer however, you will not notice that the WInRT are unmanaged (except in some rare occasions) because the API is managed.
This means that the performance gain in C++ is not going to be as significant as versus "classic .NET". There will be however a small performance gain in using XAML/C++.

Portability of Metro style apps

HTML/CSS/JavaScript applications coded for WinRT are not cross platform. They are something new. They use WinRT specific APIs, both in HTML/CSS (for instance the new Grid layout, which is not supported by other browsers at this time), or of course any calls against the WinRT APIs. This is NOT web programming. This is a standalone Windows 8 app that happens to be coded in a programming language that can also be used on the web. Two very different beasts, though of course knowledge and skills can be leveraged.
XAML/C# apps are not Silverlight or WPF. They are something new. They use WinRT specific APIs (sounds familiar?). Mostly, these APIs were already available in Silverlight, however there was a rather large "spring cleaning" operation, and a lot of APIs were moved in different namespaces, and sometimes renamed. A good example of this is the System.Threading.Dispatcher class which is now a Windows.UI.Core.CoreDispatcher. The original dispatcher's CheckAccess() method is now a property named HasThreadAccess.

In both these points, notice how similar the experience is for the developer: Much is familiar, some things are new (most significantly new/renamed APIs), skills are portable but there is a learning curve.

How to choose?

In Jason Zander's (and others') own words, to choose the stack of choice to create a new Metro style app, you should consider the skills you have. If you are a web programmer with a solid experience in JavaScript, it's obvious that you want to leverage your knowledge of the language. You will have a learning curve though, to learn the new proprietary APIs. If on the other hand you are a Silverlight/WPF developer, or even a .NET developer with no prior XAML experience, it will be easier and more faster for you to climb on the C#/XAML stack. Finally, if you are a C++ enthusiast, the C++/XAML stack is for you. And if like me you love to learn new things, then you can try one or both of the other stacks to build new apps.

Because of the Win8 architecture, any new feature added to WinRT will (almost) automatically be available to all three programming stacks (in fact it requires a little bit of work to decide what should be exposed or not, because some APIs just don't make sense with a given programming language, but in regards to the investment needed to implement the feature, this is not significant.

What about existing applications?

It means that your (our) investments in any technology you were using until now are safe for a number of years. You had a Silverlight application, or are currently working on one? You should continue. WPF? Same thing. Not only these frameworks are fully supported and extended (Silverlight 5 release candidate was announced a few days before Build started), but they also work as is, without any changes on Windows 8.

And C#?

I had the immense privilege to be invited to a side session with Anders Heljsberg, the father of C#. It was a great session, and you can feel Anders' happiness and enthusiasm. WinRT currently supports C#5, including all the new features such as the async and await keywords, and more. When asked if he was thinking of a version 6, Anders laughed and told us that he had a history of being quite stable at his job (13 years at Borland, 10+ years at Microsoft) and that he was foreseeing C# 6, 7, 8. C# is actively developed, and Anders is an accessible architect, who will listen to requests for new features. Changing a language is obviously not a fast process (nor should it be!) but his team is working on exciting stuff, and we are his customers!

Thoughts about porting applications from Silverlight/WPF to WinRT

This one is a tough one, mostly because I did not have time to experiment enough. If you have an existing application implemented in Silverlight or WPF, and you want to make it a WinRT application, how should you proceed, and is that easy?

Based on what I saw and what others reported, it is not a trivial process, even if in most cases the major work is to find out what was renamed and what was moved (see the “spring cleaning” mention above). If you want/have to do that work, I would consider the following:

Why do you want to do this? Do you really want to make your existing application (which by the way runs perfectly fine on the Windows 8 Desktop) a WinRT app? Who are you trying to touch. Shouldn’t you rather be developing a new app, something like a companion to the existing application?
If you answer “yes” to the “do you really want to” question, then I really hope that you followed best practices and layered and componentized your application carefully (I also hope you wrote unit tests, because you’re going to need those to verify that the ported code runs fine).
Porting the code will take some effort. Do not underestimate the effort. I tend to believe that Microsoft was (purposely?) over-optimistic in telling us that this is an easy process. At least now that the documentation is in a very early stage, looking for the renamed objects is a tedious process.
By the way, I started porting MVVM Light to WinRT and I hope that (if my compulsion to blog about Windows 8 lets me) I might have something to share soon.

Tip: I was told (and didn’t test yet) that ILDASM can decompile the WinRT assemblies and let you peek for your objects/methods/properties. This is because even though the WinRT framework is unmanaged, a thin layer of meta data is built in to allow managed code access. Pretty clever (and handy) if you ask me. I (again) didn’t try but I suspect that dotPeek and other similar tools may work too. Let me know in the comments if you try it!

Wrapping up

There are a few not-very-well organized thoughts on Windows 8, WinRT, XAML and more, put together after 5 days of immersion and tons of discussions with Microsoft employees as well as third party experts. I hope you'll forgive me if it sounds a bit chaotic, it is simply that a new framework of that amplitude will need a few weeks (months?) to be fully assimilated and digested. I hope that this helps painting a clearer picture however.

If there is one thing only you should take from this post, it is the following: Don't panic. Yes we will have some work to fully climb on this new exciting platform. But much MUCH of what we know is going to apply almost 1:1 to the new stack. Also, Microsoft is really investing in user experience, Blend, XAML, C# and all that. If there is only one session of Build that you must see, it is Jensen Harris fantastic Big Picture session about the Windows 8 UX.

I for one am pretty excited about Windows 8 and WinRT. First it confirms what I have been thinking since I started playing with the Avalon bits: XAML is a great way to build a wonderful user experience, Blend is central to that experience and C# is awesome. I am also excited to see new ways to develop applications for WinRT, because diversity is good. The Samsung slate is an awesome device, and there was a great sense of excitement in Anaheim this week. Of course I am known for being an optimistic, but I don’t think it’s just me feeling that excitement. Windows 8 is going to be pretty awesome.

Credit for “Don’t panic” button: http://www.flickr.com/photos/brighton/2153602543/s

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

MVVM Light V4 beta1

Laurent Bugnion — Mon, 12 Sep 2011 16:00:20 GMT

This morning, I published MVVM Light V4 beta1 in the form of an MSI. The installation instructions are detailed on the MVVM Light installation page. Please make sure to uninstall previous versions before you install V4 beta1.

There are quite a few changes in this version, and I plan to blog about various features in the coming days. As usual, stay tuned!

Change log

General changes

Added XmlnsDefinitionAttribute for GalaSoft.MvvmLight.Command in Extras assembly.

Setup

Created an installer.

Messenger

Fixed Issue #7521: race condition in Messenger.Default.
Fixed Issue #7539: Messenger support for uncast objects.

ViewModelBase

Added support for RaisePropertyChanged(null) and RaisePropertyChanged(string.empty). A blog post about this will follow.
Fixed Issue #7520: RaisePropertyChanged() fails in ReleaseBuild. This overload was removed because of the many issues, and replaced by the Set methods.
Added Set(...) methods. A blog post about this will follow.

RelayCommand

Fixed Issue #7522: used deprecated Predicate instead of Func.
Fixed Issue #7534: RelayCommand has security issue.

SimpleIoc

Implemented method IsRegistered<T>(). A blog post about this will follow.
Fixed issue "Contains<T>() is returning true even if no instance was already instantiated". Contains<T>() only returns true if an instance is already created. IsRegistered<T>() returns true if the class has been registered with the IOC container.
Fixed issue "Instances get created at registration already when registered with a key and a factory". Registering the instance does not execute the factory method yet. The method is only executed when the method GetInstance is called the first time.
Fixed issue "Use the correct DLLs for CommonServiceLocator". The original DLLs from http://commonservicelocator.codeplex.com are now used everywhere.

DispatcherHelper

The class was moved from GalaSoft.MvvmLight.Extras.dll into GalaSoft.MvvmLight.dll.

Project Templates

A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

ViewModelLocator Template

Modified template to use SimpleIoc.
A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

ViewModel Template

A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

View Template

Fixed issue in XAML for WP7 and WP7.1 templates.
A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

INPC snippet

Setter in property is now public.
Added $end$ marker.
Added new snippets with various ways to call RaisePropertyChanged.
Added a snippet using the new ViewModelBase.Set() method.
A blog post will follow about all this.

ViewModelLocator property snippet

Added $end$ marker.
Modified to use SimpleIoc.

Relay Command snippets

Added code snippets for RelayCommands. A blog post about this will follow.

Details

XmlnsDefinitionAttribute for GalaSoft.MvvmLight.Command in Extras assembly

Thanks to the addition of XmlnsDefinitionAttribute, you can simplify the inclusion of the MVVM Light EventToCommand action in XAML. See the before and after below:

Before:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity" 
             
             xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.SL4"
             
             xmlns:cmd="http://www.galasoft.ch/mvvmlight" 
             x:Class="MvvmLight4.MainPage">

After:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity" 
             xmlns:cmd="http://www.galasoft.ch/mvvmlight" 
             x:Class="MvvmLight4.MainPage">

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

MVVM light V3 installer for non-English systems

Laurent Bugnion — Thu, 01 Sep 2011 20:28:01 GMT

After I released the MVVM Light installer, I got a note saying that parts of the installation failed on non-English systems (in that case a German installation of Expression Blend and Visual Studio). Specifically, what failed was the code snippets on Visual Studio, and the project and item templates in Expression Blend.

After investigating, it is correct that these two particular features of MVVM Light were installed to language-coded folders. Correcting the issue for Expression Blend was easy enough (Blend can also find project and item templates in the My Documents folder, under Expression\Blend 4\ItemTemplates and Expression\Blend 4\ProjectTemplates, which are language independent).

Unfortunately it was not that easy for code snippets, so eventually I had to resort to a few custom actions in the installer. How annoying that we cannot install code snippets to a language-neutral folder!!

Anyway, after a lot of efforts and even more testing, I published a new version which corrects the previous issues. So now I can happily resume my efforts on V4 beta 1 which is nearing completion, and which will also come with a neat installer

Happy coding,

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Automated installer for MVVM Light V3!

Laurent Bugnion — Sat, 06 Aug 2011 23:50:59 GMT

For a very (too) long time, the installation procedure for MVVM Light sucked. It involved downloading and unzipping files in various locations. Unfortunately, creating an automated installer is not completely trivial because of the variety of files that are getting installed: Binaries, Code Snippets, Project and Item Templates, all require different locations, and all that for VS2008, VS2010, Blend 4 and Silverlight 3, Silverlight 4, WPF3.5 SP1, WPF4, WP7.0 and now WP7.1 “Mango”.

Thankfully, MVVM Light is taking advantage of a great community. First, Leon Zandman initiated the project of an MSI for MVVM Light. Unfortunately, Leon was not able to complete this initiative, but the very helpful and capable Morten Nielsen created the installer in Wix. This gave me the occasion to learn Wix (I had only created setups with the Visual Studio setup project so far), and to tweak the installer. I am really grateful to Morten for his time!

Yesterday, I published the automated installer for MVVM Light V3. This installer contains binaries, project and item template as well as code snippets for Silverlight 3, Silverlight 4, WPF3.5SP1, WPF4, Windows Phone 7.0 and Windows Phone 7.5 “Mango”. It allows you to develop in Visual Studio 2008, Visual Studio 2010, Expression Blend 4 and/or Visual Studio Express for Windows Phone.

Update: The previous version has issues on non-English systems. This issue has been corrected now (as of 1st of September 2011).

And then?

A lot of people asked me when MVVM Light V4 will be published. As I mentioned above, I will release a beta 1 very soon. Beta 1 means that the API should be reasonably stable. I do however have more things I want to fix, so I am also planning a beta 2 before I hit RTM. The goal with beta 2 is to let people test my fixes, just to make sure that I didn’t break anything (yes I do run quite a few unit tests in all available frameworks, but… errare humanum est!).

It is really hard for me to give a precise timeline for those releases, because of work, a new house that we are moving to in August, my wonderful family who also requires some of my time here and there and my greedy Kindle 3 (just finished A Dance with Dragons, that one was pretty amazing). However roughly put, it looks like this:

MVVM Light V4 beta 1 before end of August.
MVVM Light V4 beta 2 not too long after that.
MVVM Light V4 RTM not too long after that

More than ever, I am amazed and delighted at the great feedback I receive from the MVVM Light community. This is not a perfect product, but your continuous constructive feedback keeps me motivated to continue developing and making this toolkit better. Thanks for your fantastic support!

Happy coding!

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Proposing a new RelayCommand snippet for MVVM Light V4

Laurent Bugnion — Wed, 15 Jun 2011 14:39:30 GMT

In MVVM Light V4, I am proposing a new RelayCommand snippet, making it easier to declare and initialize a RelayCommand. I came up with a syntax that allows having the RelayCommand and its initialization in one convenient location.

I am looking for feedback, so leave your comments below!!

RelayCommand

This is the code created by the code snippet after expansion, for a simple RelayCommand.

private RelayCommand _testCommand;

/// <summary>
/// Gets the TestCommand.
/// </summary>
public RelayCommand TestCommand
{
    get
    {
        return _testCommand ?? (_testCommand = new RelayCommand(
            () =>
            {
                // Execute delegate
                throw new NotImplementedException();
            },
            () =>
            {
                // CanExecute delegate
                throw new NotImplementedException();
            }));
    }
}

RelayCommand<T>

This is the code created by the code snippet after expansion, for a generic RelayCommand (with parameter).

private RelayCommand<string> _testAgainCommand;

/// <summary>
/// Gets the TestAgainCommand.
/// </summary>
public RelayCommand<string> TestAgainCommand
{
    get
    {
        return _testAgainCommand ?? (_testAgainCommand = new RelayCommand<string>(
            p =>
            {
                // Execute delegate
                throw new NotImplementedException();
            },
            p =>
            {
                // CanExecute delegate
                throw new NotImplementedException();
            }));
    }
}

Conclusion

Do you find this way of creating the RelayCommands convenient? This limits the number of key press to a minimum (the only parameters to enter are the attribute name, the command’s name and (in the case of the generic RelayCommand) the type of the parameter. Looking for feedback before I consolidate this for V4!

Happy coding!

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Is your application powered by #mvvmlight?

Laurent Bugnion — Fri, 20 May 2011 16:56:31 GMT

A couple of days ago I had the wonderful surprise to find a mention (and a link!) to MVVM Light on USAToday.com. The article talks about the new USA Today app available for Windows Phone 7. MVVM Light is mentioned as well as JSON.NET just after the high quality of the development tools is mentioned:

“That same high bar for tools extends into the community as well. MVVM Light and JSON.Net were extremely useful moving past mundane tasks and instead getting to the business of building our app.” – Tim Carlson, USA TODAY

This is of course fantastic, but it made me realize that I did not, until now, keep track of what applications (in Windows Phone 7 but also Silverlight and WPF) use MVVM Light to facilitate the development.

An appeal to MVVM Light users

In order to correct this, I would love to hear from you. Do you use MVVM Light? Did you publish an application (WP7, Silverlight, WPF) using the bits? If yes, do you mind answering the following optional questions:

What is the name and homepage of your project?
What framework is it? (WP7, Silverlight, WPF?)
Do you allow me to use this info for promotion (on the MVVM Light Toolkit’s page, or in conferences)? (if you prefer me to keep this info confidential, you have my assurance that I will happily comply).

Feel free to answer in the comments below, or per email to laurent@galasoft.ch. This is, in advance, very much appreciated!

Happy coding,
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn