How to create a class I can bind a list (or other control which works with collections) to

B

bz

Hi,

I create a class that retrieves a number of records from database.
Internally, the class store the returned data in a datatable /
datareader. I would like to bind a listbox to that class (to the
records from this datatable), using data binding wizard and to be able
to select bind to object
How should I make this class to be able to accomplish this? Do I have
to define it to implement some interface? Which one? I want to bind
DisplayMember to a certain field from the datatable

Thank you
 
M

Marc Gravell

Internally, the class store the returned data in a datatable /
datareader.
Note that data-readers are generally firehose (one-way) iterators, so
don't really "store" anything. Almost any binding work will involve
reading over the data many times, so datareader probably won't work.
Of course, if you are considering DataTable under the covers, why not
just use DataTable all the way? It will support everything you need
and more. What is your wrapper providing?
You can implement ITypedList in your collection class.
For completeness: for runtime binding, ITypedList is generally
overkill. The binding code checks for a range of things, but in most
cases simply implementing IList and providing a typed indexer
(SomeType this[int index]) is enough; the standard binding code will
assume that this is a list of items, typed by the indexer (i.e.
SomeType). This means that in 2.0, List<T> will do everything you
need. If you want better support for property notification,
BindingList<T> will do what you need.

As for design-time (IDE) binding - your guess is as good as mine! Due
to the instability in the IDE (and too many lost bindings) I gave up
on design-time bindings a long time ago.

Marc
 
B

bz

Note that data-readers are generally firehose (one-way) iterators, so
don't really "store" anything. Almost any binding work will involve
reading over the data many times, so datareader probably won't work.
Of course, if you are considering DataTable under the covers, why not
just use DataTable all the way? It will support everything you need
and more. What is your wrapper providing?

My class looks like this:

class MyCollection
{
protected DataTable prvMyTable;

public MyCollection(string SomeCriteria)
{ // here I use SQLHelper to run a sql or stored proc which
returns a dataset
myDS = SQLHelper(....)
prvMyTable = myDS.Tables[0];
}
// then I expose the prv through a property
public DataTable Objects {
get {
Check.Ensure(prvMyTable != null, "Objects collection
was not retrieved ", new ArgumentNullException("prvMyTable"));
return prvMyTable;
}
}

And I access the fields through Columns collection

How should I implement IList? I saw DataTable implements
IListCollection interface.
Should I implement this interface in my wrapper? If so, how, since I
tried, but it seems DataTable does not have the GetList method, which
is required for IListCollection interface.

Thanks






You can implement ITypedList in your collection class.

For completeness: for runtime binding, ITypedList is generally
overkill. The binding code checks for a range of things, but in most
cases simply implementing IList and providing a typed indexer
(SomeType this[int index]) is enough; the standard binding code will
assume that this is a list of items, typed by the indexer (i.e.
SomeType). This means that in 2.0, List<T> will do everything you
need. If you want better support for property notification,
BindingList<T> will do what you need.

As for design-time (IDE) binding - your guess is as good as mine! Due
to the instability in the IDE (and too many lost bindings) I gave up
on design-time bindings a long time ago.

Marc
 
M

Marc Gravell

How should I implement IList? I saw DataTable implements
IListCollection interface.
Again - why not just work with DataTable (or DataView) directly? I'm
not sure what your wrapper is helping with... but to answer your
specific question, in this case, IListSource is the interface to
implement (which acts as an intermediary to IList) - which mimics
DataTable's behavior:

class MyCollection : IListSource {
bool IListSource.ContainsListCollection {
get {return ((IListSource)Objects).ContainsListCollection;}
}
IList IListSource.GetList() {
return ((IListSource)Objects).GetList();
}
...

Marc
 
S

Sheng Jiang[MVP]

jut use DataTable.DefaultView or create another view if you want. DataView
implements a wide range of data binding interfaces.

--
Sheng Jiang
Microsoft MVP in VC++
bz said:
Note that data-readers are generally firehose (one-way) iterators, so
don't really "store" anything. Almost any binding work will involve
reading over the data many times, so datareader probably won't work.
Of course, if you are considering DataTable under the covers, why not
just use DataTable all the way? It will support everything you need
and more. What is your wrapper providing?

My class looks like this:

class MyCollection
{
protected DataTable prvMyTable;

public MyCollection(string SomeCriteria)
{ // here I use SQLHelper to run a sql or stored proc which
returns a dataset
myDS = SQLHelper(....)
prvMyTable = myDS.Tables[0];
}
// then I expose the prv through a property
public DataTable Objects {
get {
Check.Ensure(prvMyTable != null, "Objects collection
was not retrieved ", new ArgumentNullException("prvMyTable"));
return prvMyTable;
}
}

And I access the fields through Columns collection

How should I implement IList? I saw DataTable implements
IListCollection interface.
Should I implement this interface in my wrapper? If so, how, since I
tried, but it seems DataTable does not have the GetList method, which
is required for IListCollection interface.

Thanks






You can implement ITypedList in your collection class.

For completeness: for runtime binding, ITypedList is generally
overkill. The binding code checks for a range of things, but in most
cases simply implementing IList and providing a typed indexer
(SomeType this[int index]) is enough; the standard binding code will
assume that this is a list of items, typed by the indexer (i.e.
SomeType). This means that in 2.0, List<T> will do everything you
need. If you want better support for property notification,
BindingList<T> will do what you need.

As for design-time (IDE) binding - your guess is as good as mine! Due
to the instability in the IDE (and too many lost bindings) I gave up
on design-time bindings a long time ago.

Marc
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top