Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

UI controls require DataSets?

I've been reviewing UI controls, Infragistics and Janus mostly, for use in a WinForms app and was surprised to find that both want you to bind a DataSet to the control.  As far as I can tell there is no way to manually populate the UI control with data.

My preference "was" to use DataReaders for retrieval.  In the ADO/COM world I'd just get a RecordSet, then read the data into the UI control.  This worked well where I needed to do special formatting because looping through each record in code gave me complete control over the display output in the control.

Are bound DataSets now the "preferred" way of getting data to the UI?

If not, can anyone recommend alternate, professional-looking UI controls (grids, calendars, etc.)?


Joe Paradise
Monday, June 2, 2003

Any data-bound control should also support any collection. Have you tried binding a collection?

Brad Wilson (
Monday, June 2, 2003

Clarification... by "UI control" I mean their respective grid controls:  Janus GridEX and Infragistics UltraWinGrid. 

Basically, I'm looking for a grid that supports:
- unbound, manual row creation/addition
- Outlook-style grouping and sorting
- cell merging (like the MS FlexGrid)

Joe Paradise
Monday, June 2, 2003


To make a long story short, I'd like to reproduce in VS.NET a custom grid layout I originally made in VB6 using the MS FlexGrid.  The customer loves the layout, but asked if I could include the Outlook-style grouping to ease navigation.

The problem is that one row in the grid layout does not correspond to one record in the database.  So binding of any kind won't work.

I can post a screenshot of the layout if that would help.

Joe Paradise
Monday, June 2, 2003

If I were you I'd just go ahead and use DataSets. They do seem to be the "preferred" way. Using DataRelations you can massage the data into various hierarchies and I guess the controls you're looking at will represent that visually.

A possible benefit is that if the controls are configured to allow updates you can grab the diffs in the dataset and send the changes back to the backend.

It gets a little more complicated if you're dealing with humungous amouts of data -- but I would hope any controls expose enough sensible events so that I can lazy load parts of DataSet on demand (bear in mind that DataSets and DataTables etc have a quite a rich event model).

Duncan Smart
Tuesday, June 3, 2003

You do realize you can build an entire DataSet and all its contents in code, right? So instead of manually inserting data into the grid, you can manually insert the data into its proper position into an underlying DataSet.

Mike Gunderloy
Tuesday, June 3, 2003

Mike, that's an excellent idea.  I knew you could do that, but never thought about using that technique in this case.

My prejudice against data binding was really blinding me to other solutions.  Building a DataSet in code will do exactly what I need.  Thanks for all your replies!

Joe Paradise
Tuesday, June 3, 2003

Here is an interesting article comparing the performance of datasets vs custom classes.{31716324-E8E6-4B68-AC13-66C225EAB39E}/st~{9508C006-DD59-4F5D-8316-0AFDB0EA806C}/session_id~{A17AE8BB-AAC9-456A-B3B2-9F7A289094F7}/content/articlex.asp

Jason Watts
Tuesday, June 3, 2003

It's my understanding that DataReaders aren't allowed to be bound to most controls because they aren't updateable, don't provide some of the necessary components for the data controls to work, and are built for speed - not functionality.

The fun thing I encountered was that changing from a DataReader to a DataSet was surprisingly easy.  It was almost as easy as switching from using ODBC to read a CSV text file to using Jet.  (Tip:  don't use ODBC to read a CSV file if the first column doesn't have header information.  The ODBC .NET driver seems to ignore the HDR=No directive; you have to use the Microsoft Text Driver in the OleDb space..)

Brian Schkerke
Tuesday, June 3, 2003

Jason: Thanks for the link. After about one year of development of the first half of our product, we have decided to abandon datasets altogether for the second half and go with custom classes. (Luckily, the two halves are pretty segmented, so there won't be too much ovelap between the old and new approach.)

We're still in the infancy of the second half of our development process, but we're feeling better and better about being able to apply a more object-oriented approach to our development process because of the ability to easily encapsulate complex behavior with the data. This is especially important for us because each of our domain objects are pretty sophisticated, and fit very nicely into an OO paradigm.

I summarized our experience in this thread on the main board:

Monday, June 9, 2003

*  Recent Topics

*  Fog Creek Home