.
                     NAMING OBJECTS
                     ==============
.
When I first started out, I was naming things as:
.
form1, form2, form3, etc
label1, label2, etc
.
and this works fine, until you try to go past number 9.
.
I thought I had bigger problems when I went to a 16 form demo.
 at IDE design time, form10 was getting properties meant for 
 form1 saved to it or vice versa. Deleting wrong forms, oh, it
 was a hot mess.
.
the problem was, when you search for "form1" you also
 find "form10". The SOLUTION was easy:
.
form001, form002, etc
button001, button002, etc
.
so, you should be aware of this, and name things appropriately;
 IE, do not name things that are INSTRs of other names.
.
IMPORTANT:
 I myself periodically lose my ever-loving presence of mind
 dealing with 1500-2000 lines of code, and run into the
 (now) dreaded "INSTR CLASH". EXAMPLE, I was putting in
 colored text property on forms. I start making and using a
 new property ".textcolor". I start reading and reacting to
 that form property. Colored text appears. Do the happy dance.
 PROBLEM: I go to put ".textcolor" on all the other controls,
 'cause its just so darn handy and "pro" looking. Instead
 of an extended happy dance, I am greeted by buttons that now
 say "255255255".
WHAT ACTUALLY HAPPENED:
 form has a .title property; not a .text property
 so a "form001.textcolor" works exactly as intended. Happy dance.
 unfortunately, a "button001.text" property already exists;
 most unfortunately, when i read/set-default on the 
 "button001.textcolor", I allowed "button001.text" to be
 read in. IE, INSTR.
                    *** IMPORTANT ***
                 name objects carefully
                watch out for INSTR names
                    *** IMPORTANT ***
.
