Looks I’m not the only one who has a beef with Windows Forms. Robert McLaws post kind of started off a whole flurry of cross posts. There’s a sincere response from one of the WinForm team members as well, that brings a little balance.
I’ve had a lot of issue with WinForms starting with horrible performance, major inconsistencies in control behavior, lack of common behavior (where’s the TreeView NodeClick for example?) and just plain screwed up behavior (EnableVisualStyles anyone?). From what I can see in Whidbey so far some of the issues are being addressed, but the inconsistencies are still there.
Think about some common controls like the toolbar – have you ever gotten this thing to do what YOU as the developer want it to do? How about a Tab Control which doesn’t have the ability to even hide, make invisible or even remove items from the control at runtime? A treeview that doesn’t have the equivalent of a NodeClick. The DataGrid is barely usable because it lacks customizablebility at almost every level and looks awful. How about Edit controls that have a strange margin that cannot be changed? A DateTime combo that can’t deal with a null.
WinForms applications are slow. Let’s face it the UI in these applications is sluggish. It’s not uncommon to see the user interface on forms draw rather than snap on the screen. Apps are slow to start, especially if the .Net runtime was not loaded at first. I have two identical apps, one in Visual FoxPro and one in .Net. Both apps perform almost exactly the same tasks at startup. On first load the .Net app takes around 20 seconds to load – the Fox app less than 5. On subsequent loads the same app will load in about 5-8 seconds in .Net and less than 1 second in Fox. Sure these are pretty heavy forms with lots of controls, but waiting 5 settings for this app even under the best conditions is pretty bad. Watching the controls draw onto the screen when the form comes up is fun too… and I always thought VFP apps were slow to start up. Granted this app is fairly fat. It loads up data from SQL Server and stuffs a fairly large number of records into a ListView for display and then displays about 30 textboxes. But while profiling it turns out the behind the scenes code is fast – all the slowness is in .Net rendering the form. But the Fox app does exactly the same things and Fox isn’t a speed demon when it comes to user interface operations either (especially when populating an ActiveX ListView). But compared to .Net WinForms it downright flies. And these are just a few things I can think of this second. There’s plenty more to bitch about.
I’m going to argue that there’s nothing wrong with the WinForms model, rather that there is something wrong with the implementation in the form of controls that are provided out of the box. Obviously, some of the third party vendors get it right and they provide consistent controls across platforms. No one can tell me that if a (maybe not so) small control development company can do this that Microsoft ‘has limited’ resources. I don’t feel sorry for the folks at Microsoft…
I don’t want to see third parties getting thrown out of the game either, but it would go a long way for Microsoft to put top shelf controls into the box. This is about look and feel as well as functionality and optimizations. The 1.x controls where definitely a little short of some common features.
I don’t want to sound like a whiner and I do know that the folks at Microsoft are putting a lot of effort into building the best tools they can – it’s not a conspiracy. But often it seems that the MS developers don’t understand how we use the tools. A lot of this is because of Win32 API mindset rather than a higher level object approach. I understand that it’s difficult to build quality and consistent controls, but there are developers that specialize in control development. Don’t any of these people work at Microsoft? It always seems like control design in Microsoft dev tools is an afterthought or a last minute thing. Oh – we need controls too?
In response to Robert’s point of making controls more alike in Windows and Web: I don’t think that one needs to necessarily bring the Web’s stateless model into this. Consistent property, method and event names certainly would go a long way there. I don’t think anybody expects to write code on one platform once and just run the same code on the Web or vice versa. But I would expect to be able to cut and paste code out of a button click event and be able to access form properties in a similar manner. This stuff is just not close enough as it could have been.
And what about Databinding? I’ve heard the argument over and over again that the WinForm model doesn’t fit with the Web and vice versa. Has it ever occurred to anyone that both models may be invalid for databinding. Yes the two models have different needs but the Web for example doesn’t have to use all of the same features that the WinForm model needs and the interfaces could still be the same. Instead WinForms and WebForms in Whidbey both introduce yet another new and separate databinding model. 4 models for doing something as simple as databinding? C’mon…
On the other side of the coin is the fact that third party companies are doing a pretty good job of providing powerful controls within the confines of the WinForm model. Given that it’s clear that the model provides the core functionality – the problem seems to be in the higher level abstraction.
It’s going to be tough going forward now though, since there’s a baseline that needs to be adhered to. Backwards compatibility can be a curse – I did notice that in Whidbey many new controls have been introduced that replace the old ones and a lot of these work very differently. While this may provide relief in the form of new functionality, this will also be potentially confusing for new developers who look at two objects that are very similar and now have to choose. It’ll be interesting how this will be addressed (I guess the stock control palette just won’t show the old controls?).
No easy answers, not for us as developers, and certainly not for Microsoft.