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.
So, I’ve managed to get through most of the problems and actually worked through a few of the labs! Some of what SCSF gives you seems quite good – a lot of the stuff that you do (or would like to do) in projects but generally do in a different way each time. Things like the following, which I have done in the last few projects in a bespoke manner that you get pretty much for free with SCSF: –
Commands / multicast delegates (nothing you don’t get in C# anyway except that you can do it quite elegantly using attributes on methods)
Decoupling between your form’s shell and inner modules / views
I’m sure that there’s lots more to see. But I’ve also found a few more annoying things about it: –
When you try to create a new View in VS2008 SP1, if your Infrastructure assembly is not named Infrastructure.Assembly but instead <root namespace>.Infrastructure.Assembly, the option won’t appear in VS! Why???
Namespaces of views that you create do not obey folder hierarchy rules e.g. a View + Presenter living inside MySolution/MyProject/Views/MyView should have a namespace something like MySolution.MyProject.Views.MyView.MyView.cs and MyPresenter.cs etc.. Instead, it’s simply in MySolution.MyProject. This is (IMHO) just plain wrong. VS automatically pads on the namespace for new classes based on the folder structure, so why doesn’t SCSF? Even worse, any other classes that you create will obey the “proper” rules so you end up with classes in the same folder with different namespaces!
So generally I think SCSF looks quite nice, albeit it seems like they haven’t updated it in a while and that it’s got a few issues with it that could have been fixed relatively easily but they just haven’t been bothered / had time (note – last version of SCSF WinForms was April 2008)??
A word of warning. When you drag an Infragistics 2007 grid onto your form, it doesn’t create it "empty", but with hard-coded appearance settings put into the designer.cs. This results in your AppStylist themes not working 100% correctly since they get overridden in code. There is no warning that this happens and it occurs apparently by default. I’m told that the 2008 release fixes this, but I’m amazed that this slipped through the net. I had to manually go through the designer.cs for about 10 Forms & Controls and modify the generated code to remove the junk so that my Style worked as expected.
There’s a workaround for this – when you first drag on the Grid, immediately use the "Reset Layout" function (in the Properties pane) to get rid of all the hard-coded stuff that it’s created for itself. You can’t really use this function later, however, as it removes all changes that you’ve to the Grid made including hidden columns, groupings etc. etc..
We’ve started using Infragistics as our toolset of choice for Windows Forms programming. I can’t stand it! I’ve been using the Janus control set for the past few years and have grown to really like it. It has a few small issues but generally fits in very well alongside / in place of standard Windows Forms controls. The API is very similar to the standard Windows one. The controls look good. The designers are well written.
Some of the controls are plain strange, too. What’s the IG equivalent of a standard Combo Box? Not the UltraDropDown, or even the UltraCombo – but the UltraComboEditor! Talking of the DropDown – this is one of the most unusual controls I’ve ever seen. It’s a good idea – a control which can be used to resolve lookups in Grids etc. However, the visual implementation is absurd. It’s a non-visual component i.e. it resolves data, and serves no purpose on the screen. However, instead of sitting in the toolpane alongside e.g. ToolTip providers, Error providers, and BindingSources etc., you actually get a physically list control on your Form at design time. When you run the application, it magically disappears from the screen though – so it behaves like a non-visual component at run time but at design-time it’s a visual control.
I’ve put the first of no doubt what will be a multitude of questions to the support team – let’s hope they are helpful!