.
                        ARRAY_PLANS
                        ===========
.
Well, planning the (possible) windowing schema(s) makes it
 seem like a good idea to try to pre-plan out the array
 strategem(s)
.
I know I need/want at least one dimension on labels. Then
 textboxes are a shoo in at that point. Buttons too.
 No way I am having a hundred click events because someone
 thinks they want 100 labels DIMensioned; having a 100 is
 fine and dandy, I already "send" the user click code LR$ so
 the code knows if it was a left or a right click that called
 it up. SO, I will send the user code "index" so the code
 knows *which* of the 100 buttons got clicked on.
.
I *know* I don't want to "surgery in" 100 labels to the def'n
 file. I could, but, keeping track of user created stuff by
 surgery? Sounds like a fiascoe *waiting* to happen. 
 (I'm talking about the tracking and the removing being a
  potential mess. Call it a hunch.)
.
.FILE is another obvious solution; file was my first idea.
.
.file strategy... the .index property of a regular control
 will be 0. An .index of 1 and greater, would trigger FILE.
 Any error in the system, and the index will most likely come
 back as 0 anyways. If an array bombs out to 1 (or none)
 controls, it would indicate a stray erroneous .property
 assignment to the .index property.
.
.they go where .listboxes already go, under the projects
 folder.
.
an .index of 1 and no others, is not as crazy as it sounds...
 it would be triggering "file" saving and retrieving.
 it would automatically take care of "running from file"
 with variables. Simply set all controls to "1" index property,
 and voila, they run from file.
.
.index 2 or greater is array implementation.
