Sunday, March 20, 2011

cDataSource object model

Recently I've begun re-implementing the cControl_Binder / cControlChild_Binding classes (under the moniker cControl_DataSource.

My initial thoughts about the implementation:

  • The DataSource object should be a separate control which maintains an active "data source" (thus far, a DAO.Recordset).

  • The DataSource is manipulated by it's bindings. The data source itself does little more than maintain a SQL query used to generate the recordset.

  • Bindings may be "parameter" or "field" bindings. Parameter bindings have a source control value which, after it updates, causes the binding to write the value to the appropriate QueryDef Parameter object. Field bindings are identical to parameter bindings, except they update a recordset field rather than a querydef parameter.

  • The bindings have a delegate function that is assigned to the source control's AfterUpdate event. This delegate function writes the control's value to the target parameter / field.

  • The data source itself has a delegate function which handles the requery. This function is assigned to each binding source control's AfterUpdate event. The source control's requrey delegate callback must follow all binding delegate callbacks. In the case of the parameter binding, the data source must execute a requery (build a new recordset). In the case of a field binding, the data source need only refresh .

  • The cDataSource control class works with iDataSourceControl objects. This interface supplies a Value property, an AfterUpdate cControlChild_Event object, among others.

  • The requirements of the cDataSource control class suggest it would be better to combine the cControl_EventHandler class into the cControl class. Don't know if that's the route I want to go just yet.

Anyway, that's about where I'm at. This implementation is proving to be more robust and flexible than the cControl_Binder implementation in Alpha 0.

Friday, March 4, 2011

Planned improvements to the Composite Control OM

Ok, so here's a list of things I'd like to do to improve the object model. I don't expect to make any releases soon, but I'm always interested in seeing just how much more I can squeeze out of VBA...


Basically, the ability to instance a class without knowing the class type at design time. In the end, you can't really do this in VBA, but I've figured out a fairly elegant and not too hackish workaround. See the CodeProject link at left for more info. Anyway, using reflection I can:
  • Get rid of the cControlType enumeration altogether
  • Get rid of the GetHandler function altogether
  • Remove any need to change the OM's core files every time a control is added / removed from a project
  • Remove the Globals support module from the core.


I've figured out how to do inheritance that gives me polymorphism and lets me reuse code at the base level. The idea works well enough, and I've got it set up so a class can inherit properties of a base class without having to code those properties into the derived class. Working on a way of doing the same thing with methods, so that the base method is available in a derived class, and can be overridden. The big advantage is cutting out a *lot* of code from my classes, though it may require me to add a few classes to get it done. More later...

Data Source

Since I removed the cControl_Binder class from the object model in the Beta 0.1 release, I've been thinking about how to add it back. Basically, I've conceived of a cDataSoruce object which maintains a data source (a DAO or ADO recordset, a collection, array, hashtable, etc.) which becomes a member of the control class that needs a data source. The data source is then manipulated by bindings. The bindings serve both to filter the data source (e.g., tie the data source to a control which acts as a filter), and update the data source (e.g., allow fields in the data source to be changed). Since I'm envisioning possibly managing more than just DAO.Recordsets, this means a separate binding class for each type of data source - DAO, ADO, Collection, Array, HashTable, Dictionary, etc.


I'm almost done with the tutorials I've posted thus far. I'd like to post more, but I don't know what I ought to do. Comments are welcome.

Composite Controls

Here's the one thing I wish I had more of. I don't really have time to develop controls right now, especially since I'm focused on getting the object model to a stable, "v1.0" release. I keep hoping someone else might have a contribution to make...