Confused by one more piece of IBindingList

  • Thread starter Thread starter W.G. Rowland
  • Start date Start date
W

W.G. Rowland

Thanks for all the help I've been getting working on understanding
IBindingList and data binding in general.

My understanding about IBindingList is that it's primary use is for binding
custom strongly typed collections to complex controls (primarily DataGrid)..

So by grouping the parts of the interface into their various functionality
I'm coming to grips with how it works, with one exception..

Datagrid doesn't have any searching ability AFAIK, so why does IBindingList
have functionality for searches? I know that it's optional, and doesn't
have to be implemented.. But every other piece of the interface maps to a
piece of the puzzle needed for the grid to be able to handle adding,
removing, editing rows of data, sorting them, and so on.

So is the search functionality actually used? And if so where?

I hope I'm not just being obtuse.. I'm just trying to make sure I don't
dismiss that section of the interface and then later find out it's used
internally by something else, and I've hosed things by not implementing it..

Thanks in advance (again)
William Rowland
 
W.G. Rowland said:
Datagrid doesn't have any searching ability AFAIK, so why does
IBindingList have functionality for searches? I know that it's
optional, and doesn't have to be implemented.. But every other piece of
the interface maps to a piece of the puzzle needed for the grid to be
able to handle adding, removing, editing rows of data, sorting them, and
so on.

So is the search functionality actually used? And if so where?

I hope I'm not just being obtuse.. I'm just trying to make sure I don't
dismiss that section of the interface and then later find out it's used
internally by something else, and I've hosed things by not implementing
it..

Searching is not used in the ms' datagrid but you can imagine it
might be useful in a grid where the user can select a row or rows based on
a filter set. Then you need a search feature.

Frankly I don't see the usefulness of this, since it is the job of
the grid, not the underlying datastructure to control the view. However
the design of the datagrid seems to be that it delegates all kinds of
functionality to the datastructure itself (like sorting, but what should
happen when the user wants to sort on 2 columns? The interface is then not
usable -> bad interface design, it is not generic enough, it is taylored
towards MS' own controls) while on other area's it is doing it itself
(controlling the edit cycle with events that fire at random as it seems).

With the IBindingList, you can always add implementation later, by
simply implementing the method instead of now throwing an exception. But I
haven't run into a situation where I needed the searching method of
IBindingList.

FB
 
Thank you, Frans..

This is what I was thinking, but I wasn't sure.. I know I can choose when
and if to implement features.. The only snag with this is I'm learning as I
go. I'd originally intended to use CSLA (Rockford Lhotka's Business Object
framework) for my goals. I read through the book that explains the
framework taking in concepts and constructs as I went.. Then when I was
done, I realized that it was such a big construct that I couldn't remember
which pieces I needed to implement and which I could discard (as is, it's
overkill for the simple app I'm trying to build)..

As for the wisdom in MS's control and interface layout.. I've been wondering
about that alot myself, atcually. I don't really want to build my own
business objects. It's an education, to be sure, but it's also a royal pain
in the keister. From the work I've done with ADO.Net I really like
Datasets. They're fairly easy to work with. The only reason I'm having to
build my own objects is because I want my business logic decoupled from the
UI (one of the achilles heals of the current version of this application)..
It doesn't seem like there's a straightforward way of adding proper
validation logic to the dataset.. So I'm stuck building my own, and having
to rebuild a lot of functionality I was perfectly happy letting the
framework handle in the first place..

If I'm not mistaken about the dataset, and its forcing the programmer to
keep validation too near the user interface (or completely in the back end,
meaning a user wouldn't find out they'd made an entry error until after
they'd submitted the form), then it seems like Microsoft made a pretty major
blunder in their design to begin with..

Of course, I'm just learning, so more likely the blundering is my own..
Which is why I keep asking all the questions..

Thanks again,
William Rowland
 
W.G. Rowland said:
If I'm not mistaken about the dataset, and its forcing the programmer to
keep validation too near the user interface (or completely in the back
end, meaning a user wouldn't find out they'd made an entry error until
after they'd submitted the form), then it seems like Microsoft made a
pretty major blunder in their design to begin with..

The dataset is a pure value object, which means that it just contains
values. Business logic can be extremely complex, it is undoable to write a
common object for that. So BL code is living outside the object where data
is stored. Validation code for field values should indeed be added to the
value holding object, but you can argue that it should be placed outside the
object, because it's a pure value object.

IBindingList is pretty complex, but the real killer is ITypedList,
which is also important for binding custom objects to complex controls.
ITypedList is the most horrible interface to implement in the complete
framework. There are some examples on the net, but not that frequent, and it
will take a lot of time to get it right.

FB
 
Am I going to need to learn it as well?

Here's the scenario I'm working with (simplified, so as not to bore
everyone):

Single user database tracking a storage rental business..

An Account consists of:
A Customer record
- 1 or more linked Lease records
- each lease has one linked Unit record
- each lease also has many linked transaction records..

There's more to it, of course, but that's the core..

To model that I was building simple business object classes for each record
type, collection classes to hold the data objects, and then an account
object which would hold related collections of data (as above) for a single
customer..

I also planned on making a simple, read only report object for returning
non-editable views of data, but the Account object would be the only way to
actually alter or add information..

Now, what I want as far as databinding is concerned it to be able to edit
records through simple data binding only (i.e. through custom forms where a
single column value is bound to a single control).. But not editable in
grids... (I know inline editing in datagrids is cool and chic and all, but
it's also not terribly intuitive for the computer illiterate, which is half
the people who will be doing data entry into this program)..

So in other words, I might have an information screen that has User info in
text boxes.. Maybe a combo box with the various leases that customer has..
And a read only datagrid that needs to show all the transactions for the
particular lease selected in the combo box..

I understand enough to build the objects and collections to make up the
Account object.. What I'm not sure is which interfaces I will have to
implement to make this scenario work..

Obviously no one here has the time to hold my hand through the whole
process, but if someone could clue me in to what I need to be researching
it'd be a big help.

At this point I have collections that will bind to grids and update
automatically if I make changes to the date in code.. Which is what I want.
What I'm struggling with is how to build the Account class, so that, if a
user changes focus from, say, one lease to another, the windows form
automatically updates controls to be showing the correct tables (so, for
example, the grid showing transactions is always showing transactions for
the correct lease)..?

I hope that made sense, if not.. Ignore at your leisure..

Thanks, as always, in advance
William Rowland
 
Yeah, I think you're right.. I guess what I'm trying to figure out is how
you get custom objects to do during data binding what datasets do via
relationships... There's a couple more layers to it in my app, but I'm
basically looking to do a simple master/detail relationship with custom
objects using databinding..

I'll see if I can't find that solar system example..
 
ITypedList would allow you to change the
properties/columns of your list at run time, I don't
think you need it. Let me make sure I understand what
you want. When a user switches between leases in a
customer record (as opposed to choosing a different lease
on another customer) you need a control to change which
list of transactions its displaying. If that's the case,
I would look at complex data binding. I think I remember
an example in the VS documentation that used an analogy
to the solar system to illustrate complex data binding,
that might help.

You need ITypedList when you want to make columns read-only for
example, without relying on the control the stuff is binded to.

Binding anything to a grid IS complex binding, however Microsoft
hasn't supplied any documentation worth mentioning about ITypedList. For
example the retrieval of nested property descriptors is hard to do when
you just look at the reference manual documentation (because you only need
to check out the last type in the list of passed in types, not a single
line of documentation is spend on that).

To create a complete object that is bindable to all kinds of
controls I sincerely would advice to implement ITypedList.

FB
 
Back
Top