>Mike - any OOP purist will tell you AddProperty stinks - I don't claim to be an oop purist - but as a general rule - well - AddProperty stinks - it is a bandaid for poor design somewhere else down the chain.

I don't claim to be an OOP purist either, however, this should be taken on a case by case basis. For example, there may be instances where you would want to add a system wide property. You have to choices either a global variable or using AddProperty() to the _SCREEN object. The same applies to AddObject(). In general, it isn't a good idea, but everything needs to be taken on a case by case basis.

>I can tell you that - as a general rule again, and not in all cases - the more someone tends to move to an "academic" position with all this - the more they start talking self-indulgent nonsense that sounds really cool but has zero practical value. My suggestion is that you give as much credence to those out "in the trenches" as you do to those on the pedestal.

This reminds me (and you may not be going this way) of, "Well, that doesn't work in the 'real world'" tripe that I heard early in my career. What this type of statement overlooks is that the theories are based on "real world" needs and situations. The fact of the matter is that OOP (and Structured Programming before it) grew out of the need for addressing these problems. Not only do the applying the principles of cohesion, coupling, and partitioning make development easier and faster, but, more importantly they make maintenance and modification easier and faster. Since, in most systems, the bulk of the cost associated with the system is in maintenance and modification, it is important to carefully analyze when it is appropriate to "break the rules". This can only be determined by careful quantitative analysis.

I'll take issue with an earlier statement regarding DO FORM. There is zero, none, nada advantage to using CREATEOBJECT() over it. In fact, in some cases (especially where the designer has chosen to use the native VFP DE), it is less advantageous. You can still gain all the advantages of sub-classing a base form and using it as your template, by using the template form option under "Options/Forms" or by CREATE FORM cFormName AS cClassName FROM cClassLibraryName. This overcomes the lack of a DE.