.
                         STRING$
                         =======
.
This is in it's own section, because the subject of STRING$
 is very important to project CODENAME:Takky.
.
                  *** IMPORTANT *** 
            Takky runs entirely on STRING$
                  *** IMPORTANT ***
.
Why is this? Several reasons, and in no particular order:
.
This is not my first "giant program" adventure, obviously.
 Several decades of large programming projects has taught me
 many lessons, and one of the big ones is to USE STRING$.
 Honestly and truly? if my programming "job" was to name and
 save a number of INTeger values... I would write it all out
 in the file as string bytes. Yes, I know I am "wasting hard
 drive space". Hard drives are so big and cheap and getting
 cheaper and bigger every ten days it seems like.
.
There's a METHOD to my seeming MADNESS and my veritable
 obsession with STRING$.
.
sure, it would save file space to simply write out the
 INTeger values, actually a large gain in this example. But,
 when you go and *look* at the file? You don't "see" your
 INTeger values. You "see" your NAMES surely, those are just
 string bytes to the file, but... your INTeger values? If
 converted and space is saved, you see GOBBLEDYGOOK when you
 "look" at the file in notepad.
.
if I am not writing a program to save ten or 20 MILLION
 integer values? I can write out a simple STR$(int_val!) at
 file-writing time, and VOILA! I can now "see" the values
 easily.
.
Yes, I know I could when done... add some "module" that
 lists, tracks, and converts... all the values back and
 forth. But, I *won't* do this. Why?
.
Because... the SYSTEM is now much EASIER. you can just LOOK
 and "see" what all the values are, see what all the object
 variable names are, everything. WHy would you want to turn
 that into gobbledygook? Not only is it easier to SEE and
 READ in the file(s), its simply too easy to (carefully...)
 make a c-a-r-e-f-u-l edit with NOTEpad.
.
And? as another bonus, *any* novice programmer just about,
 can open up a text file, and read a line at a time in, and
 LOOK for whatever they are looking for. You can CHANGE a
 value with a few lines of code, if the programmer is any
 good at file and string manipulation.
.
Gobbledygook? I just know its (probably) some number there.
 I dont know if its INTeger, non-integer, *nothing*. I have
 to GUESS, I have to ASSUME.
.
SO, this is why for instance, the .color properties are all
 9 bytes. The first 3 bytes are the trimmed str$ of the RED
 value, and the following 6 bytes are obviously going to be
 the GREEN and BLUE bytes. I know I enjoy seeing and knowing
 and intuitively grasping what color something is by glancing
 at the bytes.
.
Once again, its a very easy coding task for the
 end-programmer to go "under the hood" and read, manipulate,
 or write out... bytes that are easily understood and read
 by humans.
.
This is a big program, I desperately *need* anything and
 everything as easy to create and manipulate as possible.
 Why would I make my job harder for myself, and why would I
 want to obfuscate the inner workings for the
 end-user-programmer?
.
To my way of thinking:
.
The end-user-programmer? do this simple programming exercise:
.
make a form, and put some controls on it. 3 button will work
 perfect. I will call them button1, button2, and button3.
 keep your form1 small, and locate it "low" on the project
 screen. This will give you "space" to simply PRINT directly
 onto the blank project screen.
.
after "MakeProjectBones" creates the SUBs... 
.
go to your button1 coding area, so when you click on your
 button1, you can run the following code:
.
     print"Object Varbs:"
     print"-------------"
     for t = 1 to v_cnt
      print t;" ";VN$(t);" = ";VV$(t)
     next t
     _display
.
go to your button2 coding area, so when you click on your
 button2, you can run the following code:
.
     print"Definition file:"
     print"----------------"
     for t=1 to nr
      print t;" ";def$(t)
     next t
     _display
.
go to your button3 coding area, so when you click on your
 button3, you can run the following code:
.
     cls
     _display
.
when you compile and run it? you can LOOK right at the
 object variable names and values. You can LOOK right at the
 definition file itself. Its as-held in MEMORY, right there
 on your screen. Its a copy of what was read in, minus the
 remarks.
