Hi again, UTers!

After my last post on relative referencing, I wanted to post a related topic: The compound class. What's that? Simple, it's a container class containing of one or more other classes. What's it to you? Your best friend in RAD in a lot of cases.

Here's an example: Addresses tend to be the same in format regardless of table within the same application. 2-3 address lines, city, state, zip. Right?

What a lot of developers will do is put textboxes for the address lines, city, and zip and, maybe, a combobox for state on each form. Over and over. What's different from form to form. Almost nothing. Probably the ControlSource for each.

But if you define an invisible container with these same controls as a compound class, each time you need an address in a form, you drop the container in the form. No mess, no fuss and the only thing you have to twiddle with are the controlsources....and maybe the rowsource for the state combobox.

Like the old TV ads, "But wait, there's more!". You could always add properties to the container and use those properties as the ControlSource for the contained controls. What about binding to data? Well, with VFP6+, _Assign events on the container custom properties that the controls are bound to with REPLACE statements handles that problem.

And if you really want to go over the top, you can always further normalize your data and make addresses a separate table, linked through foreign keys to the source table and record. Then, you can hard-wire the controlsource for each control in the class, as the data source table won't be changing.

Compound class are fun and useful. And just not that hard to implement if you think ahead!