>The more I've considered how bizobj are intimately related to their data the more I like the idea of creating properties on the bizobj representing data fields. I've started a small app to examine this idea further.
>
>I especially like how this ties in with VFP's access and assign methods. No longer will I have to place validate code in controls if I want validation right away or batch validation in a method if I want to validate all the fields before a save.
>
>There are a few items that have come up, however: How do you deal with different field types? I believe property strings can only be 255 characters long, so how do you place a memo field in the property? The same goes for a general field type.
>
>The only other problem I foresee with this is having to write the equivalent of a GetFldState function.
>

Michael,

I prefer to not use properties as it makes subclassing the bizobjs for sepcialization cleaner, in my opinion. If I use properties then I will be introducing new properties to subclasses which rubs me the wrong way when thinking about the idea that superclasses should introduce the interface and subclasses should use the interface.

It is easy enough to create control classes that can read the controlsource during their Init and remap everything to the bizobj.