Hi Hilmar

I'd like to suggest that a container class that is coded to be a business object has no reason to be called ctrBusinessObject. It is not relevant that it's a container. It also has no reason to be called ctrBOInvoice. However in the interest of making wrong code look wrong, txtBOInvoice would clearly be an instance of the wrong class. I'd have to dismiss that one. The point is to make things clear. Having txtBOInvoice and ctrBOInvoice is just asking for trouble.



>>Let me give you an example. Don't you find lcAccountNumber and lnAccountNumber more useful names than AccountNumber? I think the disctinction is MORE important in a weakly typed language like xBASE. xBASE is downright diabolical in letting you instantiate variables willy-nilly, no type defined, even letting you change type by assigning a different constant, and then expecting certain parameter types at run time. Kaboom!
>
>You may not like it, but what this particular article suggested was to create your own types. For instance, if you use different account fields in several places, each might be prefixed by Acc (in Visual FoxPro, we might perhaps adapt this to lAcc, with l for "local") - instead of lc or ln. This - according to the article quoted - was the original idea behind the "Hungarian Notation", which has since become distorted.
>
>>
>>Mike
>>
>>
>>>Hungarian notation was invented for the C programming language. It has its great value in strong (strict) typed languages has you carefully have to match types. In weak (dynamic) typed languages it is less important, casting from double to int to numeric is done automatically: there is less need to be aware of the exact type. In VFP we have only: character, boolean, numeric, date, datetime and object as base types. Therefore there is less technical need to distinguis between derived types like int, float, double and memo and text.