complex databinding accepts as a datasource either in Ilist or IListSource

I have to populate the combobox with both text and value. The datasource is a SqlDataReader.

I have used the following code.

cboInst.DataSource = SetInstRec
cboInst.DisplayMember = "ShortName"
cboInst.ValueMember = "Register"

Where 'SetInstRec' is an instace of SqlDataReader. While running this code I am getting the following exception.

"complex databinding accepts as a datasource either in Ilist or IListSource"

Bind it with the Dataset because it implements IList interface.

thank's
but what if i want it to do with datareader.

It most probably won't work this way . Read about databinding and datasource property in MSDN . Maybe you understand why you have to bind it with Dataset !

Did you find a solution to this?
I am having the same difficulty
I do not want to use a data set but want to use the sqldatareader along with a combo box

Quote:

---

Originally Posted by mbsdb

Did you find a solution to this?
I am having the same difficulty
I do not want to use a data set but want to use the sqldatareader along with a combo box

---

You absolutely CANNOT use a DataReader, plain and simple. Your DataSource has to implement IList or IListSource and the SqlDataReader doesn't. There is absolutely no way around it. Having said that, you don't have to use a DataSet or even a DataTable. There are plenty of other classes that implement either or both of those interfaces, or you can define your own.

Another example of .NET being inflexible.

Quote:

---

Originally Posted by DNA7433

Another example of .NET being inflexible.

---

That is a really well thought out comment. How is allowing you to bind to any object that implements either of two interfaces being inflexible? In order for an object to be bound to a control the control has to know how to get at the data it contains. That's why it requires one of those interfaces: because it then has a standard set of members it can use to get at the data the object contains. The underlying structure of the object can be absolutely anything you like. You can create a type with absolutely any structure at all and as long as it implements that standard interface you can bind it to a control. How can that possibly be considered to not be flexible? You can quite easily define your own class that wraps a data reader and implements an appropriate interface. You then pass a data reader instance to the constructor of that class and then bind that object to a control. Voila. Sounds flexible to me.

Quote:

---

Originally Posted by jmcilhinney

That is a really well thought out comment. How is allowing you to bind to any object that implements either of two interfaces being inflexible? In order for an object to be bound to a control the control has to know how to get at the data it contains. That's why it requires one of those interfaces: because it then has a standard set of members it can use to get at the data the object contains. The underlying structure of the object can be absolutely anything you like. You can create a type with absolutely any structure at all and as long as it implements that standard interface you can bind it to a control. How can that possibly be considered to not be flexible? You can quite easily define your own class that wraps a data reader and implements an appropriate interface. You then pass a data reader instance to the constructor of that class and then bind that object to a control. Voila. Sounds flexible to me.

---

That was a really insightful reading of my well thought out comment. I wasn't talking about the control, I was referring to the data reader. The reader should implement IEnumerable (IList is too strong) and data-bindable controls should accept that interface. Second time the enumerator is accessed from the reader would throw an exception.

Quote:

---

Originally Posted by DNA7433

Another example of .NET being inflexible.

---

Uhmmm, Don't you mean another example of somone using the wrong tool for the wrong job? The data reader is used to obtain a "forward-only stream of rows from a SQL Server database"msdn Do you like wasting resources to bind a simple list to a control? You do understand that your sqlConnection is useless while the datareader is in an open state? If you want to bind a control to data directly from a database use a dataadapter to fill a datatable, which is still arguably poor coding practice depending on who you talk to. Any way. It is not .NET being inflexible. It is a "Control", not the framework causing the issue(for good reason). Create your own control. .net is flexable enough to let you write bad c0d.

I don't understand your point about the connection being useless while the data reader is open. You open the reader, assign it to the DataSource property of the combo box, the box loops through the items in the data reader, then the rest of your code continues executing where you close the reader and the connection. Your code wouldn't even have a chance to use the connection during all that, and it happens instantly not over the course of an hour. And how is using a reader wasting more resources than having to use a dataadapter and dataset? If all you do is open a reader, loop through the items to populate the combo box, then close the reader, what's the big deal with allowing the user to assign a reader to the DataSource property to do the same thing?

The simple fact is that .NET is not inflexible, or certainly not because of this. It allows you to define your own class that implements IList or IListSource and wraps a DataReader, instances of which you could then bind to any control. If you're not prepared to do that then it's you who is being inflexible, not the language or the platform.

So why do we have the anchor property on Windows Forms? We didn't need it before because we could write all the code ourselves, but we wanted it because it is easier.

Easier is easier, not more flexible. The Anchor property makes many situations easier but it is not flexible enough to handle the situation where you have two controls side by side and you want them each to occupy 50% of the available width. With addition of the TableLayoutPanel in .NET 2.0 you now have the flexibility to use the Anchor property within a cell and achieve that behaviour from the designer without additional code.