constants??

[fredigertsch]

Hi there
I like to have constants like MODE_BUILD_INACTIVE that I use in all Scripts. Is it true, that I have to declare that constants in any script? Or is there a better way? Thanks.

Best, Fredi

[Klaus]

Hi Fredi,

I am not sure, but I think constants are treated like local variables, the docs are not explicit about this!
I would use GLOBAL variables and inititlaize these "on openstack" or or maybe even custom properties.


Best

Klaus

[fredigertsch]

Thanks Klaus, then I can not use constants as usual.
Best, Fredi

[dunbarx]

If a constant is declared in a script, but outside any handler, it can be used in any handler within that script. But it will not be available in other scripts. In this way it is similar to the "local" declaration made, again, in a script but outside any particular handler.

The main difference between the two forms, as I see it, is that constants cannot be changed once declared, whereas variables can be.

Craig Newman

[mwieder]

But it will not be available in other scripts.

Sad but true. There's a long-standing request in the bug database to change this.

I like to have constants like MODE_BUILD_INACTIVE that I use in all Scripts.

There *is* one way around this, but it's a workaround kludge rather than a real way to have constants available everywhere.

in script of card 1:

Code: Select all

global kMODE_BUILD_INACTIVE

on preopenstack
  put true into kMODE_BUILD_INACTIVE
end preopenstack

will create a MODE_BUILD_INACTIVE variable that can be used in all scripts, but its contents aren't locked like a real variable. I use a "k" prefix to remind myself that it's a constant and I shouldn't write to it (as in kMODE_BUILD_INACTIVE). And you still have to declare access to the global in each script where you will be using it:

in an object script:

Code: Select all

global kMODE_BUILD_INACTIVE;

if tBuildMode is not kMODE_BUILD_INACTIVE then
  -- do the active build stuff here
end if

[fredigertsch]

Thanks for all replies.

@mwider: this is a workaround, but when I have to newly "declare" it with the global statemant in each script, why not newly declare the constant MODE_BUILD_ACTIVE = "mode_build_active" in each script? (copy paste). Anyway, it would be better to implement the global constant declaration...

Fredi Gertsch

[mwieder]

The only advantage is that if you're using MODE_BUILD_ACTIVE as a semaphore to drive conditional things, then you only have to set the value of it once, i.e., true or false, instead of changing it in multiple scripts (and trying to remember which scripts have it defined). The downside, of course, is that it has all the drawbacks of global variables.

But yes, global constants (or include files) would be a much better solution.

[BvG]

I don't understand why anyone would use a global to replicate a constant. Using cprops is so much more easier and the bestest! Especially as they can be set by hand in the inspector, then never to be touched again. For example (not a very good one maybe, but it's a real world example), I have a "FirstTimeLoaded" cprop in my BvGDocu stack (actual property name different). Whenever I release a new, updated version, I make sure to set it to true, then save. This makes the stack change to the setup wizard, the next time it's loaded, basically the following:

Code: Select all

on preopenstack
  if the firstTimeLoaded of this stack then
    show group "setup settings"
  end if
end preopenstack

PS: this is a bad example, because the stack should just check if the necessary setup steps have previously been done, instead of always showing the setup.

[mwieder]

Yep - that's another good way to deal with it, and that's normally what I do. Has the same drawbacks as global variables, though: they're not read-only, so any script could "set the MODE_BUILD_ACTIVE of this stack to 42". I won't use globals unless it's absolutely necessary.

[FourthWorld]

Given the scope limits of constants, I tend to use function calls to access such values.