.
                   OBJECT VARIABLES; ADVANCED
                   ==========================
.
When I was at my university the first time, all of us in the
 math & computer science department had never seen nor heard
 of VB. This was late 80s, early 90s. owning a 16bit computer
 wasnt much of a sin back then. If VB existed then, we hadn't
 been informed, or at least I dont remember anyone so much as
 mentioning it. the compiled version of "regular basic" was
 all the rage.
.
When I went back to my university the second time? Things
 were vastly different. The mainframe terminals were still
 everywhere, but, networked PCs were clearly the oncoming
 thing to replace the aging mainframe. PCs were a little
 faster, a little more memory... and? I was shown
 "Windoze 3.11" for the first time. Along with...
                       ding ding ding
 what was referred to as "the new basic".
 (my first quick glance at VB)
.
Along WITH THIS new setup? Came also new "stuff" creeping
 into the CompSci coursework. The "Object Model" was the
 latest buzzword. One of my higher-level courses I had been
 looking forwards to? Was something along the lines of
 "APPLIED compiler design", hey, I wanted to make a "real"
 compiler for something small... not just discuss and
 memorize crap about a made-up THEORETICAL compiler MODEL.
.
Wish in one hand though, and an entire course that was once
 dedicated to making a real compiler? Was now yet one more
 "lets discuss this theoretical language... we are more
 concerned with implementing the OBJECT MODEL than we
 actually are in the mechanics of accomplishing the compiler
 design... 
.
you see, my problem WITH the "object model" is not any
 problem with the object model itself, its how the object
 model is IMPLEMENTED that drives me up the wall. WHY did no
 one ever just SHOW us VISUAL BASIC... to SHOW us, what the
 object model was "good for", I'll never understand.
.
Yet? One huge GEM came out of that class, a real nugget of
 pure wisdom that I did not understand until getting into
 *this* mess of a project. We were something like 8 or 9 out
 of 15 weeks of pure boring hell, memorizing a fictitious,
 made up language that was "properly designed" to some
 abstract model from some textbook... Grrrr!
.
I cracked a wise remark, and the professor
 (uncharacteristically) smiled and took a second to be one of
 the guys... "people? understand this, I *have* to teach this
 course this way now. I realize this is dry, fictitious
 junk... you are all way more concerned with actual coding.
 If you remember NOTHING ELSE from this not-well-planned
 course the administration came up with? Do not forget this,
 ever:
.
"everyone wants to know in REAL LIFE how this object model
 affects you? mainly... you can think of the Object Model,
 as nothing more than SPECIAL VARIABLE NAMES, that can help
 you ORGANIZE a large, complicated, set of software."
.
This isn't the *first* time, that the biggest thing I got out
 of college, was just remembering a one-off COMMENT that
 later on you realize was the big KEY that unlocked something
 HUGE you otherwise could never do.
.
I will repeat this, because I feel its extremely important:
.                            
                      *** IMPORTANT ***
   SPECIAL VARIABLE NAMES, is the primary "thing" that the
           entire object model actually gives you.
                      *** IMPORTANT ***
.
Now, if you sit and actually *think* about it, not a rush to
 judgement, but a slow-deep-think session? You will be hard
 pressed to come up with a "great" easy explanation to SHOW 
 what the object model gives you.
.
if you cant "show them VB" (or a clone), or show them the
 object variable names... short of showing those, I honestly
 feel as if I would be lecturing and regurgitating abstract
 crap I was forced to memorize in college.
.
Honestly, 2 main ingredients go into this CODENAME:Takky
 project...
1) a definition file provides "structure" and "organization"
2) Takky maintains a PRIVATE set of variables and values.
.
These 2 main ingredients are CRUCIAL. Each depends on the
 other. The definition file is not worth much without the
 special "dotted" object variable names it dictates be
 created. The special variables? CANT be "regular" variables,
 they have to be "dynamically named variables".
.
Now, you *can* name variables with periods... for instance?
 QB64 has no problem with project1.form1.label1.visible="1"
 and MAN did i (initially) think I was "ready to GO!"...
 ready to go nowhere but spin my wheels.
.
why? the variable special names have to be able to be
 DYNAMICALLY NAMED at run time. Meaning, my Takky GUI reads
 in a definition file I point it at, it sees a control named
 this, owned by that... and it makes a "this.that" name for
 it...
.
...great, but... HOW do i know what name to NAME my variable
 at compiling time? I dont. I wont KNOW that info until
 runtime.
.
the elegant solution to all of this? actually pretty easy.
.
1) Maintain a definition file. Write BACK to it to keep it
 updated.
2) two string arrays and an INT counter? *poof* instant
 custom variables. done.
.
so there you have it. The object oriented model is a
 wonderful theoretical abstraction, that happens to really
 come to life in VB (or any VB clone). At the CORE, it's 
 *honestly* nothing more than a special list of specially
 named variables, held private.
.
The def'n file tells Takky which object varbs to create,
 and when you save changes in the IDE? it uses the
 "structure" to sort of sweep and comb the list of object
 variables, extracting existing object variables.
.
which is to say in plain english? the following:
.
1) the definition file yells out to Takky: "Hey Takky !!!
 2 forms, each form has a button1 on it! what?? YEAH, its all
 defaults."
.
2) Takky grabs a list of default settings for "form" and
 "button". If the variable isnt made? it creates the
 variables
.
( increments the counter, 
  NAME$(counter) = "SpecialVariableName"
  VALUE$(counter) = "SomeBytesStoredHere" )
.
if the variable already exists? Takky just gets the bytes
 stored in the matching string array.
.
3) When the time comes to UPDATE the definition file? "Hey
 TAKKY!!! we're packing it in! save your notebook page on
 that one!", and TAKKY sweeps the def'n file several times,
 saving any entry and keeping the same structural
 organization.
.
TECH TIP: anyone can run the following code, to see at any
 point in time what object varbs are being held, and what
 they contain.
.
for t = 1 to v_cnt
 print VN$(t);" = ";VV$(t)
next t
.
TECH TIP: "yes, its that easy". And before you ask? Yes,
 you *could* use the following example code...
.
if (v_cnt < 1024) then v_cnt = v_cnt + 1
VN$(v_cnt) = "project1.form1.button1.language"
VV$(v_cnt) = "Spanish"
.
then later on, you could USE this property when your program
 decides what text to put on the buttons. You could start
 USING this new property all the time, put it in your
 definition files carefully.
.
whatever custom property you think you want or need? Takky
 once the variables are created and used, sees ".language"
 as simply another property, no different than ".x1" or
 ".text".
.
obviously, TAKKY does not expect the average user of this
 software to hard-code in such tasks.
.
A large and ever-growing set of FUNCs and SUBs, provides the
 functionality. As a quick example? In the original VB, I
 remember typing code like:
.
     project1.form1.button1.text = "Click_Me!"
.
until I figure out a way to accomplish this, the following
 FUNCtion provides the same thing:
.
     z$=PutProperty("project1.form1.button1.text","Click_Me!")
.
the various FUNCs and SUBs do these things for you.
