Creating a reusable object - Part 2
Timothy Bleiler
bleiler at buffalo.edu
Thu Aug 9 09:54:06 EDT 2012
Hi Mark,
Glad you found my previous suggestions helpful. Let me offer something
else for you to think about.
I agree with Jacqueline that if all you need to do is handle the
resizeStack message, then the best approach is to catch the message at
the stack level or the backscripts level. The backscripts level would
be appropriate for handlers that you want to access from more than one
stack. If you have a single stack design, then there would usually be
no practical difference between placing a handler in the backscripts
vs the stack level. Note that background groups and backscripts are
very different. I think the similarity in their names often confuses
people. One key difference is that backscripts do not need a specific
current card control associated with them. The background and shared
groups feature is usually the better choice for sharing actual
controls across cards.
Since you said that you don't want your resizeStack handler on some
cards in your stack that indicates that you have a stack feature
associated with resizing that varies with the cards in the stack. That
probably is not the best design for a variety of reasons. You should
consider placing the cards that need a special response to stack
resizing in one stack and putting the other cards in one or more other
stacks. I'm guessing they have some key functional differences that
might also suggest a multistack design. Check the User Guide for the
discussions on substacks. That might help you get a cleaner, easier to
debug and maintain architecture.
Finally, I just want to try and clarify the purpose of the
SharedBehavior and BackgroundBehavior properties for you. The
sharedBehavior property is a relatively recent addition that allows
the sharing of groups of one or more controls across cards WITHOUT
having the BackgroundBehavior set to true. Any group that is placed on
multiple cards has SharedBehavior set to true and that's locked by the
Livecode engine. It really doesn't do very much but allow the
separation of the BackgroundBehavior features from shared groups. The
BackgroundBehavior property has greater impact on your stacks because
when it is true, the location of the group script in the message path
is changed and the group is automatically placed on new cards. You can
control the placement and removal of groups on cards in your scripts
using the "place" and "remove" commands.
Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo
On Aug 9, 2012, at 12:37 AM, Mark Smith wrote:
> This leaves the original group/object intact to respond to
> (in this case resize) messages.
More information about the use-livecode
mailing list