>>> [EMAIL PROTECTED] 11/05/03 03:49AM >>>
>>>I've been throwing to gether 5 line scripts...
>>>The problem is that, given a blank piece of screen,
>>>where do I begin when devising my own code to solve my
>>>own problems. What is the starting point.
I have exactly that same problem. I have used REBOL for little
chores--moving files around the office, generating automatic email--but
when I want to use it for something bigger my mind is blank as to how to
start. Just last week I had an excuse to use it for something a bit
bigger (but still small) so I have made a small crack in that barrier.
Here is what I have so far, in case it helps.
"Languages are interesting not only for what one MAY say, but for what
one MUST say."
I come from a COBOL background ("The use of COBOL cripples the mind..."
Edsger Dijkstra) so I'm used to having things that must be present, and
must be in certain places, so I do that in REBOL to make myself
comfortable. I also have found that the examples on the REBOL web site
use words like "file," "data," and so on that trigger a reflex in my
mind that says, "That's a reserved word," and that is confusing. So to
easy my confusion I type all the REBOL words in lower case and all the
words of my own invention in upper case, just like old COBOL. It is not
recommended as a style, but it helps me personally.
I hope that as I go along I can develop a collection of reuseable, or
at least reconfigurable, scripts that I can call into my main program
with the "do (script-name)" command. I have one so far, which is a
language module. It contains every scrap of text that the main program
will show in any way. The idea it that by isolating all text in one
file, I could move the script to another language by translating that
one file. I hope to write it up for the cookbook this week.
The final form of a finished script will be something like this:
** The header
** "do" commands to bring in any reuseable modules
** "Declarations" of any configuration data items that the user might
want to change.
** "Declarations" of all other data items.
** All screens, defined with the layout function, each followed by all
the code that is run when the various controls are activated.
** The "main program" or "first executable instruction" to get the
program running.
With those preliminaries explained, here is how I proceed for a script
that has a GUI screen and does stuff when you push buttons, etc.
Draw out the screen, physically or mentally, so I have some idea of
what I am trying to accomplish.
Copy a skeleton of the REBOL header as my new script file, and fill in
all the stuff. This just gets me warmed up, gets a little momentum
going.
Put in a "do %language.r" command to bring in the language file, which
at this time is just a skeleton. (I'll put this "do" into the header
skeleton eventually.)
If I can see far enough ahead to know what data items I will be dealing
with, I will "declare" them. This is not necessary in REBOL, but I like
to do it to keep track of things. "Declaring" them is just setting them
to some initial value in some standard spot in the script, so I can look
back at them later and remember how to spell their names. This is like
DEFAULT-FILENAME: %xxxx.xxx
FORMATTED-DATA: none
and so on. As I go on, I will add more items. I also document each
item in comments in the script so I don't forget what they are and use
them for the wrong purpose. I tend to go overboard on comments, so I
have heard from my co-workers.
Then I define the(all) screen(s). I use just the layout function, as
MAIN-WINDOW: layout [
(VID commands)...
]
Now, when I set up any text, button, etc. in the layout, the text that
is to appear is NOT coded as a literal in the layout. It is coded as a
data name in the language file. For example:
button 60x20 LMB-001
LMB-001 might refer to a value of "OPEN" in the language file. So
during this layout development I also am making entries in the language
file, like
LMB-001: "OPEN"
For any screen control that can cause some action, usually a button, I
use a function call as that action. Even if the action is as simple as
"quit," I use a function call. This is because I like things tidy, and
so that if that action becomes more complex, I don't have to rework the
formatting of the script so much. For example:
button 60x24
LMB-001
[BUTTON-ACTION]
[inform LMH-001]
In the above example, BUTTON-ACTION is a function in the script. The
other action, "inform LMH-001," is the "inform" command which will
display a help text on a right click. That help text is a layout
in...the language file. So as I am setting up buttons, I am also adding
items to the language file.
I will define as many screen items as I feel like, just to get
something that can be displayed. I won't necessarily do the full
screen, or all screens, at this time unless I have a clear idea of what
everything will be like, or unless I have a good head of steam.
Then I define all the functions that were declared as actions on the
screen. I just put in stubs for them, like
BUTTON-ACTION: does [
]
This makes the script syntactically complete, although I believe this
is not necessary--in other words, the script will run fine until you
push the button with the missing funciton. But, I like things tidy, so
I put in a stub for every action, and will fill them in later.
Finally, I will put in the "first executable instruction" (or whatever
your computing background calls it). This usually is something like
view MAIN-WINDOW
At this point, I have something that will bring up a screen, and do
absolutely nothing. So I run it. Seeing it there gives me hope for the
future. Then I start filling in the unwritten parts.
Keep in mind as you read this that I am a beginner with a bias. Hope
it helps. In spite of REBOL's "simplicity" I still find it strangely
very difficult.
Steven White
City of Bloomington
1800 W Old Shakopee Rd
Bloomington MN 55431-3096
USA
952-563-4882 (voice)
952-563-4672 (fax)
[EMAIL PROTECTED]
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
