I tried to follow the three-character prefix for simple objects like textboxes, but I don't find it practical for more complicated objects.

If I have a PickField class (to select data from another table), each object based on it would have a name that starts with "Pick": PickArticle, PickClient, etc.

An object based on a multiselect class might be named Multi-something. And so forth.

>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 recommended for textboxes, cmd for command buttons. There is not one prefix for them all, because even though they are all "controls" they serve distinctly different purposes.
>
>OK? Good. So if I subclass a custom control and turn it into a business object why should I call it cusBusinessObject? If I do that, then any subclasses either have to be cusBusinessObjectCompany or cusBOCompany. Since this new class is used for distinctly different purposes than the custom class why not begin using a new three character prefix, such as BZO?
>
>For that matter, if I create a class based on the Iterator design pattern, that ultimately derives from a custom class, should it be called cusIterator rendering subclasses like cusFileIterator or cusITRFile instead of ITRFile?
>
>Please discuss.
>
>Thanks