.
                    ALTERNATE STRUCTURES
                    ====================
.
While I was working on this, I had a mild deja-vu feeling,
 when I started indenting for pretty-printing the definition
 file out for human reading. "Where have I SEEN this
 STRUCTURE before? Its BUGGING me..."
.
Once I started indenting the buttons into and back out of
 the form to show ownership easier... it reminded me of... 
file/folder structure.
.
Follow the logic of this with me, if you will. You have a
 PROJECT, so, you then have a FOLDER named 'project'.
.
folder 'project' would contain 2 other folders:
.
folder 'form1'
folder 'form2'
.
lets open folder 'form1' inside 'project1' folder, shall we?
.
folder 'button1' 
folder 'labelclik2'
folder 'textbox1'
.
wanna guess what is IN any of those folders? I would imagine
 a file like this one:
.
-------------------------------
labelclik2.text = see LastRun;
labelclik2.visible = 1;
labelclik2.x1 =  316;
labelclik2.y1 = 50;
labelclik2.x2 =  516;
labelclik2.y2 = 75;
labelclik2.color = 255255255;
labelclik2.border = 1;
labelclik2.data = 000;
-------------------------------
.
this data structure would have some benefits.
.
when creating a new project? easy... simply create and name
 a folder
want a form? create a folder with a name on it and stik it
 in there. Want six more forms? create a folder anytime you
 FEEL like it... then simply call "paint project" and it
 appears automatically.
.
as it is right now? I consider it "surgery" to go in, read
 and modify and write back out on the fly, the holy
 definition file. Things the user might perceive as weird
 rules? Have largely came out of this situation.
.
"you must have at least one form" was simply because once
 the "project" is defined, it goes looking for any FORMS.
 I didn't see the POINT of having a project with no forms at
 the time.
.
when I create a form or a control? I found that due to my
 way i do it, I have to have at least one property set and
 defined in between the begin and end statements. Again,
 this made sense to me, what good is a control withOUT any
 properties? Sure, I *know* to assign default to get the
 ball rolling, but, with this folder structure? I simply
 DROP another folder in, and it already CONTAINS every
 default "object variable" already from the get go.
.
again, when i DELETE a control or a form? I simply delete
 the folder, then repaint the project. Done. finis.
 No 'surgery'. No CHANCE for any errors editing the
 def'n file.
.
This structure would FEED the existing program the same
 object variables. This would allow me to "keep" the
 existing program base, for now. The "pre open project"
 would in essence automatically CREATE the definition file
 automatically and instantaneously.
.
this would allow me to get STARTED a little less painfully
 down this road; but I think this might be the way to go.
.
the folder structure would, automatically, strictly enforce
 ownership. the folder for 'button' would EXIST inside the
 folder for 'form'. This would also give me a perfect
 structure for where to locate "CODE" for the object. The
 "click code" the user makes use of. I want the user's code
 automatically saved and re-used every time without cut and
 pasting it like now.
.
this would allow me to have a more traditional IDE with a
 "code" button to click on to "see the code" during IDE
 runs.
.
by making the object variables a small file inside folders,
 the actual objects are actually contained inside the object
 owning them. LOCATING them is no more difficult than
 following a directory tree.
.
project1/form2/label1/text... where "text" is an actual
 FILE NAME
which we either read or write to. This aspect of the whole
 system is fixable inside the get property, put property,
 make property, getmakeproperty routines. The code CALLING
 the getproperty routine doesnt care "where" it GETS the
 string from, it just cares that it gets it.
.
this is AWFULLY close to VB syntax...
 project1.form2.label1.text = 
.
Hm. another thing this folder syntax would be good at, is
 custom properties. As it is now? TAKKY combs the object
 variable list, extracting control properties and putting
 them into the def'n file... during the update-defn. I know
 which controls to use, they are listed in the form def'n.
.
I know which properties to go looking for as well, templates
 has a list for each object type. This works very well,
 except for custom properties. You can create and use them,
 but it doesnt gather them in during the defn sweep.
.
With this folder syntax? Too easy. any custom properties
 created? created a small FILE in the correct ownership
 folder. This small FILE? For instance might be
 "button1.altlang=Spanish". This FILE, will not
 *spontaneously* re-locate itself, nor will it change
 itself or delete itself.
.
the custom property you created? would stay there.
.
With my current system? there's just a CONCEPT of ownership.
 Form1 'owns' label1 and label2, largely because
 "the def'n file says so". And simply because the def'n file
 says so... its proj1.form1.label1 ends up being the
 variable name created.
