Windows Forms Annoyances

I've not yet looked at Beta2, but here's my list of annoyances with Win Forms 1.x; Win Forms in its current incarnation is like a poor cousin in the .NET world - it's like it was developed as an afterthought to ASP.NET, C# and the .NET Framework.

1. The Win Forms Designer -

1. it deletes your controls after you've carefully composed a form (apparently fixed in beta2); this bug alone really makes me mad! So I don't use the damn thing as I prefer to complete a task once and not every time the tools decide to destroy my work!
2. when you drag controls around, it adjusts the relationships of the controls to each other - so if you have neatly arranged your controls in a line, when you drag them to another location they'll be all out of alignment...
3. if your form code has a bug (e.g. you've got a custom control that barfs while the designer is rendering it) then the forms designer blows up - that's fine, but at least tell us the exception details and give us a stack trace so we can work out what went wrong!
4. Aligning controls is just too damn fiddly! It's actually easier to layout a UI design in Visio than it is to implement it in VS 1.x.

2. The Win Forms Controls

1. Listviews, treeviews, etc all require an ImageList control to work - just like the VB.OLD controls did! This is rubbish, as it requires you to load an ImageList at design time with all your images and bind it to the control in question - but I want to be able to use multiple resource files to hold my images and load the control directly from them at runtime! I really, really hate ImageList, and the behaviour of the control really hasn't changed an awful lot since the VB.OLD days;
2. All the controls work and look pretty much the same as the VB.OLD controls; this is no bad thing, as it's easy to pick up Win Forms if you have experience with putting VB UIs together; but unfortunately you have to take the good with the bad - for instance events that give you very little information other than the standard eventargs - which mouse button was clicked? In a tree, did the user click the icon, the expando button, the text...? Unfortunately, I guess we'll be stuck with this now as it's unlikely that future Win Forms will introduce breaking changes by redesigning control interfaces.
3. XP Theme support sucks - not all the controls support it (e.g. the spinner controls); try making a tab control take on the Xp theme... the listview doesn't support grouping... having to set the flat style on controls that support it is a dumb hack... some of the controls' borders won't take on the XP border style so you have to resort to owner-drawn controls... Application.EnableVisualStyles() is buggy (it fires a native Win32 PostMessage() off asynchronously, and if it fails to complete you'll get random
   System.Runtime.InteropServices.SEHExceptions forcing you to call the abomination Application.DoEvents() to ensure the PostMessage() completes before your call to Application.Run() - aaaargh!);
4. How about some MVC support? And no, I do not want to use the UIP application block, as this is really only appopriate for use in web applications (and I'll fight anyone to the death who says otherwise) - fortunately MS have admitted this and are working on a new Win Forms specific implementation in Enterprise Library; but let's see support for this in Win Forms itself. It's about time the Patterns & Practises group started putting its money where its mouth is.
5. Why is context-sensitive help so poorly implemented in Win Forms? How do I tell whether the form's Help button was clicked or whether the user pressed F1 easily? Why can't I pull context sensitive help out of a Help file without invoking APIs (the managed interface expects you to hard-code context-senstive help in your application code and have it completely separate to your help file - gaargh!);
6. Overall, the Win Forms controls are just thin wrappers around the native Win32 controls, designed to emulate the VB.OLD interfaces; well, OK there are some changes, but they offer very little in the way of value-add.

I'm sure I'll come up with more soon enough. I'm looking forward to trying out VS 2005 to see if any of these are fixed or at least addressed.