best practice regarding behavior references?

[melristau]

Bet there's advice here but not finding...
Have behaviors linked to controls that need updating when I archive and change the name of my project. What's a smarter way of managing behavior descriptions?

[dunbarx]

Hi.

It is true that if you set a behavior, and then change the name of the enclosing stack, the behavior still reflects the old stack name. The behavior will break.

I do not know if there is a direct way to link that reference in a dynamic way, You can always manage this by hand, of course.

So is there such an expedient, as melristau requests?

Craig Newman

[melristau]

Just seems like there would be a better way than:

Code: Select all

on openStack
   setMatrixBtnsBehavior
   setTileBtnBehavior
end openStack

on setMatrixBtnsBehavior
   repeat with x = 1 to 117
      set the behavior of btn ("x"&x) to the long ID of btn "matrixBtnBehavior"
      end repeat
end setMatrixBtnBehavior

on setTileBtnBehavior
   repeat with x = 1 to 117
      if there is a grp ("x"&x) then set the behavior of group ("x"&x) to the long ID of btn "seedScript"
   end repeat
end setTileBtnBehavior

[FourthWorld]

Many things can depend on stack names. In practice there's rarely much of a need to change them. How often do you need to change your stack names that contain behavior scripts, and what prompts the change? Perhaps we can find a much simpler solution for you.

[jacque]

This came up on the mailing list, and for now the only dynamic method is to use the repeat loop you posted. The team did acknowledge that less dependency would be good.

But as Richard points out, it's rare to need to change the stack name. Usually changing the label is enough.

[melristau]

changing the label is enough.

Yes! This is a good and simple solution.

...when I got into LC a couple months ago, had fairly frequent crashes with 8. Seldom have crashes with 7.1.4 but couple times a day I duplicate and advance the version number. (Going forward, by label only.)

Thanks for help.

[dunbarx]

Labels are not just another option to the more important and far-reaching name property. The very secondary nature of labels allows one to "see" displayed text associated with objects, but leave the referencing tasks and responsibility to the "name".

In Hypercard, I changed names often, perhaps to indicate a new functionality of a button (like toggling "show" and "hide"). This can be managed, of course, but it is far more robust and comforting to be able to separate visible attributes from referencing attributes, the latter, once set, generally permanent.

Craig