cross-stack globals, also, file inclusion

J. Landman Gay jacque at hyperactivesw.com
Thu Oct 23 14:47:49 EDT 2003


On 10/23/03 12:13 PM, Rob Cozens wrote:

> Jacque, et al:
> 
> * My primary constant list is, in effect, an index to lines of text in a 
> file and/or variable.  It is there to facilitate handler readability, 
> comprehension, and debugging.
> 
> Example:
> 
>     constant badInputWarning = 244
> 
>     answer sdbMessage(badInputWarning)
> 
> tells me a lot more than
> 
>      answer sdbMessage(244).

This is pretty much what custom properties are good at. You could do all 
this in a single line of script. Say you store the message list along 
with their ID numbers as a bunch of custom properties in a button called 
"propBtn". Somewhere when the stack opens:

   global sdbMessage
   put the customProperties of btn "propBtn" into sdbMessage

The global now contains an array. The keys are the message names, and 
the values of each key are the ID numbers. In your scripts, you use:

   answer sdbMessage[badInputWarning]

> * My secondary constant list is used to facilitate handler modification:
> 
>     constant simpleSearchIcon = 103405
> 
>     if the icon of button "Search Type" is simpleSearchIcon then ...
> 
> The idea here is, if I should later change the simple search icon to 
> 103450, I could make one change here and need modify nothing else. Of 
> course, without global constants this doesn't hold true; but at least I 
> only have to modify one constant declaration at the beginning of each 
> script rather than searching for every instance of the icon number in 
> every handler.

Same thing here again, only with a custom property array you really do 
only need to change the value once, directly within the custom property. 
Again, your scripts would use:

   if the icon of btn "Search Type" is myIcons[simpleSearchIcon] ...

> 
> * An ancillary use of constants is to support multi-lingual, 
> translatable applications:
> 
>     constant saveStackMenuItem = 133
>     constant newStackMenuItem = 107
>     constant copyStackMenuItem = 206
>     constant unsupportedChoiceWarning = 2
>     constant tryAgainPrompt = 202
>     constant forgetItPrompt = 203
> 
> 
>     on menuPick thePick
>         put sdbMessage(saveStackMenuItem) into saveMe
>         put sdbMessage(newStackMenuItem) into makeMe
>         put sdbMessage(copyStackMenuItem) into copyMe
>         put sdbMessage(forgetItPrompt) into quitNow
>         switch thePick
>         case saveMe
>             ...
>             break
>         case makeMe
>             ...
>             break
>         case copyMe
>             ...
>             break
>         default
>             beep
>             answer sdbMessage(unsupportedChoiceWarning) with \
>                 quitNow or sdbMessage(tryAgainPrompt)
>             if it is quitNow then exit to top
>             ...
>         end switch
>     end menuPick

One of the primary reasons for adding support for custom property sets a 
couple of years ago was to support multi-lingual apps. This is exactly 
what you need here. You'd create several custom property sets, one for 
each supported language. You only need to do this once, during 
development. When it is time to load the values, you just choose the 
property set first before loading the array:

   global sdbMessage
   set the customPropertySet of btn "propBtn" to "Spanish"
   put the customProperties of btn "propBtn" into sdbMessage

Bingo, all your scripts work without modification, but the strings that 
sdbMessage returns are in Spanish.

Seems pretty straightforward to me. You don't even need your original 
sdbMessage function.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com



More information about the Use-livecode mailing list