RE: 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)
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution