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.

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...

Reflection

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.

Inheritance

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.

Tutorials

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...

Fighting the effects of blogrot...

Ok, I have to admit, I love blogging, but I'm terrible at it. Blogging's like this idea that promises to be life-changing in one way or another that one attacks with enthusiasm, only to find that, about three posts later, either the creative juices have dried up, or the opportunity to express oneself isn't worth the effort it takes to put up a post.

Such as it is, I'm renewing my commitment to blog regularly. I say this while thinking of all the blogs I've wandered across in my time which start out similarly only to have three posts following, and all of them no less than three or four years old...

But in this case, I've got a reason: The VBA Composite Control project I started (see link at left).

I don't know why I started this project. I don't really presume to be able to make it something great. The fact that it's written in VBA is pretty self-limiting. But I get a kick out of this sort of stuff and I really want to make as much of it as I can - if for no other reason than because I enjoy doing so.

So I plan on using this blog to post about what I've got in mind for the project and other related subject matter.

My only hope is that someone may care enough to contribute.

In the interim, I've got lots of plans for the project. I don't plan on releasing another update soon, but I do want to finish out the tutorials (they're getting there) and start developing a data source object model to provide data management to the object model. I'm also playing with techniques to bring more advanced OOP concepts into VBA that aren't natively supported (like reflection and inheritance). In fact, I've written a couple CodeProject articles about it, one on the Object Model, and the other on Reflection in VBA.

In the meantime, if you read this and you've messed around with the object model, and you have thoughts / comments / questions...

I'm dying to hear them.

VBA Composite Control Object Model

When I turned 16 and got my license, I took to the road in a 1988 Buick Somerset. It was a nice car, I’ll admit. But it wasn’t as cool as my friend’s beat-up 1984 Monte Carlo.

Not that I disliked my Somerset, but it’s just not cool to drive a car named after a retirement village in Florida when you’re in high school. In all honesty, I’d have traded my nice Somerset for my friend’s Monte with its dents, torn seats, dash cracks, stained carpets, and odd smells in a second. Why? Because when you grow up in a village of 200 (196 people, 4 llamas) surrounded by acres of cornfield, you make your own fun. And an old beater of a car was especially fun because such a vehicle was perfect for making “enhancements”.

Case in point, my friend made one such enhancement by tearing apart his fuzz-buster, burying the sensor in the dash behind the windshield, and tying the output to the seatbelt light. Not only was this a smart move (radar detectors were greatly frowned upon by the local law enforcement), but it was a lot of fun watching his seatbelt light go berserk every time we passed a cop on the road. Not surprisingly, my friend went on to co-found a company that specialized in reprogramming your average four-door grocery getter to humiliate a stock Camaro off-the-line. He’s done things with cars we couldn’t have dreamt of then.

So what’s this got to do with VBA?

Only that I have learned that some of the most useful and valuable things I own are things that I’ve repurposed. That’s why I love VBA. I’ve used it to find unique ways to solve problems, work around software limitations, and otherwise get Microsoft Office to do things that I very much suspect it’s not supposed to do. In short, VBA is how I repurpose Office, particularly Access.

For example, I recently had a post on the Microsoft Access Team Blog on creating dynamic callbacks for controls. That code opened up some possibilities with VBA that I’d never explored. So, I tinkered a bit.

What I came up with is the Composite Control Object Model. Briefly, it’s a way of managing event driven interactions between controls and forms or any other object that can exist in VBA. So far, I’ve used it to create custom visual effects (like the WebButton), bind controls / forms together for easier updating, and enable a TabControl object to have a RecordSource. I think it could do other things, too - like create a javascript-style menu system, or perhaps a filmstrip-style gallery control that manages images stored in a single Attachment field.

However, I’ve reached a point where I can’t really take it much farther. That is, I don’t have enough uses for it to make it really useful. That’s why I’ve started a CodePlex site for it.

Anyway, download the demo. Tear it apart. Use it to repurpose a seatbelt light or two… Whatever.

Just let me know what you think.