.
TECH TIP: the *effect* this will produce in the
 end-user-programmer? The light bulb going off, how easy this
 will be? 
.
Will be perhaps I think most pronounced an effect, if you let
 "project maker" make a simple one-form project for you;
 running on mostly the given DEFAULTS. This will limit the
 number of assigned properties. Enlarge the form1 only enough
 to squeeze the 3 buttons on the same way, leave them
 defaults to limit the properties.
.
This will easily allow you enough SPACE to see the entire
 simple definition and object variables list; for a simple
 one form start up? its really short.
.
if the end-user performs the above simple programming
 exercise... honestly, as a programmer myself, how much
 *simpler* could it possibly be. I know *seeing* well over a
 thousand lines of code in a "heap" of FUNCs and SUBs will
 initially APPEAR to be intimidating; IGNORE IT ALL.
.
just run those 3 button codes, and the complete underlying
 structure becomes instantly crystal clear. 
.
Have fun. 
.
I have included a "generic" and un-used property called
 ".data" which is attached to *each* and *every* control and
 form... I made it for myself, so I had a place to stick
 ".color" property while I was working on implementing color
 across the project. It was a handy thing; when i was done
 and it worked? I simply cut-and-pasted my CODE, then
 adusted my code to work on the new ".color" property.
.
I don't have to put a new feature "into" code until I think
 its time.
.
the end-user can use .data for anything under the sun.
 Its a string. You could stick anything in it.
.
Its faster and easier for me to work with string files.
 I write out STR$() on numbers. When i read in a "variable
 name" and a "value" (both string$ arrays, btw) If i want or
 need a number, I just convert the string to what I need.
.
I dont have to keep track of whether a property is an integer
 or a real. Less code, less things stored.
.
I dont have to convert to several different types, and so I
 dont have to re-convert back again. Every one of these
 steps? would be a possibility for the (common) type-mismatch
 or conversion error(s).
.
in MY system? if a weird entry just HAPPENS to find its way
 into the system? It most likely wont CRASH the final
 program. If ".x1" bombs out because it finds "12K3" instead
 of "123", its no longer a type mismatch, a conversion
 error... it simply reverts to a ZERO. Maybe your form or
 your button jogs over unexpectedly, but... the whole system
 otherwise keeps running.
.
strings give me all this. Readability, ease of programming,
 less code, less chance for errors, less chance of crashes.
.
TAKKY doesnt "need" for the definition file to be structured
 and readable; I did that for the USER's convenience. For the
 end-programmer's convenience.
.
TAKKY doesn't need the ;REMarks ability? Thats just there to
 make things easier for humans to see whats going on, and
 where. I would expect users to ;COMMENT any multi-form
 project definition file, for their own purposes.
.
TECH TIP: (a) ;REMark line(s) in the def'n text file? is a
 VERY EASY way to "mark" the definition file, so the
 programmer can LATER at RUN TIME, make some change, and do
 it easily. Think about it... its a TEXT FILE. you could
 EASILY:
.
read in the def'n lines one at a time, writing them back out
 to another file.
when you "hit" your special comment? you read in, but DONT
 write out to the other file. (you skip it).
when you hit your *other* special comment? You continue
 reading in, and writing out, the lines to the end.
rename the new file to the definition file name, DONE.
the programmer can, at run time, take OUT controls or whole
 forms, and put IN controls and forms, in the same fashion.
.
you simply LOOK with INSTR() for "your" ;COMMENT, whatever
 code YOU decided on.
.
THAT other/conversion system? would only benefit from saving
 bytes on a hard drive. I don't know, maybe a company wants
 the files to "look high tech", or, to KEEP the end user from
 knowing how (possibly) simple the data structure really is.
.
MY (string) system? has so many other benefits, they easily
 outweigh the saved file space.
.
TECH TIP: the true underlying data structure(s) of TAKKY,
 are just string$. The definition file is just lines of
 strings, the variable name array is string$, and the
 variable VALUE array is string$ as well.
.
