Terry, I really try to shyaway frum public variables. It really leads to jello - code (you touch it here it wiggles there) for me. After the function call you have to re-initialize the variable in case you have another function that calls or returns it. The only time I use a public variable is for global application objects, such as instantiating forms or custom controllers. Is this an odd approach?

No it is not - remember - there are no rules - we are artists - not repairmen!

Most of my projects work modeless forms (in top-level form) indside a main (top-level) form. Usually the contained forms will communicate with each other

If the form names of the "contained" forms are not public, then they wont be recognized as objects by VARTYPE() or TYPE(). When the form names are made public, TYPE/VARTYPE sees them. I have also noticed that PRG forms have issues when they are not "public".

My position is that everyting in the project that is issued an address by "runtime", like a variable name, is an object. Some restrict the definition of an object to only those things that are instanciated from a class. But every address is really an object! It's node mapped by runtime!

Were are told that an advantage of objects is that they are reusable. Then we get a "new" object syntax NEWOBJECT() *g*.

For little things there are judgements to be made. I may be a bit retentive, but the clock always weighs my decision. A question I always ask is the clock consumed by instanciation really necessary when I only have one or two or three variables that need to assigned?

So sometimes I use objects (mostly "custom" properties in a form), or I'll create a seperate function for each required variable and code their calls when (and in the order) the variables are needed.

There are no rules with VFP design (I like that) - but I am a holdover from the 8088 daze - so my first concern when making design decisions is "How much clock" will the process eat - can the process be implemented to use less clock?

I like fast interfaces too - so I try to write fast interfaces!:) - Clocks are so fast now - it is hardly notice.

Example of new age DBF: Most people use "SELECT" statements to pull a record - I use SEEK - Most people "bind" their textbox to a field - I assign the textbox.value=field. I evaluated "binding", but for the types of interfaces I write it (binding) was noticably slower than TextBox.Value=field, and not flexible enough to suit my goals. Yet - there are plenty of VFP developers writing good qualty interfaces with SELECT and bind - I just think my way is sexier!:)

And that is what is [really] all about - sexy interfaces!!