lassic VB ListBoxes held a simple array of strings used for the list, and a parallel ItemData
array that held a list of Long numeric values. Using the two in tandem, you could populate a ListBox with a list of strings to display and simultaneously populate the ItemData
property with some type of ID or primary key field value. When a user selected an item (or items) you could retrieve the ItemData
value and use it to obtain the associated object or use the value as a lookup value for a database query.
However, in VB.NET, when you drag a ListBox onto a form and then try to write the same loop to populate the ListBox, adding a text value and an ItemData
numeric value for each item, you'll get a compile-time error. ListBoxes in .NET don't have an ItemData
property. Hmm. It does seem that the ubiquitous VB ListBox lost some backward compatibility. But in doing so, it also gained functionality. Rather than holding simple String values, the ListBox's Items collection now holds Objectswhich can be anything. In addition, you can set a DisplayMember
property for the ListBox (by default, it calls the ToString() method) of the item. Before displaying the item, the ListBox invokes the item member named by the DisplayMember
In other words, rather than storing a single set of strings and associated ID values and then having to retrieve the appropriate data when a user clicked on the item, you can now store the entire set of objects right in the Items property.
Still, despite considerable effort by VB.NET experts to convince people of the advantages of VB.NET's Items collection, many people aren't happy with the new ListBox implementation. One reason is that the consumers of a class aren't always the creators of the classand they may not be satisfied with the class creator's selections.