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.
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.
Coming from a WF background, I was pleased to see that most of the standard controls are also available in WPF, such as Textboxes, Combos, Listboxes etc. However, as you might expect, it’s a not a direct like-for-like swap between the two worlds. Firstly, there are a few controls which you’ll have used in WF that no longer exist out-of-the-box. Some are obsolete, like the Panel and Table control, which is no problem at all – the Grid and StackPanel etc. are superior to them anyway. However, some others, like the Numeric Up Down and Date Time Picker aren’t included. There are a few freely available controls that people have written that seem to do the trick, and I’ve been trying them out with varying degrees of success. Another omission is a DataGrid-esque control. I think what people are probably doing is to use existing WF grid controls within WPF applications. There are also a few commercial third-party control suites coming available – some look very impressive. But then again, the Infragistics website looks excellent too, and I’ve never been that impressed with what they offer. By and large, by default the controls behave pretty much as per before for the simple situations etc.. Some of the property names are different e.g. IsEnabled instead of Enabled – but generally I have had no problem getting up to speed with these controls. There are also some nice new features, such as out-of-the-box databinding to ListViews and Treeviews (finally!). The biggest difference between the way that the WF control set was designed and the WPF one is that WPF controls are “lookless” i.e. they contain a fixed set of behaviours, but a flexible and extensible presentation tier for the control. A simple example would be if you had an object which had two properties, Forename and Surname, and wanted to display both items in a ListBox. In the WF world you might have created a read-only property called Full Name or perhaps created an anonymous type for display purposes built on top of the two fields concatenated together. In WPF, you can now change what controls are used to display each item in the list e.g. in the example above, you might have two labels one after another, with the first displaying the forename and the second one displaying the surname. You can use this approach to create controls that are really just e.g. ListBoxes in terms of behaviour, but look nothing like them. Very cool.
This is the part of WPF that, from as a Windows Forms (WF) developer for the past few years, I found most difficult to get my head around. However, once I’d actually read a bit up on this, it became second nature and I think is actually fairly intuitive – not to mention more flexible than the old WF way of doing things. In Windows Forms, you tend to use absolute positioning as the way to layout your forms. Most controls are fixed in size at design time. There are some features that .NET provides to allow more flexibility – such as anchoring and docking. In addition, .NET 2 came with FlowLayout (which I hated) and Table (which I loved) containers. The Table one specifically, allows you to create consistent “grid-like” forms with Labels and Textboxes nicely aligned etc. It’s a little buggy but I’d rather have it than not! However, localisation of applications is difficult e.g. if a button text is too long etc. it can overflow the control. WPF takes a completely different approach. There is no “anchoring” or “docking” like in WF. Instead, content can automatically resize itself to fit it’s container, depending on the size of the control and the settings of the parent. Instead of explicitly setting the width and height of a control, you can now simply use * to fit it to the container (actually, this is the default so if you don’t set the width it fits the container automatically), or “Auto” to set it to as big as required for its content. As the content changes, the size will automatically change. You’re discouraged from using absolutely positioning (although you still can) because it leads to a more rigid form which cannot easily change. WPF comes with several container controls which your controls (buttons etc.) live inside: StackPanel The Stack Panel places items either vertically or horizontally on top of one another. In this example, the Stack Panel contains four controls – a Label, two buttons, and a progress bar. Notice how the buttons and progress bar automatically resize themselves to fit the width of the panel. WrapPanel The Wrap Panel is similar to the FlowLayout container in WF – it arranges items in a list horizontally. When they reach the end of the panel, they wrap onto the next line. In this example, the Wrap Panel contains those same four controls – I’ve set the width of the Progress Bar to 100 units wide. As the four controls can’t all fit on one line, the Close button and Progress Bar and pushed onto the next one. Notice how the Buttons now size to fit their content text. DockPanel The Dock Panel decorates child controls with a Docking property that allows you to dock them to a particular side of the Dock Panel. In this example, I’ve docked the Label to the Top, the buttons to the left and right, and the progress bar to the bottom. You have to be careful of the order that items appear in the XAML so that they dock as you intend e.g. in this example, the Label comes before the buttons in the markup. If it came after them, the OK and Cancel would extend all the way to the top of the panel and the label would have been surrounded by them. Think of it almost like the “bring to front” feature in Windows Forms. Grid Think of the Grid container as a better version of the Table container found in WF. It allows you to create rows and columns and place controls inside them, just like the Table. However, it requires less effort to achieve similar results. It’s probably the most useful container control, and it’s the default one you work with whenever you create a new Window in VS 2008. In this example below, I’ve created a 3x3 grid. The middle column has it’s size set to “Auto”, meaning it’s width is equal to the minimum required by its child objects i.e. the OK button. The middle row is set to 50 units high for the Progress Bar. I’ve also set the Column Span for the Label to 3 columns so that it goes all the way across. The designer support for Grids is pretty good – so I’ve got screenshots of both the Grid running and in the designer (taken from VS2008 Express). The columns and rows are draggable within the designer to quickly resize them if necessary; you can also see the sizes from the numbers on each row/ column, and get semi-transparent grid lines to help you keep focus of where you are in the grid. All of this disappears if you’ve not selected a control within the Grid. Nice. Note that in the running version of the Grid I’ve explicitly left the gridlines on – these are turned off by default. Canvas This lets you use absolute positioning for items within the Canvas. I’m not going to talk much about this as I've not used it really and, again, the recommended approach is to not use absolute positioning in your Forms. There's no Anchor or Docking facility with WPF like in Windows Forms if you're in the Canvas. Apart from the Canvas, all the others work by position their contents relatively to one another – so if one changes size, all the others automatically resize and reorder themselves as appropriate. I found it a bit unusual designing a form like this but once I got the hang of it I realised the benefits of such an approach: You tend to spend more time getting the layout correct, and then placing controls inside them. Once you’ve done this, your form almost seems to “magically” arrange itself – you don’t get the problems as in WF where adding a new control later on requires all sorts of re-ordering and resizing of the existing controls.
Surprise, surprise. If you know anything at all about WPF, you’ll have heard of XAML (eXtensible Application Markup Language). At it’s simplest level, it’s the replacement for the designer.cs that you get when you create forms in Windows Forms. Whereas WF uses programmatic statements one after the other to create content, XAML is an XML-based hierarchical, declarative markup language much like HTML designed to store your form content. So, you might have content looking something like this: Hello World! This is a crude example that wouldn’t even compile but you get the idea. It would probably map in C# to creating a Panel and then doing a Panel.Controls.Add (new TextBox()); or whatever. XAML is very powerful. They’ve taken some of the good ideas out of web design and brought them into the .NET world, such as styles (similar to css), as well as the ability to declaratively linked presentation to events e.g. you may have a style for a button to use when the mouse is over it and another for when it has focus – you can do this all inside your XAML without having to write any C#. In terms of performance, it’s not interpreted or anything like that – at compile time it gets turned into a binary form within your assembly so it can be read very quickly. Although you probably don’t need to know this, WPF also uses DirectX extensively (even for non-3D graphics) and almost 100% does away with the reliance on GDI and user32.dll etc. that Win32 and Windows Forms uses. If you have a decent graphics card, this means that it uses that for rendering and calculations and takes advantage of all your cards features. There are a few ways of writing your XAML within the context of an IDE – the most obvious choice is Visual Studio. VS2008 and 2008 Express Edition both have integrated XAML designers with a neat split view so that you can see your UI and your markup at the same time: This view can be resized and changed to a vertical split, or you can opt to just work in XAML or Visual Designer mode. The Visual Designer is mostly the same although some things have been streamlined and enhanced depending on the control that you’re working with. Firstly there’s a handy document outline which, as with “regular” XML documents, lets you walk the tree of elements in your markup and see the hierarchy.You also get a handy little breadcrumb on the bottom which shows you the branch that you’re currently on; leaving the mouse over an crumb will give you a visual tool-tip of that item downwards – neat. There’s also a rich collection of ready-made controls, most of which are pretty similar to their original WF counterparts although most are different enough so that you can’t just jump straight in and carry on as normal. You can either drag-and-drop controls onto the page, or simply enter the markup for them directly into your XAML and the controls appear in the Designer pane. This is my preferred way of doing things currently, because when you drag controls on, VS tends to set extra properties and attributes that you may not want on. Plus, I want to learn what all the attributes do, and just using the designer isn’t the best way of doing that in my opinion. Another option – and probably the “ideal” scenario in professional development environments – is to have a specialised XAML graphic designer who works on the UI of an application whilst the application developer handles the programmatic side of the app. However, this does not mean that the designer would need to learn how to use Visual Studio. There’s another application, Expression Blend (is it still called that? It’s gone through several name changes since it was in beta) - a Microsoft application that is geared towards creating XAML UIs. This comes with a lot more tools for generating XAML, styles and so on – but it also understands VS project file formats and even C# (although the C# editor is, as expected, crude). So one person could be designing the XAML in Expression Blend whilst the coder is working on the code behind – when the design makes changes to the XAML, the developer gets the latest look-and-feel. I suppose that this is the logical progression for where MS is going with UIs – in .NET 2 they introduced partial classes as a means to separate the designer.cs from your main code-behind; now they’ve pulled it out even further. There are several benefits to XAML: - Provides a mechanism to completely separates the UI from the code – although you can still add controls programmatically if you really want to. But having used XAML now, that method just seems ugly and slow to write. I would never write a Form in WF manually, but in WPF it seems quite doable for relatively simple ones. - You can spit XAML out to be rendered in a browser as well. Obviously if you want the code behind to work as well (like Java Applets) then you’re looking at extra deployment requirements and security (look at XBAPs) but it’s definitely possible. Of course, there are lots of things that you can do in XAML that would have required lots of coding in the WF world – I’ll talk about them in future posts.
So, I’ve finally decided to take the plunge and learn WPF. I’ve been trying on-and-off for a few months but there’s a distinct lack of online resources for Windows Forms developers trying to make the leap across to the WPF world. So, I’ve gotten a book and have been working through it. I’m really surprised at just how different WPF is, even at this early stage of the book. Lots have been made of WPF’s new media features, and the introduction of XAML has made things somewhat different to writing your forms but that could have been introduced without any changes to the design model/ strategy for creating forms – this is, to my mind, the area that’s changed dramatically from Windows Forms. If XAML was the only thing that was new, we could carry on coding as normal because you rarely look at designer.cs anyway. What I’m more interested at the moment is how to get the regular LOB functionality that one can do in a Windows Forms app with their eyes closed e.g. : - Form / Control layout Data binding User controls Events What I’m planning on doing is writing a few articles about how easy or hard it is to write applications in WPF coming from a WF background; I’m not an expert graphic designer although I can design relatively good looking UIs in WF. I want to try to discuss the new features of WPF but relate them to existing WF ideas or problems that you might come up against and compare and contrast the two.