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.
"William Ryan" <do********@nospam.comcast.net> wrote in message
news:uR**************@TK2MSFTNGP09.phx.gbl...
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
"Fred Morrison" <fm*******@erols.com> wrote in message
news:OY**************@TK2MSFTNGP11.phx.gbl... 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?
