Hey Bob

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?

>>Hi all
>>
>>All controls are inherited from VFP. Despite the fact that they are all controls, each has a recommended three-character prefix. "Txt" is
>
>I think this recommendation is for naming OBJECTS not classes. When you drop a textbox class on a form, you are actually creating an object.
>
>But, you are talking about classes, and if you follow the VFP names, you will also see that the clases don't use those prefixes.
>
>Which is why, the TextBox class is not called txtTextBox.
>
>>OK? Good. So if I subclass a custom control and turn it into a business object why should I call it cusBusinessObject?
>
>You shouldn't, cause your bizobj class is not an object. As a matter of fact, when you instantiate a bizobj class I would use a prefix... for example:
>
>boCustomer = createobj("CustomerBizObj")
>
>The above shows two names, the object with the "bo" prefix, but the class name with the "BizObj" suffix.
>
>So, using a common sufix for class names that indicates it's function seems to work best for us:
>
>

>DEFINE CLASS Base AS Custom
>ENDDEFINE
>
>DEFINE CLASS BusinessObjectBase AS Base
>ENDDEFINE
>
>DEFINE CLASS CustomerBusinessObject AS BusinessObjectBase
>ENDDEFINE
>
>*Of course, we may end up abreviating:
>
>DEFINE CLASS BizObj AS Base
>ENDDEFINE
>
>DEFINE CLASS CustomerBO AS BizObj
>ENDDEFINE
>
>*With Controls we use something like:
>
>DEFINE _TextBox AS TextBox
>ENDDEFINE
>
>DEFINE SSNTextBox AS _TextBox
>ENDDEFINE
>
>DEFINE NumericTextBox AS _TextBox
>ENDDEFINE
>

>
>HTH,
>BOb