active wrote:
Can you see why this does not sort the list?
It displays OK but is not sorted
<snip>
Private mItemList As List(Of StringWithInteg er) = New List(Of
StringWithInteg er)
<snip>
GenericComboBox 1.BindingSource DataSource = mItemList
GenericComboBox 1.SortItNow("St rng ASC")
<snip>
Public Class GenericComboBox
Inherits System.Windows. Forms.ComboBox
<snip>
Public BindingSource1 As BindingSource = New BindingSource()
<snip>
Public Sub SortItNow(ByVal sortString As String)
BindingSource1. Sort = sortString
End Sub
End Class
According to the docs, the BindingSource class relies on the objectc
assigned as DataSource to most of its operations, which most of the
times requires only an IList implemtation form the DataSource. But for
the all-important operation of sorting, BindingSource requires that
the DataSource implements IBindingList or IBindingListVie w.
The problem with most general list implementations provided by the
framework (List(Of T), Dictionary, ArrayList, etc etc) is that none of
them supports IBindingList or IBindingListVie w (even though some of
then do support sorting, relying usually on the contained data
supporting IComparable, or taking hold of an instance of IComparer).
You'll find an *almost* complete implementation of IBindingList in the
System.Componen tModel.BindingL ist(Of T) class. Unfortuantely this
class *doesn't* support sorting either -- you'd have to derive from it
and implement sorting yourself by overriding the ApplySortCore,
RemoveSortCore and SupportsSorting Core methods. *yuck!*
One class that seems to provide a complete implementation of the
IBindingList interface is System.Data.Dat aView. Unfortunately (again),
DataViews can only deal with DataTables, not with List(of), Arrays,
etc...
Sorry for the bad news.
Regards,
Branco
PS: For quick and dirty tests, using Public fields in your class
*seems* OK. It's not. Public fields in a class are exactly that: a
public field, acessible by whomever gets a reference to an instance of
the class. It *is not* protected by underlying get_Field/set_Field
methods as you could suppose (if you were a hardcore VB6/5/4
programmer in a previous lifetime, I mean). If you later on decide --
and you should -- to change that field access to a property access,
then the interface of you class *will change* (code that relied on
accessing the field will no longer work). Not really a problem if your
class is used only inside that particular project, but a bad practice
(IM*X*HO) nonetheless (worse still if the class will be used as a
visual component)... Just a 'heads up'.