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