Attn Microsoft: How to make the databindings useful...

Skip to first unread message

Martin Robins

Jan 6, 2003, 4:24:49 PM1/6/03
I have this evening been sitting and going through a decompile of the System.Windows.Forms.dll.
<sitting back while waiting for abuse to be hurled regarding intellectual property etc.>
Specifically, I have been looking at the "Data Binding" capabilities of the controls, and why they are so problematic to use with user defined objects. Imagine my horror, when I realised just how simple it could be to make this usable. The "Binding" class is what does all of the work, and this class is public too. Unfortunately, all of the methods are private or internal (with the exception of the OnFormat() and OnParse()) which means that I cannot override the existing functionality through inheritance.
There is a method,
    private void Target_Validate(object sender, CancelEventArgs e) {
        try {
        catch (Exception) {
            e.Cancel = true;
If we were able to override this method in a derived class, we could easily resolve the problems of using Data Binding the way I keep hearing people ask ...
    class NewBinding : Binding {
    // Constructors etc.
    public event CancelEventHandler DataError;
    protected override void Target_Validating(object sender, CancelEventArgs e) {
        try {
        catch (Exception ex) {
            if (DataError != null) {
                CancelEventArgs cancelEventArgs = new CancelEventArgs(ex.Message);
                DataError(sender, cancelEventArgs);
                e.Cancel = cancelEventArgs.Cancel;
                e.Cancel = true;
        // Anything else we do not like
Using this simple revision, we could use business objects that raised Exceptions when properties were set incorrectly (just the way Microsoft tell us to) and these objects would also be usable from Windows Forms without having to be drastically re-written. With a little imagination, we could also build in better support for the IDataError interface and really make some useful bindable objects.
But we cannot. Microsoft in their infinite wisdom have decreed that the class functionality is fixed as is.
Well, There is my whinge for the day. Anybody got any ideas how we could get around this? I will not start up about the changes that have taken place between versions 1.0 and 1.1 so that my existing code no longer works anyway!
Martin Robins.

Chandika Mendis

Jan 6, 2003, 11:19:58 PM1/6/03
We have built some tools and infrastructure components in-house to overcome the problems and limitations with ADO.NET and data binding.
No DB Independance (handling of Auntonum keys etc.),
Synching to database is non-trivial for complex multi-table transactions.
Dataset definitions need to be standardized where possible rather than promoting adhoc creation of datasets for each feature.
Fill operations should be simplified, parameterized, reusable and extensible.
Default optimistic concurrency mechanism is very inefficient (better to use a single timestamp or version field)
A standardized transaction handling mechanism is needed that doesn't put the burden on the developer
Our answer to the above problems is a DataSetHelper class that encapsulates a dataset and provides generic functionality (a single updateDB method, efficient optimistic concurrency mechanism provided internally, a generic parameterized fill method etc.). For a particular concept we would define a common (shared) dataset and a corresponding DataSet Helper class.
ADO.NET dataset classes cannot be conveniently extended to provide business logic functionality.
Our answer to the above problem is an in-house rules-engine that allows us to implement independant expression, validation, aggregation and editability rules that get fired automatically when the dataset is modified. The datasethelper binds the relevant rules-engine based on the dataset context so that regardless of who uses the dataset a consistant set of rules will be fired.
Curious to know if anyone else has similar experiences??
"Martin Robins" <> wrote in message news:ebT1LnctCHA.2332@TK2MSFTNGP12...
Reply all
Reply to author
0 new messages