A case of assigned behavior not taken into account
Pete Haworth
lists.pete at haworths.org
Thu Jul 28 12:55:39 EDT 2011
The dictionary does say that behaviors are in the form of long IDs but I
have found that they don't have to be. A behavior of the form 'button ID
1234 of stack "xyz" works just fine. I have no idea if this is a loophole
or whether it is intended to work that way. I do know that it save a huge
amount of work reassigning behaviors every time you move a stack form one
location to another.
Pete
On Thu, Jul 28, 2011 at 12:41 AM, André Bisseret
<andre.bisseret at wanadoo.fr>wrote:
> Hi Bob,
>
> You are right ; i verified that when loading the application from one
> computer to another (from Mac to PC and vice versa) I had to reassign the
> behavior button
> So I am keeping doing this reassignment.
>
> Thank you very much for your attention and explanation.
>
> André
>
>
> Le 27 juil. 2011 à 18:37, Bob Sneidar a écrit :
>
> > I will take a shot at this. Behaviors are actually the script of a
> button, referenced as it's long ID. The long ID (as you could see if you got
> the long ID of any object) references not just the card it is on but the
> stack itself. When you clone a stack with behaviors, I suspect that the
> behaviors are still using the reference to the long ID of the button in the
> template stack. You will have to change that by script as you suspect.
> >
> > The reason this is like that is because you would want a modified
> behavior script to affect all object that use it in your entire application.
> It's just a little bit like OOP for programming. If you wanted the behavior
> to be altered a bit for certain objects, you could either intercept the
> message in the object's script, do what is different, then optionally pass
> it, or you could create a new button which was a copy of the behavior button
> and assign the object's behavior to that. But obviously you would lose the
> "one edit fixes all" for that button.
> >
> > Bob
> >
> >
> > On Jul 27, 2011, at 4:41 AM, André Bisseret wrote:
> >
> >> Bonjour,
> >>
> >> On an app. I am developing on Mac, I have a main stack a substack of
> which is a model used for creating new stacks which are cloned from the
> model and saved as "independent" stacks (not substacks).
> >>
> >> The scripts of the card 1 of this model and of all objects on this card
> are all together in a behavior button which is assigned to this card 1.
> >> This behavior is on card 2 of the main stack.
> >>
> >> All is working well on Mac.
> >>
> >> But when I load the standalone for Windows on a PC (by means of a USB
> key) then a newly created stack from the model is inert.
> >> Meanwhile, I verified that the behavior is actually assigned to the card
> 1 of the new stack, but all behaves like this was not the case!
> >>
> >> If, by script, I reassign the behavior to card 1 of the model before
> cloning it, then the new stack is working as expected.
> >>
> >> So I could stay with this reassignment but…
> >>
> >> Is it normal (seems not to me!), or am I missing something ?
> >>
> >> Any hint much appreciated
> >>
> >> Best regards from Grenoble
> >>
> >> André
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
More information about the use-livecode
mailing list