31142 lines/cards/records

[Rob Cozens]

<<
constant left = 1
constant mid = 2
constant right = 3

put leftValue into myArray_c left]
put midValue into myArray_c[mid]
put rightValue into myArray_c[right]

get myArray_c[alignBy] -- assumes alignBy is "left", "mid", or "right"
<<

Sorry Doug: I let you astray here.

In the above example alibnBy would have to be "1", "2", or "3".

Since I'm not sure of your objective, I'm not sure show to steer you 
straight; so here are some general thoughts:

The value of a constant never changes.  Where ever the MC engine 
finds a reference to a constant in a handler, it replaces the 
reference with the value of the constant.

In general, I have two uses for constants:

One is to reference an object indirectly so the object can be changed 
without have to rewrite every handler that uses it.  For example, 
suppose I have three icon images representing a barrel holding red, 
rose, or white wine.  I can script every button on every card or 
group with something like:

    switch wineColor
       case "red"
          set the icon of me to 123456676
          break
       case "rose"
          set the icon of me to 123456677
          break
       case "white"
          set the icon of me to 123456678
          break
    end switch

If I do so, and later need to change icons for any reason, I must go 
back to every handler where this logic is used and change the 
appropriate icon id(s) everywhere they appear.

If instead I script:

    constant redBarrel = 123456676
    constant roseBarrel = 123456677
    constant whiteBVarrel = 123456678

    switch wineColor
       case "red"
          set the icon of me to redBarrel
          break
       case "rose"
          set the icon of me to roseBarrel
          break
       case "white"
          set the icon of me to whiteBarrel
          break
    end switch

I can now change the constant declarations and leave the rest of the 
scripts unchanged.  One limitation: constants are not globals; so 
they must be declared in every script (not handler) that uses them.

Reason 2: If you look at the above examples, I think you will agree 
that "set the icon of me to redBarrel" gives a scriptor revisiting 
the handler a clearer picture than "set the icon of me to 123456676". 
So the other general use I have for constants is to make my handlers 
more descriptive.

Another example: there are currently 190 individual messages (lines) 
in a Serendipity Library message file.  Every time I need a message I 
could simply "answer sdbMessage(123)" or "put sdbMessage(55) into 
field "Message Field"; but reading the handler later gives one (who 
has not memorized the message order) no clue as to content:

   answer file with sdbMessage(123)
   if it is empty then exit thisHandlerName
   open file it
   if the result is not empty then
       beep
       answer sdbMessage(137) with sdbMessage(148)
   end if

So I use something like:

   constant sdbFilePrompt = 123
   constant sdbFileOpenError = 137
   constant sdbQuitTranslated = 148

   answer file with sdbMessage(sdbFilePrompt)
   if it is empty then exit thisHandlerName
   open file it
   if the result is not empty then
       beep
       answer sdbMessage(sdbFileOpenError) with sdbMessage(sdbQuitTranslated)
   end if

Two closing note:

1.  If you look closely at the second example, note the logic also 
facilitates maintaining multiple translations of the same stack (as 
Serendipity Library does).

2.  The second example is very close to use with an array.  If one 
were to "split sdbMessages by return", then the sdbMessage function 
could "return sdbMessages[lineNumber]" instead of "return line 
linerNumber of sdbMessages".

Hope this helps.  If I'm still off target, post more details.
-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)