Expression Blend – a powerful tool for developers

I’ve been experimenting with the use of Expression Blend as a tool in the life-cycle for day-to-day development for a typical .NET developer that might be writing an application using Silverlight with some sort of implementation of MVVM. Having used Visual Studio 2010 as my primary, all-in-one tool for developing applications, I was somewhat sceptical … Continue reading Expression Blend – a powerful tool for developers


Siverlight / WPF adoption over WinForms

I saw a couple of interesting discussions on LinkedIn this week with a few people discussing the merits / costs of using one of the XAML-based .NET frameworks compared to either WinForms or ASP .NET. Now, I’m somewhat reticent to compare SL to ASP .NET / HTML etc. as the two (to my mind) aren’t direct competitors. But WinForms and WPF, to me, seem like two technologies that are competing for the same space, with WPF destined to replace WinForms in the medium term; obviously since it came out it appears like it hasn’t been widely adopted, but I think this year we’ll see a larger uptake in WPF adoption particularly, for a number of reasons: - Wider adoption by third-party component suppliers. DevExpress, Infragistics, DevComponents, RAD etc. are all shipping slick-looking WPF components such as gauges, grids, navigation panels. Improved developer experience in Visual Studio 2010. VS2010 has better design time support now, which means that if you come from a WinForms background you should find the mental hurdle of writing forms in XML less so. Anyway, my main point if really about this: Which of the following do you see WPF as being used for? Either: - Graphically intensive applications e.g. 3-D animation, animations etc. Line of business (LOB) applications – primarily data capture over a domain model sourced from a database, with validation etc. Financial applications – graphs, some data capture, real time ticker feeds etc. Believe it or not, the answer is – all three! The main point for this article is this: I was surprised when I realised that a lot of people see WinForms as the preferred platform for writing LOB applications, despite the fact that WinForms offers very little over WPF now, whereas WPF offers some really compelling reasons for such an application, such as the awesome data-binding or the much more powerful control over behaviour and look of your controls e.g. listboxes in WinForms were effectively useless for direct binding whereas in WPF they’re actually very useful thanks to data templates. I also see people that believe that if you are writing a WPF application, it must use fancy animation, or worse still, that that is the only time that you should use WPF. Or that you cannot use WPF without being an expert in Blend. I’d disagree with all of these points! Whether you’re using WPF or WinForms shouldn’t affect whether you need animation in your application – is it a requirement? Then the technology choice is irrelevant! Do you need to do complex animation / styling? Then probably use Blend. If you just want to writing a simple LOB application (where perhaps the styling is not a core requirement) then don’t bother! I guess the upshot of this rant is this: Don’t judge a technology only by what new features it brings to the table. Judge it by everything that you can do with it. I personally see WPF as a full on replacement for WinForms, and encourage you to think of it as such, too. And if you want to get into it but don’t know how, I would suggest this. The next time you need to write a little in-house application to help you out in your day-to-day tasks, or write a tool to e.g. configure your main application to give to administrators/end-users – write in in WPF. Start small, with low-risk applications and solutions. Build up your knowledge of what it does and how it works slowly, but surely.

PRISM from Patterns and Practices

I’ve been looking into the Prism framework that came out of the Patterns and Practices team – if you’ve not heard of the framework, it’s basically the WPF and Silverlight version of Smart Client Software Factory. And if you’ve not heard of that – well, it’s a framework and set of guidance packages to write modular, decoupled and extensible applications i.e. any application that you expect to have a medium-long shelf life with changes throughout it’s lifespan. I’ve had a relatively short look at it but expect to be spending more time with it over the next few weeks and months. So far, it looks like it addresses a number of the shortcomings of SCSF, such as the lack of flexibility with the framework in terms of IoC container (which was pretty much fixed to object builder in SCSF) and a clearer set of services and interfaces. It also allows you more control in terms of how you register modules within the shell than SCSF. Generally, so far it seems more lightweight and easier to access than SCSF, although it retains many of the concepts. As I touched on before, it can use any IoC container that you want, although by default it uses Unity – which suits me fine as I really like that. One thing I’ve not seen a decent answer on yet is how to register regions (think workspaces) into a modal dialog; in SCSF you had a modal dialog workspace which popped up a window automatically when you did a ShowViewInWorkspace – not seen anything like that in Prism yet. There are a good set of videos on the net on Prism; I’ve been going through good old Mike Taulty’s series on Channel9 recently, and I’d recommend that if you want a good start in Prism. In particular, the first video is an excellent introduction if you have never thought about how to write decoupled and extensible applications using principles like SRP and the like.

Silverlight 3 Data Editing abilities

