Elaborating on an Earlier Post
I wanted to take a second and defend my earlier post about WindowsForms. Had quite a few people point out how obviously stupid I was for not looking deeper into the system. So, I thought I would take a few minutes and point out what my specific beefs are, coming from the ASP.NET world. Just because I am normally a WebForms developer does not make my arguments any less valid, nor does it mean that this is my first time building a WinForms app. This is my first super-complicated WinForms, and I don't like the hoops that I had to jump through to make it work.
I'm going to start out with the List controls. I'm going to come right out and say it.... they suck. BIG TIME. I'm going to get really specific about why they suck, so bear with me. Lets start with putting items into the collection. In ASP.NET, you get a Name/Value collection. Doesn't matter how you do it, you will always get a SelectedIndex, SelectedText, and a SelectedValue property. Not so with WinForms. In the designer, you get a single line box that says "Please enter one item per line". Further, items are not of an expected type, like ListItem. No, Items are of type Object, which makes the whole control really discoverable IMO. (Please note that the previous statement was sarcasm.)
So then, Cory Smith tells me that the IS documentation and samples for these controls, "Just hit F1, stupid". What Cory and a few others neglected to do when looking at these documentation samples was to actually READ THEM and run the code. Just for a review, here is the code in this sample:
Private Sub WhatIsChecked_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles WhatIsChecked.Click
' Display in a message box all the items that are checked.
Dim indexChecked As Integer
Dim itemChecked As Object
Const quote As String = """"
' First show the index and check state of all selected items.
For Each indexChecked In CheckedListBox1.CheckedIndices
' The indexChecked variable contains the index of the item.
MessageBox.Show("Index#: " + indexChecked.ToString() + ", is checked. Checked state is:" + _
CheckedListBox1.GetItemCheckState(indexChecked).ToString() + ".")
Next
' Next show the object title and check state for each item selected.
For Each itemChecked In CheckedListBox1.CheckedItems
' Use the IndexOf method to get the index of an item.
MessageBox.Show("Item with title: " + quote + itemChecked.ToString() + quote + _
, is checked. Checked state is: " + _
CheckedListBox1.GetItemCheckState(CheckedListBox1.Items.IndexOf(itemChecked)).ToString() + ".")
Next
End Sub
For Each item As String In CheckedListBox1.CheckedItems
MsgBox(item)
Next
Pasting this code into VS.NET brings up quite an interesting result. indexChecked.ToString is NOT wired up to actually dump the value to a string. It is actually designed to dump the item type to a string, which seems to me to be rather useless. Now, as I mentioned before, the type is not a variant of ListItem, as you would expect. It's actually a member of System.Data.DataRowView, which is not even CLOSE to being intuitive OR discoverable. Little did I know that I would actually get a database row to work with instead of a name and value, EVEN THOUGH I set a "DisplayMember" and a "ValueMember". I can't even access the value that I set. Further, the last "For...Each" loop produces zero useful information.
OK, onto the different ways to access selected items. I blogged earlier that there were something like 9 different ways to get at a selected item. Several people said that I was incorrect, and they were right. Further inspection of the object model with IntelliSense uncovered 12 different properties that could be used (or a user would assume could be used) to access selected items. They are (in alphabetical order):
CheckedIndexCollection
CheckedIndices
CheckedItems
Items
SelectedIndex
SelectedIndexCollection
SelectedIndices
SelectedItem
SelectedItems
SelectedObjectCollection
SelectionMode
SelectNextControl
I mean, come on here. I thought this stuff was supposed to be intuitive? I can't even have a simple name/value pair. And don't even get me started about databinding. The designer doesn't support specifying column names to bind text and values, instead you get DisplayMember and ValueMember (wtf is that???) and the binding is not procedural (i.e. CheckedListBox.DataBind), it's actually called when you set the DataSource.
Now, this is not just a pointless ranting, so if you're still paying attention, here is the point. It is extremely apparent to me that WinForms is the bastard child of .NET. Don't believe me? Open up two browser windows, and put them side by side. Set the one on the left to www.windowsforms.net, and set the one onthe right to www.asp.net. See the difference? The quality of information and presentation on www.asp.net is dramatically better. This same disparity is apparent in many aspects of WinForms construction, from the samples, to the documentation, to the object model. Is that the fault of the WinForms team? No. It's the fault of Microsoft as a whole, and here is why.
Microsoft touted .NET as the way to build client-independant systems. Using web services back ends, it doesn't matter what front-end you use. Here's the dealmaker/breaker. For this architecture to make sense, and have a wide adoption, both client models should be intuitive, and close enough alike that someone specializing in one client mode should be able to put together the other in a fairly straightforward way. For me, this is not the case. Am I the only one that feels like it? Probably not. But I shouldn't need a CS degree and 4 hours to figure out how to get data in and out of a freakin ComboBox, for BillG's sake!
In closing, I am distressed at the amount of negative activity occurring in this community as of late. I don't know why everyone jumps down everyone else's throat all the time, but calling me an idiot and a moron because I have an opinion is hardly showing respect for anyone as individuals here. We are all examples to others here, and we should behave as such. If my post came across as rude, then I apologize. I think I've spent long enough at this point validating my original argument, and I stand by it. I never said that they didn't do a good job compared to what they had. My problem was with the level of disparity and lack of intuitiveness between the two programming models. And the people at Microsoft should pay attention to that opinion. If a seasoned programmer has difficulty with it, how hard is it going to be for a newbie?