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