.
form1 "owns" label1, just because we made a notepad file
 that SAYS so.
.
With folder syntax... form1 *actually* owns the controls, as
 they are folders inside the form folder. Physical ownership.
============================================================
OKay, these seem to be all good things that come from folder
 syntax. 
.
Now, before I do a thing at all, I need to stop and think.
 What are the ramifications of it all? I have a couple of
 logical possibilities:
.
1) Implement and use folder syntax initially. During make
 project. It allows for rock-steady form creation and
 deletion, as well as creating, moving, deleting controls.
 anything created or set, stays that way. THEN, use that
 rock-solid base to create the definition file from, and go
 on "normally" as we do now.
.
2) Do #1... *AND* completely follow through with updating
 the code to get, put, make object variables.
===============================================
OKay, now I need to stop and always think... "what was the
 jist of how I remember VB working?"
.
I distinctly recall a "feature" I never used in VB. You could
 throw a software switch, and
 "write the project out to file", then from that point on,
 it... "ran from file". It was supposed to be useful for big
 projects, as it no longer mattered about memory. It said it
 was a *slight* speed impact, but the tradeoff for large
 projects was incalculable.
.
Normal operation was running in memory. I stayed with
 "normal" as it was working.
.
This sure does *appear* as if I have stumbled upon that
 portion of the VB magic, maybe. I suppose I COULD, maybe...
 add another global array, tag it along with the VV$() and
 VN$(), it would contain the FilePath+FileName.
.
Then, if the "software switch was thrown" to
 "run from file"... the variable access routines would
 aready have the information to access the physical property
 location and either retrieve or update it.
.
BUT... I want to implement structure and features, such as
 FRAMES and USER CODE in the IDE. These features need the
 file structure to count on them, so, I think running from
 file from the get-go is the way to go.
--------------------------------------------------------
how to do this as painlessly as possible, though...
.
I would have to FORK the entire project. This would involve
 a complete stop on all new work. Copy the ENTIRE project
 over.
.
Then, I have a safe litter-box to play in. If I can follow
 through, start to finish, making the thing run like this,
 I can then go on working from that new fork, abandon the
 old one, its incorporated anyways. I can delete it and go
 BACK and continue working on my original course if i want
 to, try it again later.
.
its a great fall back point, if down the road this turns out
 to be slow or unforseen issues.
===================================================
while I am thinking about "what was VB like"...
.
VB had "startup" or "master" forms... I don't. I don't have
 any need for such distinction so far. I'm always curious
 when i might run into a situation where that suddenly seems
 like a good idea.
.
Does this apply here? Well, I have always gone with the idea
 that we "have forms" in the def'n, and its up to the
 programmer, which one he decides to make visible initially.
.
if I start or even follow through with folder structure, I
 again dont see the need for such a thing. There are folders
 that are forms, whichever one the programmer decides to
 make visible is his purview.
--------------------------------
VB I remember, I would say something like:
.
     LOAD 'Form1.frm'
or
   UNLOAD 'Form1.frm'
.
and once I got myself into several forms, I remember
 deciding whether to load and unload them, or, just load
 them all and work with setting visible on and off on the
 forms as i wanted them.
.
Hm...
.
system memory was measured in MB back then, not GB like
 today.
.
I *like* the structure folder method for project maker,
 hands down.
I like it "pre-driving" the definition file creation,
 locking start up in.
then, running in memory? Its been working F-A-S-T.
.
the majority if not all of my problems i had with editing
 and re-writing the definition file? have been primarily
 concerned with IDE time. Once RUNNING? and not having to
 save-definition anymore? I dont encounter any problems i
 dont create for myself while working on code.
 (and speed wise? it rips like a dirt bike, I'm pleased)
.
still, the run-from-file and physical ownership of the
 variables as FILES in the correct folders? well, thats too
 tempting to pass up too. I cant be expected to keep raising
 my array limits constantly, wondering where the upper
 limits are. Some big "power user" somewhere will create
 10,000 object variables and I only allow for 1024 at the
 moment.
.
run from file will be needed somewhere, sometime.
.
also? the structure of having the folders, as a
 pre-definition structure? will allow me to have "code"
 files located in the "correct" folders. it will allow me
 to have a "real IDE" that shows you a code button.
.
I am already starting to run things from file individually.
 Listboxes for example. Instead of locating them generically
 like I do now, the folder structure will solve that as well.
.
folder structure will need to be implemented fairly soon,
 and we can run in memory like now for the time being...
 but, a complete run-from-file will have to be an option too
.
 I can work on THAT part over time, without losing the
 ability to work on the other routines.
