Windows Form Gird control - defficiences

  • Thread starter Thread starter Fred Morrison
  • Start date Start date
F

Fred Morrison

1. No Columns collection.
2. No ability to easily synchronize the underlying DataTable of a DataGrid
when a row is deleted in the Grid. Once you sort (via the column headers)
all bets are off as to whether the current row index of the data grid can be
used directly as the Rows index of the DataTable. This is documented in the
DataGrid Overview.
3. No way to access the default grid table style to make minor changes to
just one column (i.e., hide it or make it's width property zero). Not even
for read-only purposes (see #1).
4. No way to easily pick up the value of a hidden column in the Grid (which
has to be hidden using Data Layer techniques, not Presentation Layer
techniques). You have to make some ASSumption about the relationship of
grid columns to DataTable columns or use some nasty hard-coding that begs
for future maintenance errors.
5. If you want to delete a row from the data grid in your Presentation
Layer, you can't directly use the DeleteRow method of the grid (see #2
above) without going into the Data Layer to FindRows the corresponding row
in the datatable. Kind of kills the idea of separation of Presentation
Layer, Business Layer and Data Layers if the Presentation Layer has to know
how to reach into a DataTable in order to know how to delete a row in a
Presentation Layer control (grid).

Is there a 3rd-party Grid control that does not suffer from these
deficiencies?
 
A few observations...

1)Since the datagrid control is meant to be bound to a datasource, you have
a DataTable which does have a columns collection and is very straightforward
to access

2) Why is that a problem? You can access the data directly regardless of
where it is and the changes will be reflected in the underlying datasource.
3) This is a bit of a pain, but it's quite easy to write class to handle
this for you...here's one example but there are many more out there and once
you create this class, it's cake to manipulate it.
http://www.knowdotnet.com/articles/cgrid.html Moroever, you can create your
own component and adding designer support is quite easy in .NET
4) Agreed
5) If it's bound, I don't see what the problem is in getting this data.
The RowState will be marked accordingly if you delete it, so you can still
seperate your logic from presentation without a problem.

I have some examples I can send you if you are interested.

HTH,

Bill
 
small remark on point 3

you can hide a column without using the styles...
myTable.Columns(colIdx).ColumnMapping = MappingType.Hidden
 
1) Only works if the ordinal positions of the columns in the grid exactly
match the ordinal position of the columns in the DataTable.
2) The problem is obvious: the row index of the grid cannot reliably be used
directly to manipulate (e.g., DELETE) the corresponding row in the
DataTable. If you delete a row in a grid that has been sorted, the wrong
record in the underlying DataTable gets deleted in the database. This is
clearly documented in the online help and is, in my opinion, an admission by
Microsoft that they didn't do a good job of making their windows forms
(don't know about the ASP version) grid intuitive. Instead, you have to use
"tricks" to get around the deficiency.
3) The hyperlink you posted does not work. Is there a better one I can look
at?
5) The presentation layer should never (repeat NEVER) have to know how to
figure out the primary keys of the underlying DataTable in order to make
sure the proper row in the database gets deleted (see Microsoft's admission
of this deficiency in their online help). That belongs in the Data Layer,
not the Presentation Layer. Why have three layers if the presentation layer
has to know data-specific information (like the Primary Key constraint) of
the data bound to a grid control? If Microsoft wants to simplify our lives,
don't implement something with such an glaring flaw.
 
Yes, you can. And as soon as you do that, you can no longer access that
column's value in the Grid to pass back to the data layer in order to have
it use a FindRows method to locate the corresponding row in the underlying
DataTable to DELETE. Best alternative: set the column's width to zero, but
that means creating another grid table style (because you can't get at the
default one to manipulate just one column's attributes - another strange
restriction that Microsoft freely admits too in its online Help).
 
access that column's value in the Grid

uh?
just get your table and "ask him" the data for that column...
 
Read the table? That's the problem! Why should my presentation layer have
to know anything about how the data go into the grid, be it hand-populated
or via a table? And if the grid is populated by a table, why can't it keep
track of the data, even after the user clicks on one of the column headers?
(That last one is really strange, but at least Microsoft freely admits their
failure in their online help for the Windows data grid control). Is the
web version of the grid control just as bad as the windows form data grid
control? My applications all use windows forms, so I can only tell you my
experiences with the windows data grid control.
 
Back
Top