When my relatives moved to Linux

[Bill Marriott]

Richmond,

>>>
Now, having paid for a newer version of RR I was
rather surprised to find that there appear to be
rather similar script constraints.
<<<

Without those constraints, you'd pretty much be able to write your own 
mini-Rev and distribute it for free, eh? Just put whatever script you like 
into a field and use do commands. There'd be no limit what could be done by 
the end user of your standalone.

Keep in mind the script constraints are for what is defined "on-the-fly" at 
runtime in standalones, when "setting the script of" something or using "do" 
commands. Scripts that already exist at the time you created the standalone 
can be of any length.

Obviously it's an arbitrary, anti-piracy thing that restricts absolute 
freedom in design. But in practice I haven't found it to be a factor at all. 
In your stack, you want the kids to be typing "Grandmother" and "Cousin" --  
not writing xTalk handlers, right? I think the only real limitation 
scriptLimits imposes is making it more difficult (but not even impossible) 
to build some kind of self-aware AI that reprograms itself. :)

Anyway, I think the real lesson here is to look at programming Revolution 
differently than how you're doing it right now. Take your skills to the next 
level! Sure there are lots of "styles" with benefits and drawbacks perhaps 
to each, but just look as some of the handlers you had in that stack.

- In some cases if you made one small addition to how you wanted to 
handle/display things, you'd be making multi-line changes to the scripts of 
dozens of different objects (like the check marks).

- The script that I replaced with 10 statements in my prior post was 
originally more than 50 lines

- Everything was explicitly referenced, as if you had a grudge against 
loops, variables, and passing messages :)

- And did that script really need to be in a field, as opposed to being 
attached a standard control? It seems to me one would only want to do this 
for something that must be dynamically created/modified at runtime.

Sure it works (standalone issues aside) for what you've got currently. But 
what if you wanted to take this stack to the next level? For example, 
perhaps you'd like to start out with a "simpler" family tree at first, then 
build up to the one in card 2. Or enable a student to build their own 
personal tree based on interview questions? Or to have them load the actual 
pictures of their family members? Any of those changes would require an 
almost complete rewrite because of the "hard-wired" nature of what you've 
got.

Here's one concrete example. You've got a closeCard handler in card 2 that 
reads as follows:

on closeCard
---- hide yellow borders ----
set the vis of img "Y1" to false
set the vis of img "Y2" to false
set the vis of img "Y3" to false
set the vis of img "Y4" to false
set the vis of img "Y5" to false
set the vis of img "Y6" to false
set the vis of img "Y7" to false
set the vis of img "Y8" to false
set the vis of img "Y9" to false
set the vis of img "Y10" to false
set the vis of img "Y11" to false
set the vis of img "Y12" to false
set the vis of img "Y13" to false
set the vis of img "Y14" to false
---- clear fields ----
put empty into fld "F1"
put empty into fld "F2"
put empty into fld "F3"
put empty into fld "F4"
put empty into fld "F5"
put empty into fld "F6"
put empty into fld "F7"
put empty into fld "F8"
put empty into fld "F9"
put empty into fld "F10"
put empty into fld "F11"
put empty into fld "F12"
put empty into fld "F13"
put empty into fld "F14"
end closeCard

Now, you follow a convention in which all the yellow border images around 
solved pictures are named starting with "Y" and all the fields where answers 
must be supplied start with "F" -- and there is one field for every image. 
You could say:

global familyElements
-- number of Family Members to guess. Doesn't have to be a global,
-- could be stored in a field or even derived from counting the number
-- of portrait images

on closeCard
  repeat with i = 1 to familyElements
    hide img ("Y" & i) -- hide the yellow borders
    put empty into fld ("F" & i) -- clear the "guess" fields
  end repeat
end closeCard

And you'd be done with it... never having to visit that handler again. In 
the original script, you have to make two changes any time you add or remove 
a family member from the tree. And if you decided to adjust the naming 
convention (from say "F" to the more descriptive "Guess") you'd have 14 
changes. In the suggestion above, that's just one adjustment.

Suppose you realized that you had one more "cleanup" chore to do for each 
image. Well you can now just add one more line inside the loop, rather than 
another 14. It's just more amenable to updates.

Compared to the original it is quicker to write, easier to understand, more 
flexible, and self-maintaining. This is an example of where "quick and 
dirty" is not really quicker. Best to do it "right" the first time.

It's kind of like the difference between manually setting the headline font, 
size, and style in a word processor document, vs. using a style sheet. It's 
how a lot of us learned in the beginning, and it's kind of okay for quick 
notes or email. But if you were to have an entire manual prepared that way, 
it would be a nightmare if you one day wanted to change from "Times" to 
"Palatino" font. And that is why style sheets are critical in both print and 
web publishing. Or to use an even simpler example, pressing return at the 
end of each line (instead of letting the computer word wrap) and pressing 
the space bar repeatedly (instead of tab stops) to align text.

I think that you'll open new possibilities for your projects and ultimately 
find more freedom in design if you are willing to take a more *abstracted* 
view of building stacks, from the beginning -- even with simple ones. It may 
require conscious effort and perhaps even some discomfort at first. But soon 
it will become second nature and you'll begin to perceive the elegance and 
practicality of such an approach.... and that will bring its own pleasure.