Tim, may I ask you to consider adding support for arrays of variants as another type of data in TDataType? Or at least arrays of primitive types.
It would also be great if there was an opportunity to create your own classes with the TDataSet interface, which could be used as a proxy to the data in custom formats (collections, lists, etc.), so that you can use a unified interface between controls and data. That is, make TDataSet an abstract type, and make the current TDataSet class a descendant of this abstract type (TDBDataSet or whatever).

<< Tim, may I ask you to consider adding support for arrays of variants as another type of data in TDataType? Or at least arrays of primitive types.
It would also be great if there was an opportunity to create your own classes with the TDataSet interface, which could be used as a proxy to the data in custom formats (collections, lists, etc.), so that you can use a unified interface between controls and data. That is, make TDataSet an abstract type, and make the current TDataSet class a descendant of this abstract type (TDBDataSet or whatever). >>

There are two major areas that need addressing in this regard:

1) The binding needs to be made more abstract, as you say.  This will also solve the issue of the TGrid control having two different ways of dealing with data, depending upon whether the grid is bound or not.

2) The content/control embedding needs to be made more abstract so that different content presentations (control classes) can be embedded within grids, lists, etc.

The initial EWB 3 release concentrates on solving some long-standing database/dataset issues, namely things like echoing generated/identity columns back to the client application and proper authentication handling, but I will be addressing the above two issues ASAP after the initial EWB 3 release is out.

Tim Young
Elevate Software
www.elevatesoft.com