Hi, Mike.

>I hear you, but look at VFP's help under naming conventions. It says "suggested for objects" but then in the chart header, it says Object, when according to you it should have said "Class". Further, if you subclass a TextBox to use for your own purpose, what will you name the class in the VCX? TextBoxDate? DateTextBox? Why not txtDate?

In my case, I use a personal (ego-driven) prefix using my initials. Then the base subclasses become: msTextbox, msCombobox, etc.

For further subclasses I add a clue about its functionality, like: msDateTextbox, msStateCombobox, etc.

As for business objects, I use the following convention (which has to do with how do I separate tiers):

TierAdpater                  -> the mother of all my tier classes
  |
  +--> DataTierAdapter
  +--> BusinessTierAdapter
  +--> UserTierAdapter

This make up for the basic of my framework. In each application, I start using three basic subclasses which act as a stub for any generic functionality I need for this particular app:

  DataTierAdapter      -> doGeneral
  BusinessTierAdapter  -> boGeneral
  UserTierAdapter      -> uoGeneral

From them, I subclass any subsequent object using this two-letter prefix, like:

doCustomer -> data tier
boCustomer -> biz tier
uoCustomer -> user tier

You can see this has to do with my own framework ( you can take a look at it at www.salias.com.ar/TierAdapter and there is even a diagram showing all this there ), but you can also see the logic behind it.

Hope this helps,