I’ve been looking at Silverlight 3 (SL3) lately and seen some of the data editing features of it – really, really impressed with it. SL3 comes with lots of great-looking controls such as: - Charting Calendar, Date and Time Pickers Tab Control Auto Complete boxes It’s actually getting to the stage where Silverlight is in some ways appearing to be a more compelling choice than WPF as a way to write rich UIs, since the control set has become that much richer. Anyway, the two controls that I was most interested in were the Data Form and the Data Grid controls – two controls that for any LOB and data capture you’ll want to be using… Data Form This is a generic control to edit the fields of a particular entity. It supports change tracking, paging / record navigation, validation, and tooltips. Here is a simple Employee entity: public class Employee { public string Name { get; set; } public string Project { get; set; } public string Skillset { get; set; } } Basic Functionality To edit this entity in the Data Form, drag on a DataForm and set the ItemSource property in code: - Here’s the (slightly simplified) XAML. I’ve just removed some of the initialisation XAML but the Grid area is the bit we are interested in and it’s completely unchanged. And here’s the code for the UserControl_Loaded event. I’m creating some “fake” employees and then binding that to the grid. private void UserControl_Loaded (object sender, RoutedEventArgs e) { employees = new List { new Employee { Name = "Isaac", Skillset = ".NET", Project = "TCP" }, new Employee { Name = "Tim", Skillset = "Business Analysis", Project = "Client 1" }, new Employee { Name = "Fred", Skillset = "XRM", Project = "Client 3" }, new Employee { Name = "Jane", Skillset = "SQL", Project = "Client 2" } }; this.dataForm.ItemsSource = employees; } Here’s what we get when we run our app: We can now edit any of the properties and the control has automatically bound them to the underlying datasource. Notice also the record browser at the top right of the form. By clicking the + button, the control will automatically create a new entity and add it to the ItemSource; similarly hitting the – button will remove the entity. Here I’ve hit the “+” button to create a new entity. Pressing OK pushes the new entity into the collection, Cancel drops it. Also remember that this form is being dynamically generating based on the entity’s public properties. Further functionality The data form control can also do much more than basic editing of data. By decorating our entity with certain attributes, the control will do: - Validation Tooltips Field Description Here’s a revised version of the Employee entity: - public class Employee { [Display (Name = "Employee's full name", Description = "The name of the employee", Prompt = "Enter the user's name here...")] [Required (ErrorMessage = "You must enter a name for this employee")] public string Name { get; set; } [StringLength (16, MinimumLength=3, ErrorMessage = "Project name must be between 5 and 16 characters long")] public string Project { get; set; } [ReadOnly(true)] public string Skillset { get; set; } } I’ve now put a few attributes on some of the fields; by now re-running my code, without any change to the data form, I get this: Notice that: - The first field now takes the “Name” parameter on the Display attribute The first field is shown in bold to indicate that it is Required. The third field has a grey background to indicate that it is read-only. The first field has an “i” icon next to it. Hovering over it displays a tooltip: If you fail the validation on any of the fields, when trying to leave that record you get the following: Clicking on any of the errors sets the cursor focus to the field in question. I am pretty sure that you can control the styling of all of this through XAML, but the default look and feel seems pretty OK to me. This validation will also kick in automatically if you e.g. enter a string into a integer field. More control over editing You can also set a few properties on the control to specify whether editing and committing of changes happens implicitly (as above) or explictly (see below). When you are explicitly editing data, you first have to the hit the “Edit” button in the record navigator to edit the record in view; then you hit the OK button (which only appears in Edit mode) to persist your changes. Change Tracking You’ll notice in the last screenshot that there is no Cancel button. That’s because your entity does not track what it’s been changed to. But you can fix this by implementing IEditableObject on your entity; I’ve done it on my Employee class below: public class Employee : IEditableObject { [Display (Name = "Employee's full name", Description = "The name of the employee", Prompt = "Enter the user's name here...")] [Required (ErrorMessage = "You must enter a name for this employee")] public string Name { get; set; } [StringLength (16, MinimumLength=3, ErrorMessage = "Project name must be between 5 and 16 characters long")] public string Project { get; set; } [ReadOnly(true)] public string Skillset { get; set; } #region IEditableObject private Employee originalValue; ///

/// Causes the object to enter editing mode. /// public void BeginEdit () { originalValue = new Employee { Name = this.Name, Project = this.Project, Skillset = this.Skillset }; } /// /// Causes the object to leave editing mode and revert to the previous, unedited value. /// public void CancelEdit () { this.Name = originalValue.Name; this.Project = originalValue.Project; this.Skillset = originalValue.Skillset; } /// /// Causes the object to leave editing mode and commit the edited value. /// public void EndEdit () { originalValue = null; } #endregion } All I’m doing in the above code is making a copy of the object as soon as you BeginEdit. If CancelEdit is called, I revert back to the old version of the entity, otherwise if EndEdit is called I remove the backup copy. Now when we edit any entities we get a Cancel button, too! This obviously calls CancelEdit above, whereas OK calls EndEdit. DataForm looks like it’s a very powerful control that will save us lots of time when editing basic data on an entity. Because it has inbuilt support for validation (with support for RegEx as well) and change tracking, it’s something that could be of real use with LOB applications.