>Thinking of the "consistency of look and feel" and the "objects can be reused to save much coding" I figured I could make a Container class with just the relevant fields displayed just-so and use that in the 6 different places noted above.

Good move, the right approach IMO.

>However, I am stymied when it comes to the data in the fields - HOW, in a single such class, do I control where the data comes from and where it goes to??? As far as I can discern, only a form (or report) can have a DataEnvironment, and furthermore in at least one of the cases the source/destination fields would be different than in the other 5 instances.

So, you haven't normalised the data into a table of addresses related by Primary Key to the actual customers etc that they refer to.

In that case, your Address Class will require extra properties to link it to the tables and fields that it shoudl be using.


>So far I have concluded (hopefully ERRONEOUSLY) that one cannot use OOP for such savings, and that I actually have to code each one individually.

Your container could have all the controls UNbound initially.
The container can then have a DataSource property that specifies the table that should be used.

Then in a ConnectToData method
If the table's not open, then open it.
Set the ControlSource properties of all the contained controls to the right fields form the table.
Refresh to show the data.

Of course you'll want code to close the table if you opened it when you destroy the container (guess which method that goes in <g>).


I've done this where I had multiple repeating fields and wanted to reuse a container to show different fields.
In my case Car1Svc, Car1Make and Car2Svc, Car2Make.
The data structure was defined by the customer and is not subject to discussion, this denormalisation meant I had to invent a way around the problem.

I just populated the appropriate control sources with Car1Svc or Car2Svc etc, depending on the value of a CarNumber property.

Works beautifully!