I hear and agree.
It seems Microsoft tried to do too much with this control when the
developed it; tried to make it work in too many circumstances. The
configurability makes it brittle.
We've spent about a year extending the datagrid to lock it down to a
consistent set of functionality, and have only recently enabled in-grid
editing scenarios. After a huge time investment we finally bent it to
our will. Thankfully we can now feel confident in using it for both
read-only and editable situations.
If you frequently need to use a datagrid, I would recommend you start
your own extended datagrid project based on the WPF toolkit (with test
scenarios for -everything-) and use that in your projects. But it's one
hell of a development cliff to climb and you may be better off designing
around having to use it.
(Buying a 3rd party grid wasn't an option for us but there may be some
good ones out there. In my entire career I've barely seen a decent
datagrid though; I'd still recommend extending the Microsoft datagrid
yourself).
Carl.
From: [email protected] [mailto:[email protected]]
On Behalf Of Greg Keogh <[email protected]>
Sent: Monday, 24 October 2011 3:41 PM
To: "'ozWPF'" <[email protected]>
Subject: DataGrid comments
So I want to commit changes on cell end edit and after an hour of
searching I find I have to do this weird code with a guard bool around
it because it's recursive.
private void gridCust_CellEditEnding(object sender,
DataGridCellEditEndingEventArgs e)
{
if (!isManualEdit)
{
isManualEdit = true;
gridCust.CommitEdit(DataGridEditingUnit.Row, true);
isManualEdit = false;
isEditing = false;
}
}
I want the Delete KeyUp to prompt delete the selected rows. However,
when I hit the Delete key in a cell in edit mode it fires my delete
prompt. So I put a guard bool 'isEditing' between Beginning Edit and
CellEditEnding events so I can manually skip Delete processing while in
cell edit mode.
I want double-clicks anywhere on a row to launch some edit processing of
the bound item. A double-click on an editable cell makes it enter edit
mode before my double-click code runs. So now a double-click is always
swallowed because I go into cell edit mode.
The WPF DataGrid is the most incomprehensible, time-wasting, frustrating
and quirk riddled control I have ever had the misfortune to encounter
since .NET was invented. These are just behavioural quirks, don't
mention the styling horrors. Last year it took me almost 3 weeks of
hobby time programming to figure out how to manually change the
background colour of cells, and then it still had a bug I found later. I
find I am continuously "fighting" the binding to get simple effects I
want that are absolutely trivial in the WinForms DataGridView control.
I've spent over an hour this afternoon trying to find a simple example
of how to validate that a column value is not null, but all the samples
are different, some have triggers, some have validators, they are all
different, dense and indigestible. My simplest demands of the DataGrid
usually result in dozens (or hundreds) of lines of cryptic binding and
converter code that I have to find in web searches and then paste and
tweak to get working.
Several times this year I have given up on using a DataGrid in WPF apps
and resorted to embedding a DataGridView in a host to get products
finished on time. I estimate that creating a moderately well-featured
grid working in WPF takes 10 to 50 times longer that it does in
WinForms. It could possibly send me broke.
No response necessary. I'm just angry and I don't have a shoulder to cry
on.
Greg
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
________________________________________________________________________
_______
This email has been scanned by the Bankwest Email Security System.
________________________________________________________________________
_______
_______________________________________________________________________________
Unencrypted electronic mail is not secure and may not be authentic.
If you have any doubts as to the contents please telephone to confirm.
This electronic transmission including any attachments is intended only
for those to whom it is addressed. It may contain copyright material or
information that is confidential, privileged or exempt from disclosure by law.
Any claim to privilege is not waived or lost by reason of mistaken transmission
of this information. If you are not the intended recipient you must not
distribute or copy this transmission and should please notify the sender.
Your costs for doing this will be reimbursed by the sender.
We do not accept liability in connection with computer virus, data corruption,
delay, interruption, unauthorised access or unauthorised amendment.
_______________________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
_____________________________________________________________________________________________________________________
ozwpf mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
