Hey Bob

I think you're missing the little point I'm trying to make. On the chart I mentioned, there are three columns. The second column is headed with "Object", but the column contains super classes for the objects, not object names.

I don't see why the classes and the objects must have so different a naming convention.

>>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".
>
>No, I think that's just what I said, those prefixes are for OBJECTS, which are instances of clasess. You are asking about Class names. VFP doesn't have any recomendations for "Class Naming".. The doc has:
>
>

>In This Section
>
>Constant Naming Conventions
>   Provides a suggested format for naming constants.
>Object Naming Conventions
>   Provides a suggested format for naming objects.
>Table Field Naming Conventions
>   Provides a suggested format for naming fields in tables. These conventions are recommended, not required.
>Variable Naming Conventions
>   Provides a suggested format for naming variables.
>Window Naming Conventions
>   Provides a suggested format for naming windows.
>

>
>>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?
>
>I would name it DateTextBox, cause it is a class. When I dropped it on a form to create an object, I would name it txtCheckDate or dxtCheckDate. (ie, we sometimes come up with our own prefix for objects created from our customer classes, perhaps dxt for DateTextBox.
>
>BOb

That I'll take as a vote in favor of providing a different three char prefix for subclasses. ;)