Problem Binding a Dataset to a ComboBox

[Russ]

I have a subroutine that I call to bind a dataset to a combobox. It
works sometimes. See the code below..

1 Private Sub BindDropDownToDataSet( _
2 ByRef control As System.Windows.Forms.ComboBox, _
3 ByVal ds As DataSet)
4 Try
5 control.DataSource = ds.Tables(0)
6 control.ValueMember = ds.Tables(0).Columns(0).ColumnName
7 control.DisplayMember =
ds.Tables(0).Columns(1).ColumnName
8 Catch e As Exception
9 MsgBox(e.Message)
10 End Try
11 End Sub

Code to call my sub is ...

BindDropDownToDataSet(ComboBox1, Dataset1)
BindDropDownToDataSet(ComboBox2, Dataset2) <-- fails on this call



The problem is that one time it will work just fine. Then I call it
to fill another combobox and it fails on line 6 with the error ...

"Cast from type 'DataRowView' to type 'String' is not valid."

What is really weird is that while debugging, after it executes line 6
it goes to the catch. Then if I "Set the Next Statement" to line 6,
it works just fine.

 

[Cor]

Hi Russ,

I do not see it,
However

1 Private Sub BindDropDownToDataSet( _
2 ByRef control As System.Windows.Forms.ComboBox, _
3 ByVal ds As DataSet)

Why byRef a control can done byval because it is a reference so a ByVal is
normal Byref gives extra code

4 Try

Why a try, if it works onces it works for ever, there are no external
influences
(Or is this only for testing?)

5 control.DataSource = ds.Tables(0)
6 control.ValueMember = ds.Tables(0).Columns(0).ColumnName
7 control.DisplayMember =
ds.Tables(0).Columns(1).ColumnName
8 Catch e As Exception
9 MsgBox(e.Message)
10 End Try
11 End Sub

Code to call my sub is ...

BindDropDownToDataSet(ComboBox1, Dataset1)
BindDropDownToDataSet(ComboBox2, Dataset2) <-- fails on this call

For me the most probably it that the Select from the dataset2 contains only
one element.
(However if not I think there is something with the creation of the dataset)

So when you do not find it, send the code how you create that dataset2

The problem is that one time it will work just fine. Then I call it
to fill another combobox and it fails on line 6 with the error ...

"Cast from type 'DataRowView' to type 'String' is not valid."

What is really weird is that while debugging, after it executes line 6
it goes to the catch. Then if I "Set the Next Statement" to line 6,
it works just fine.

I hope this helps?

Cor

 

[Russ]

Hello Cor,

I solved the problem, but I am not sure why.

I had a subroutine

Private Sub ComboBox2_SelectedIndexChanged(ByVal sender As
System.Object, ByVal e As System.EventArgs) Handles
ComboBox2.SelectedIndexChanged

. . . code goes here
End Sub

I changed it to

Private Sub ComboBox2_SelectionChangeCommitted(ByVal sender As Object,
ByVal e As System.EventArgs) Handles
ComboBox2.SelectionChangeCommitted

. . . code goes here
End Sub

Now everything is working.

Any Ideas of why "SelectedIndexChanged" would cause
control.ValueMember to fail, yet "SelectionChangeCommitted" would not?

Hi Russ,

I do not see it,
However

Why byRef a control can done byval because it is a reference so a ByVal is
normal Byref gives extra code

I changed it to byVal, it made no difference.

Why a try, if it works onces it works for ever, there are no external
influences
(Or is this only for testing?)


For me the most probably it that the Select from the dataset2 contains only
one element.
(However if not I think there is something with the creation of the dataset)

So when you do not find it, send the code how you create that dataset2

The dataset is fine. It even fails if I use the same dataset.
i.e.
BindDropDownToDataSet(ComboBox1, Dataset1)
BindDropDownToDataSet(ComboBox2, Dataset1) <-- fails on this call

 

[Cor]

Hi Russ,

No,

However the selectedindexchanged event fires also when it is initializing
and then there happens sometimes things I also do not understand. If I use
it I always protect it for firing with a bool/switch/flaw whatever you name
it.

Check very good if the SelectionChangeCommitted is good working for you.
I thought that if you bind the displaymember and the valuemember there where
no problems, but I check that always 10 times. (There where situations that
it did give with me the previous valuemember).

Cor