Data binding can only validate the formatting of textual input, it can't
do any other kind of validation.
In the case of binding to properties of objects (as opposed to binding
to fields of a database record, for example), a property's setter must
usually validate the value it is given in any case, regardless of whether
the value is being set by data binding, or by other consumer code.
The point here is that it is counter-productive to couple code that
does validation, to specific controls, namely because there are many
scenarios where one might want to present data in different ways,
like for example, you may want to offer the user a 'form view' or you
may want to offer them a 'tablular' view where the values appear in a
single row of a DataGridView, or you may want to present the values
in a property grid.
If the validation code is placed in handlers of control events on
a form, then how can one easily reuse that code to do the same
validation when the same data is presented in a data grid row, or
in a property grid?
So, that's the problem with Ken's approach.
You can't easily change how you present data, and/or present it in
multiple or different ways, if you couple the validation code directly
to the user interface or to user interface controls.
Just to take the heat out of this .. or redirect it ;
It's my understanding that the databinding of a control enforces the type conformance.
.. and that any other validation ( usually based on business rules) should be done via a specific callback.