Re: Behaviors

[Geoff Canyon via use-livecode]

I'll admit it's not very intuitive, but:

In Navigator, right-click any button. On the context menu, select Copy >
Objects.
Navigate to any control or card, stack, etc. Bookmarks are fine for this as
well.
Right-click any other control. On the context menu, select Set Copied Btn
as Behavior.

On Thu, Aug 24, 2023 at 7:19 PM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> polygrid
> the api is similar, but they also have some nice additional features.
> i have ripped all my dg's and replaced them with pg's.
> now, if you're using custom templates, have a look at the pl - polyList.
>
> On Thu, Aug 24, 2023 at 2:12 PM Bob Sneidar via use-livecode
>  wrote:
> >
> > Ah thanks for that. Yes, I knew how to nest behaviors for datagrids, but
> I never use the Project Browser because of issues I had many years ago. I
> may have another look.
> >
> > What is a “pg”? I make extensive use of Datagrid properties, and
> whatever I might replace them with needs to provide ALL their functionality.
> >
> > Bob S
> >
> >
> > > On Aug 24, 2023, at 10:15 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> > >
> > > i'm pretty sure you can set a dg's behavior. then you would set the
> > > behavior of that behavior to the button behavior (button id 1005 of
> > > stack "revDataGridLibrary"), OR you can include THAT script,
> > > separately, set that as the behavior, and modify it
> > > (but, what you should really do is remove your dg's and replace them
> > > with pg's, imho. they're much faster and more flexible and powerful).
> > > the project browser has a button for each behavior in the chain of an
> > > object. i'm pretty sure that levure baker's assistant does, too.
> > >
> > > On Thu, Aug 24, 2023 at 11:35 AM Bob Sneidar via use-livecode
> > >  wrote:
> > >>
> > >> There is also the Advanced button in the property inspector (looks
> like one large gear with two smaller ones) where you can type the behavior,
> and also has the target icon. Also, you shouldn’t have to do that every
> time. Once should be enough if you save the stack afterwards.
> > >>
> > >> I note that Datagrids have no way to set the behavior, since they
> depend on their default behavior. It was discussed long ago when nested
> behaviors became a thing, that there ought to be a way to edit a list of
> behaviors of an object. In fact it shouldn’t be that difficult to make a
> Behavior Browser widget of some sort. Hmmm...
> > >>
> > >> Bob S
> > >>
> > >>
> > >>> On Aug 23, 2023, at 5:00 PM, Dar Scott via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> > >>>
> > >>> I, too, have discovered the target icon to the right of the behavior
> object field in the property inspector. Alas, using that that I see only
> buttons on the current card (and stacks). I don’t see a way to navigate to
> a different card and select a button there. I might have missed it. — Dar
> > >>>
> >  On Aug 22, 2023, at 1:05 PM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> > 
> >  you probably know this: in the property inspector, there's a panel
> for
> >  behavior, so you can just select the behavior from a menu button,
> >  without having to type it
> > 
> >  On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode
> >   wrote:
> > >
> > > I figured out how to do it in the IDE. I needed to include “of
> stack” in the reference. — Dar
> > >
> > >> On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> > >>
> > >> Not sure how it works in the IDE - seems a problem because it
> only presents button in the current stack.
> > >>
> > >> So I do it all in preOpen... scripts, doing something like
> > >>
> > >>> set the behavior of fld "F" of grp tmpName to the long id of
> button "RichTextFieldBehaviour" of \
> > >>>   card "Behaviours" of stack "/Users/alextweedly/Dropbox/My
> Livecode/Libraries/richText.livecode"
> > >>
> > >> Alex.
> > >>
> > >> On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
> > >>> I am misremembering things about Behaviors.
> > >>>
> > >>> I have a card with my behavior buttons, but I can’t seem to
> point to buttons on that card. Maybe, I’m remembering what I did long ago
> with front scripts.
> > >>>
> > >>> I suppose I can use substacks, but I’m worried that the stacks
> would be in the message path. Is there a way to keep the stack out of the
> message path?
> > >>> ___
> > >>> use-livecode mailing list
> > >>> use-livecode@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@lists.runrev.com
> 

Re: Behaviors

[Mike Kerner via use-livecode]

polygrid
the api is similar, but they also have some nice additional features.
i have ripped all my dg's and replaced them with pg's.
now, if you're using custom templates, have a look at the pl - polyList.

On Thu, Aug 24, 2023 at 2:12 PM Bob Sneidar via use-livecode
 wrote:
>
> Ah thanks for that. Yes, I knew how to nest behaviors for datagrids, but I 
> never use the Project Browser because of issues I had many years ago. I may 
> have another look.
>
> What is a “pg”? I make extensive use of Datagrid properties, and whatever I 
> might replace them with needs to provide ALL their functionality.
>
> Bob S
>
>
> > On Aug 24, 2023, at 10:15 AM, Mike Kerner via use-livecode 
> >  wrote:
> >
> > i'm pretty sure you can set a dg's behavior. then you would set the
> > behavior of that behavior to the button behavior (button id 1005 of
> > stack "revDataGridLibrary"), OR you can include THAT script,
> > separately, set that as the behavior, and modify it
> > (but, what you should really do is remove your dg's and replace them
> > with pg's, imho. they're much faster and more flexible and powerful).
> > the project browser has a button for each behavior in the chain of an
> > object. i'm pretty sure that levure baker's assistant does, too.
> >
> > On Thu, Aug 24, 2023 at 11:35 AM Bob Sneidar via use-livecode
> >  wrote:
> >>
> >> There is also the Advanced button in the property inspector (looks like 
> >> one large gear with two smaller ones) where you can type the behavior, and 
> >> also has the target icon. Also, you shouldn’t have to do that every time. 
> >> Once should be enough if you save the stack afterwards.
> >>
> >> I note that Datagrids have no way to set the behavior, since they depend 
> >> on their default behavior. It was discussed long ago when nested behaviors 
> >> became a thing, that there ought to be a way to edit a list of behaviors 
> >> of an object. In fact it shouldn’t be that difficult to make a Behavior 
> >> Browser widget of some sort. Hmmm...
> >>
> >> Bob S
> >>
> >>
> >>> On Aug 23, 2023, at 5:00 PM, Dar Scott via use-livecode 
> >>>  wrote:
> >>>
> >>> I, too, have discovered the target icon to the right of the behavior 
> >>> object field in the property inspector. Alas, using that that I see only 
> >>> buttons on the current card (and stacks). I don’t see a way to navigate 
> >>> to a different card and select a button there. I might have missed it. — 
> >>> Dar
> >>>
>  On Aug 22, 2023, at 1:05 PM, Mike Kerner via use-livecode 
>   wrote:
> 
>  you probably know this: in the property inspector, there's a panel for
>  behavior, so you can just select the behavior from a menu button,
>  without having to type it
> 
>  On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode
>   wrote:
> >
> > I figured out how to do it in the IDE. I needed to include “of stack” 
> > in the reference. — Dar
> >
> >> On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode 
> >>  wrote:
> >>
> >> Not sure how it works in the IDE - seems a problem because it only 
> >> presents button in the current stack.
> >>
> >> So I do it all in preOpen... scripts, doing something like
> >>
> >>> set the behavior of fld "F" of grp tmpName to the long id of button 
> >>> "RichTextFieldBehaviour" of \
> >>>   card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
> >>> Livecode/Libraries/richText.livecode"
> >>
> >> Alex.
> >>
> >> On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
> >>> I am misremembering things about Behaviors.
> >>>
> >>> I have a card with my behavior buttons, but I can’t seem to point to 
> >>> buttons on that card. Maybe, I’m remembering what I did long ago with 
> >>> front scripts.
> >>>
> >>> I suppose I can use substacks, but I’m worried that the stacks would 
> >>> be in the message path. Is there a way to keep the stack out of the 
> >>> message path?
> >>> ___
> >>> use-livecode mailing list
> >>> use-livecode@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@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@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your 
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
>  --
> 

Re: Behaviors

[Bob Sneidar via use-livecode]

Ah thanks for that. Yes, I knew how to nest behaviors for datagrids, but I 
never use the Project Browser because of issues I had many years ago. I may 
have another look. 

What is a “pg”? I make extensive use of Datagrid properties, and whatever I 
might replace them with needs to provide ALL their functionality. 

Bob S


> On Aug 24, 2023, at 10:15 AM, Mike Kerner via use-livecode 
>  wrote:
> 
> i'm pretty sure you can set a dg's behavior. then you would set the
> behavior of that behavior to the button behavior (button id 1005 of
> stack "revDataGridLibrary"), OR you can include THAT script,
> separately, set that as the behavior, and modify it
> (but, what you should really do is remove your dg's and replace them
> with pg's, imho. they're much faster and more flexible and powerful).
> the project browser has a button for each behavior in the chain of an
> object. i'm pretty sure that levure baker's assistant does, too.
> 
> On Thu, Aug 24, 2023 at 11:35 AM Bob Sneidar via use-livecode
>  wrote:
>> 
>> There is also the Advanced button in the property inspector (looks like one 
>> large gear with two smaller ones) where you can type the behavior, and also 
>> has the target icon. Also, you shouldn’t have to do that every time. Once 
>> should be enough if you save the stack afterwards.
>> 
>> I note that Datagrids have no way to set the behavior, since they depend on 
>> their default behavior. It was discussed long ago when nested behaviors 
>> became a thing, that there ought to be a way to edit a list of behaviors of 
>> an object. In fact it shouldn’t be that difficult to make a Behavior Browser 
>> widget of some sort. Hmmm...
>> 
>> Bob S
>> 
>> 
>>> On Aug 23, 2023, at 5:00 PM, Dar Scott via use-livecode 
>>>  wrote:
>>> 
>>> I, too, have discovered the target icon to the right of the behavior object 
>>> field in the property inspector. Alas, using that that I see only buttons 
>>> on the current card (and stacks). I don’t see a way to navigate to a 
>>> different card and select a button there. I might have missed it. — Dar
>>> 
 On Aug 22, 2023, at 1:05 PM, Mike Kerner via use-livecode 
  wrote:
 
 you probably know this: in the property inspector, there's a panel for
 behavior, so you can just select the behavior from a menu button,
 without having to type it
 
 On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode
  wrote:
> 
> I figured out how to do it in the IDE. I needed to include “of stack” in 
> the reference. — Dar
> 
>> On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode 
>>  wrote:
>> 
>> Not sure how it works in the IDE - seems a problem because it only 
>> presents button in the current stack.
>> 
>> So I do it all in preOpen... scripts, doing something like
>> 
>>> set the behavior of fld "F" of grp tmpName to the long id of button 
>>> "RichTextFieldBehaviour" of \
>>>   card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
>>> Livecode/Libraries/richText.livecode"
>> 
>> Alex.
>> 
>> On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
>>> I am misremembering things about Behaviors.
>>> 
>>> I have a card with my behavior buttons, but I can’t seem to point to 
>>> buttons on that card. Maybe, I’m remembering what I did long ago with 
>>> front scripts.
>>> 
>>> I suppose I can use substacks, but I’m worried that the stacks would be 
>>> in the message path. Is there a way to keep the stack out of the 
>>> message path?
>>> ___
>>> use-livecode mailing list
>>> use-livecode@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@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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 
 --
 On the first day, God created the heavens and the Earth
 On the second day, God created the oceans.
 On the third day, God put the animals on hold for a few hours,
 and did a little diving.
 And God said, "This is good."
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 

Re: Behaviors

[Mike Kerner via use-livecode]

i'm pretty sure you can set a dg's behavior. then you would set the
behavior of that behavior to the button behavior (button id 1005 of
stack "revDataGridLibrary"), OR you can include THAT script,
separately, set that as the behavior, and modify it
(but, what you should really do is remove your dg's and replace them
with pg's, imho. they're much faster and more flexible and powerful).
the project browser has a button for each behavior in the chain of an
object. i'm pretty sure that levure baker's assistant does, too.

On Thu, Aug 24, 2023 at 11:35 AM Bob Sneidar via use-livecode
 wrote:
>
> There is also the Advanced button in the property inspector (looks like one 
> large gear with two smaller ones) where you can type the behavior, and also 
> has the target icon. Also, you shouldn’t have to do that every time. Once 
> should be enough if you save the stack afterwards.
>
> I note that Datagrids have no way to set the behavior, since they depend on 
> their default behavior. It was discussed long ago when nested behaviors 
> became a thing, that there ought to be a way to edit a list of behaviors of 
> an object. In fact it shouldn’t be that difficult to make a Behavior Browser 
> widget of some sort. Hmmm...
>
> Bob S
>
>
> > On Aug 23, 2023, at 5:00 PM, Dar Scott via use-livecode 
> >  wrote:
> >
> > I, too, have discovered the target icon to the right of the behavior object 
> > field in the property inspector. Alas, using that that I see only buttons 
> > on the current card (and stacks). I don’t see a way to navigate to a 
> > different card and select a button there. I might have missed it. — Dar
> >
> >> On Aug 22, 2023, at 1:05 PM, Mike Kerner via use-livecode 
> >>  wrote:
> >>
> >> you probably know this: in the property inspector, there's a panel for
> >> behavior, so you can just select the behavior from a menu button,
> >> without having to type it
> >>
> >> On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode
> >>  wrote:
> >>>
> >>> I figured out how to do it in the IDE. I needed to include “of stack” in 
> >>> the reference. — Dar
> >>>
>  On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode 
>   wrote:
> 
>  Not sure how it works in the IDE - seems a problem because it only 
>  presents button in the current stack.
> 
>  So I do it all in preOpen... scripts, doing something like
> 
> > set the behavior of fld "F" of grp tmpName to the long id of button 
> > "RichTextFieldBehaviour" of \
> >card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
> > Livecode/Libraries/richText.livecode"
> 
>  Alex.
> 
>  On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
> > I am misremembering things about Behaviors.
> >
> > I have a card with my behavior buttons, but I can’t seem to point to 
> > buttons on that card. Maybe, I’m remembering what I did long ago with 
> > front scripts.
> >
> > I suppose I can use substacks, but I’m worried that the stacks would be 
> > in the message path. Is there a way to keep the stack out of the 
> > message path?
> > ___
> > use-livecode mailing list
> > use-livecode@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@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@lists.runrev.com
> >>> Please visit this url to subscribe, unsubscribe and manage your 
> >>> subscription preferences:
> >>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >>
> >>
> >> --
> >> On the first day, God created the heavens and the Earth
> >> On the second day, God created the oceans.
> >> On the third day, God put the animals on hold for a few hours,
> >>  and did a little diving.
> >> And God said, "This is good."
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@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@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@lists.runrev.com
> Please visit 

Re: Behaviors

[Bob Sneidar via use-livecode]

There is also the Advanced button in the property inspector (looks like one 
large gear with two smaller ones) where you can type the behavior, and also has 
the target icon. Also, you shouldn’t have to do that every time. Once should be 
enough if you save the stack afterwards. 

I note that Datagrids have no way to set the behavior, since they depend on 
their default behavior. It was discussed long ago when nested behaviors became 
a thing, that there ought to be a way to edit a list of behaviors of an object. 
In fact it shouldn’t be that difficult to make a Behavior Browser widget of 
some sort. Hmmm...

Bob S


> On Aug 23, 2023, at 5:00 PM, Dar Scott via use-livecode 
>  wrote:
> 
> I, too, have discovered the target icon to the right of the behavior object 
> field in the property inspector. Alas, using that that I see only buttons on 
> the current card (and stacks). I don’t see a way to navigate to a different 
> card and select a button there. I might have missed it. — Dar
> 
>> On Aug 22, 2023, at 1:05 PM, Mike Kerner via use-livecode 
>>  wrote:
>> 
>> you probably know this: in the property inspector, there's a panel for
>> behavior, so you can just select the behavior from a menu button,
>> without having to type it
>> 
>> On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode
>>  wrote:
>>> 
>>> I figured out how to do it in the IDE. I needed to include “of stack” in 
>>> the reference. — Dar
>>> 
 On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode 
  wrote:
 
 Not sure how it works in the IDE - seems a problem because it only 
 presents button in the current stack.
 
 So I do it all in preOpen... scripts, doing something like
 
> set the behavior of fld "F" of grp tmpName to the long id of button 
> "RichTextFieldBehaviour" of \
>card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
> Livecode/Libraries/richText.livecode"
 
 Alex.
 
 On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
> I am misremembering things about Behaviors.
> 
> I have a card with my behavior buttons, but I can’t seem to point to 
> buttons on that card. Maybe, I’m remembering what I did long ago with 
> front scripts.
> 
> I suppose I can use substacks, but I’m worried that the stacks would be 
> in the message path. Is there a way to keep the stack out of the message 
> path?
> ___
> use-livecode mailing list
> use-livecode@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@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@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> 
>> -- 
>> On the first day, God created the heavens and the Earth
>> On the second day, God created the oceans.
>> On the third day, God put the animals on hold for a few hours,
>>  and did a little diving.
>> And God said, "This is good."
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Dar Scott via use-livecode]

I, too, have discovered the target icon to the right of the behavior object 
field in the property inspector. Alas, using that that I see only buttons on 
the current card (and stacks). I don’t see a way to navigate to a different 
card and select a button there. I might have missed it. — Dar

> On Aug 22, 2023, at 1:05 PM, Mike Kerner via use-livecode 
>  wrote:
> 
> you probably know this: in the property inspector, there's a panel for
> behavior, so you can just select the behavior from a menu button,
> without having to type it
> 
> On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode
>  wrote:
>> 
>> I figured out how to do it in the IDE. I needed to include “of stack” in the 
>> reference. — Dar
>> 
>>> On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode 
>>>  wrote:
>>> 
>>> Not sure how it works in the IDE - seems a problem because it only presents 
>>> button in the current stack.
>>> 
>>> So I do it all in preOpen... scripts, doing something like
>>> 
 set the behavior of fld "F" of grp tmpName to the long id of button 
 "RichTextFieldBehaviour" of \
 card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
 Livecode/Libraries/richText.livecode"
>>> 
>>> Alex.
>>> 
>>> On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
 I am misremembering things about Behaviors.
 
 I have a card with my behavior buttons, but I can’t seem to point to 
 buttons on that card. Maybe, I’m remembering what I did long ago with 
 front scripts.
 
 I suppose I can use substacks, but I’m worried that the stacks would be in 
 the message path. Is there a way to keep the stack out of the message path?
 ___
 use-livecode mailing list
 use-livecode@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@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@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
> -- 
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Mike Kerner via use-livecode]

you probably know this: in the property inspector, there's a panel for
behavior, so you can just select the behavior from a menu button,
without having to type it

On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode
 wrote:
>
> I figured out how to do it in the IDE. I needed to include “of stack” in the 
> reference. — Dar
>
> > On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode 
> >  wrote:
> >
> > Not sure how it works in the IDE - seems a problem because it only presents 
> > button in the current stack.
> >
> > So I do it all in preOpen... scripts, doing something like
> >
> >> set the behavior of fld "F" of grp tmpName to the long id of button 
> >> "RichTextFieldBehaviour" of \
> >>  card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
> >> Livecode/Libraries/richText.livecode"
> >
> > Alex.
> >
> > On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
> >> I am misremembering things about Behaviors.
> >>
> >> I have a card with my behavior buttons, but I can’t seem to point to 
> >> buttons on that card. Maybe, I’m remembering what I did long ago with 
> >> front scripts.
> >>
> >> I suppose I can use substacks, but I’m worried that the stacks would be in 
> >> the message path. Is there a way to keep the stack out of the message path?
> >> ___
> >> use-livecode mailing list
> >> use-livecode@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@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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Dar Scott via use-livecode]

I figured out how to do it in the IDE. I needed to include “of stack” in the 
reference. — Dar

> On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode 
>  wrote:
> 
> Not sure how it works in the IDE - seems a problem because it only presents 
> button in the current stack.
> 
> So I do it all in preOpen... scripts, doing something like
> 
>> set the behavior of fld "F" of grp tmpName to the long id of button 
>> "RichTextFieldBehaviour" of \
>>  card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
>> Livecode/Libraries/richText.livecode"
> 
> Alex.
> 
> On 22/08/2023 17:57, Dar Scott via use-livecode wrote:
>> I am misremembering things about Behaviors.
>> 
>> I have a card with my behavior buttons, but I can’t seem to point to buttons 
>> on that card. Maybe, I’m remembering what I did long ago with front scripts.
>> 
>> I suppose I can use substacks, but I’m worried that the stacks would be in 
>> the message path. Is there a way to keep the stack out of the message path?
>> ___
>> use-livecode mailing list
>> use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Alex Tweedly via use-livecode]

Not sure how it works in the IDE - seems a problem because it only 
presents button in the current stack.


So I do it all in preOpen... scripts, doing something like

set the behavior of fld "F" of grp tmpName to the long id of button 
"RichTextFieldBehaviour" of \
 card "Behaviours" of stack "/Users/alextweedly/Dropbox/My 
Livecode/Libraries/richText.livecode"


Alex.

On 22/08/2023 17:57, Dar Scott via use-livecode wrote:

I am misremembering things about Behaviors.

I have a card with my behavior buttons, but I can’t seem to point to buttons on 
that card. Maybe, I’m remembering what I did long ago with front scripts.

I suppose I can use substacks, but I’m worried that the stacks would be in the 
message path. Is there a way to keep the stack out of the message path?
___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and scripts and a new handler structure...

[Mark Smith via use-livecode]

Hi Bob,

If you have a bit of time, could you tell us a bit more about how?

Thanks,
Mark

> On Apr 2, 2021, at 12:42 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> I have already implemented this with the help of others, for Datagrids. I 
> think it works already for other things. 
> 
> Bob S
> 
> 
>> On Apr 1, 2021, at 12:51 , Paul Dupuis via use-livecode 
>>  wrote:
>> 
>> I have increasingly been using behaviors in my applications where it makes 
>> sense to assign a script to multiple objects or to override the actions of 
>> existing script handlers by assign a behavior with different version of 
>> those handlers.
>> 
>> The one thing I dislike about behaviors is all the objects I need to create 
>> (a button for this behavior another button for that behavior script and so 
>> on).
>> 
>> I'd love to see a new LCS structure like the following:
>> 
>> behavior 
>> 
>> 
>> 
>> end 
>> 
>> that you can just have in a script. Even multiple behaviors in the same 
>> script perhaps each with their own 'mouseUp' handlers and then you can set 
>> the behavior of an object to a behavior name and done. Obviously, any 
>> messages (i.e mouseDown, mouseUp, etc. etc.) in the behavior block should 
>> never received a mouseDown, mouseUp, etc. message unless sent to the object 
>> tat have the behavior assigned to it.
>> 
>> I think it would make code maintenance potentially much easier. I don't have 
>> any idea how much of a engine change such a addition to the language would 
>> represent.
>> 
>> Anyone else think this is a good idea?
> 
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and scripts and a new handler structure...

[Bob Sneidar via use-livecode]

I have already implemented this with the help of others, for Datagrids. I think 
it works already for other things. 

Bob S


> On Apr 1, 2021, at 12:51 , Paul Dupuis via use-livecode 
>  wrote:
> 
> I have increasingly been using behaviors in my applications where it makes 
> sense to assign a script to multiple objects or to override the actions of 
> existing script handlers by assign a behavior with different version of those 
> handlers.
> 
> The one thing I dislike about behaviors is all the objects I need to create 
> (a button for this behavior another button for that behavior script and so 
> on).
> 
> I'd love to see a new LCS structure like the following:
> 
> behavior 
> 
> 
> 
> end 
> 
> that you can just have in a script. Even multiple behaviors in the same 
> script perhaps each with their own 'mouseUp' handlers and then you can set 
> the behavior of an object to a behavior name and done. Obviously, any 
> messages (i.e mouseDown, mouseUp, etc. etc.) in the behavior block should 
> never received a mouseDown, mouseUp, etc. message unless sent to the object 
> tat have the behavior assigned to it.
> 
> I think it would make code maintenance potentially much easier. I don't have 
> any idea how much of a engine change such a addition to the language would 
> represent.
> 
> Anyone else think this is a good idea?


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Bob Sneidar via use-livecode]

Not only that, I think I overthought this. All I really need to do is retrieve 
the array and then use the array elements instead of the variables. It all 
started when I began using behaviors and discovered that a behavior does not 
have access to a scripts own constants. This was a way for me to use script 
locals in both the behavior and the parent script by having the 
getStackConstants() function in each one. I'd have to replace every instance of 
a script local with an array reference, but it's probably better in the long 
run. 

Bob S


> On Jun 27, 2018, at 15:53 , Bob Sneidar via use-livecode 
>  wrote:
> 
> You know you are right. I just noticed that. That syntax of mine should not 
> have even worked LOL! Talk about a forgiving interpreter! 
> 
> Bob S
> 
> 
>> On Jun 26, 2018, at 23:25 , Dick Kriesel via use-livecode 
>>  wrote:
>> 
>>> On Jun 26, 2018, at 1:13 PM, Bob Sneidar via use-livecode 
>>>  wrote:
>>> ...
>>>   do "put " & quote &  aStackConstants [tConstant] & quote & " into " & 
>>> tConstant
>> 
>> Hi, Bob.  If you wanted simpler code, that could be just
>> 
>> do "put aStackConstants[ tConstant ] into " & tConstant
>> 
>> — Dick

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Bob Sneidar via use-livecode]

You know you are right. I just noticed that. That syntax of mine should not 
have even worked LOL! Talk about a forgiving interpreter! 

Bob S


> On Jun 26, 2018, at 23:25 , Dick Kriesel via use-livecode 
>  wrote:
> 
>> On Jun 26, 2018, at 1:13 PM, Bob Sneidar via use-livecode 
>>  wrote:
>> ...
>>do "put " & quote &  aStackConstants [tConstant] & quote & " into " & 
>> tConstant
> 
> Hi, Bob.  If you wanted simpler code, that could be just
> 
> do "put aStackConstants[ tConstant ] into " & tConstant
> 
> — Dick
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Dick Kriesel via use-livecode]

> On Jun 26, 2018, at 1:13 PM, Bob Sneidar via use-livecode 
>  wrote:
> ...
> do "put " & quote &  aStackConstants [tConstant] & quote & " into " & 
> tConstant

Hi, Bob.  If you wanted simpler code, that could be just

 do "put aStackConstants[ tConstant ] into " & tConstant

— Dick
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Bob Sneidar via use-livecode]

Yes that was my problem. Hovering or viewing the variable in the debugger while 
getStackConstants was running would show the script local variable values being 
updated, but as soon as the handler exited, they were all empty again, meaning 
the handler was not updating the script local variables, but it's own local 
variables! It was as though the script local variables did not exist yet. 

But as I mentioned quitting and restarting *seemed* to have sorted things out. 

Bob S


> On Jun 26, 2018, at 15:04 , Tom Glod via use-livecode 
>  wrote:
> 
> another thing i keep on forgetting in v9 is when you hover over variable
> names in the debugger  it shows you the value that might help these
> kinds of problems.
> 
> keep on keepin on Bob


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Tom Glod via use-livecode]

 i remember debugging a local script in a datagrid behavior and having to
figure out which index it was working on.new window would work the same
but you'd still need to give yourself that piece of data that will tell you
which one it is.

another thing i keep on forgetting in v9 is when you hover over variable
names in the debugger  it shows you the value that might help these
kinds of problems.

keep on keepin on Bob

On Tue, Jun 26, 2018 at 5:22 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hmmm... something you said set me to thinking. Suppose I already had the
> instance of a behavior opened in the script editor with a breakpoint set. I
> then execute a handler in another object with the same behavior. Which
> instance is the script editor going to show me?? Ideally, it should open a
> new script editor window for every instance, otherwise the variable watcher
> is going to produce unexpected results. It may also confuse the engine,
> which would explain why I was seeing the results I was seeing, especially
> if I was terminating execution mid handler for whatever reason.
>
> Bob S
>
>
> > On Jun 26, 2018, at 13:49 , Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Yes, well for whatever reason it's working now. I didn't change
> anything, I just quit and relaunched. It may be some kind of topstack issue
> where the topstack is changing and I don't know it's happening.
> >
> > Bob S
> >
> >
> >> On Jun 26, 2018, at 13:44 , Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> h..  look inside the preferences to the script editor. try
> to
> >> see if "variable preservation" helps you..i think its an engine
> property.
> >>
> >> On Tue, Jun 26, 2018 at 4:41 PM, Bob Sneidar via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>>
> >>>
>  On Jun 26, 2018, at 13:30 , J. Landman Gay via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> 
>  Every instance of a behavior maintains its own separate variable
> values.
> >>> This is a feature. Globals are the solution if you want them to share
> the
> >>> values.
> 
> >>>
> >>> I don't want to share the variables. I want them to be local to the
> >>> script. The trouble is, they reset as soon as the handler exits.
> Inside the
> >>> handler, they all seem to be fine! And ONLY the openStack handler
> seems to
> >>> be having the issue, because any other handler, even preOpenStack will
> >>> retain the script local values! GAH!
> >>>
> >>> Bob S
> >>>
> >>>
> >>> ___
> >>> use-livecode mailing list
> >>> use-livecode@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@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@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Bob Sneidar via use-livecode]

Hmmm... something you said set me to thinking. Suppose I already had the 
instance of a behavior opened in the script editor with a breakpoint set. I 
then execute a handler in another object with the same behavior. Which instance 
is the script editor going to show me?? Ideally, it should open a new script 
editor window for every instance, otherwise the variable watcher is going to 
produce unexpected results. It may also confuse the engine, which would explain 
why I was seeing the results I was seeing, especially if I was terminating 
execution mid handler for whatever reason. 

Bob S


> On Jun 26, 2018, at 13:49 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Yes, well for whatever reason it's working now. I didn't change anything, I 
> just quit and relaunched. It may be some kind of topstack issue where the 
> topstack is changing and I don't know it's happening. 
> 
> Bob S
> 
> 
>> On Jun 26, 2018, at 13:44 , Tom Glod via use-livecode 
>>  wrote:
>> 
>> h..  look inside the preferences to the script editor. try to
>> see if "variable preservation" helps you..i think its an engine property.
>> 
>> On Tue, Jun 26, 2018 at 4:41 PM, Bob Sneidar via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> 
>>> 
 On Jun 26, 2018, at 13:30 , J. Landman Gay via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 Every instance of a behavior maintains its own separate variable values.
>>> This is a feature. Globals are the solution if you want them to share the
>>> values.
 
>>> 
>>> I don't want to share the variables. I want them to be local to the
>>> script. The trouble is, they reset as soon as the handler exits. Inside the
>>> handler, they all seem to be fine! And ONLY the openStack handler seems to
>>> be having the issue, because any other handler, even preOpenStack will
>>> retain the script local values! GAH!
>>> 
>>> Bob S
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@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@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Bob Sneidar via use-livecode]

Yes, well for whatever reason it's working now. I didn't change anything, I 
just quit and relaunched. It may be some kind of topstack issue where the 
topstack is changing and I don't know it's happening. 

Bob S


> On Jun 26, 2018, at 13:44 , Tom Glod via use-livecode 
>  wrote:
> 
> h..  look inside the preferences to the script editor. try to
> see if "variable preservation" helps you..i think its an engine property.
> 
> On Tue, Jun 26, 2018 at 4:41 PM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 
>> 
>>> On Jun 26, 2018, at 13:30 , J. Landman Gay via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Every instance of a behavior maintains its own separate variable values.
>> This is a feature. Globals are the solution if you want them to share the
>> values.
>>> 
>> 
>> I don't want to share the variables. I want them to be local to the
>> script. The trouble is, they reset as soon as the handler exits. Inside the
>> handler, they all seem to be fine! And ONLY the openStack handler seems to
>> be having the issue, because any other handler, even preOpenStack will
>> retain the script local values! GAH!
>> 
>> Bob S
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Tom Glod via use-livecode]

h..  look inside the preferences to the script editor. try to
see if "variable preservation" helps you..i think its an engine property.

On Tue, Jun 26, 2018 at 4:41 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On Jun 26, 2018, at 13:30 , J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Every instance of a behavior maintains its own separate variable values.
> This is a feature. Globals are the solution if you want them to share the
> values.
> >
>
> I don't want to share the variables. I want them to be local to the
> script. The trouble is, they reset as soon as the handler exits. Inside the
> handler, they all seem to be fine! And ONLY the openStack handler seems to
> be having the issue, because any other handler, even preOpenStack will
> retain the script local values! GAH!
>
> Bob S
>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Tom Glod via use-livecode]

yup a feature that makes lc driven datagrid possible. :) and many other
things.

On Tue, Jun 26, 2018 at 4:30 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Every instance of a behavior maintains its own separate variable values.
> This is a feature. Globals are the solution if you want them to share the
> values.
>
>
> On 6/26/18 3:19 PM, Bob Sneidar via use-livecode wrote:
>
>> Works with globals, but not script locals.
>>
>> Bob S
>>
>>
>> On Jun 26, 2018, at 13:13 , Bob Sneidar via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> Hi all.
>>>
>>> I have a behavior script with a handler:
>>>
>>> local cTableName, cDGName, cPriKey, cAltTable1
>>>
>>> on getStackConstants pParentStack
>>>-- retrieve stack constants from stack property
>>>put the stackConstants of pParentStack into aStackConstants
>>>put the keys of aStackConstants into tConstantList
>>>
>>>repeat for each line tConstant in tConstantList
>>>   do "put " & quote &  aStackConstants [tConstant] & quote & " into
>>> " & tConstant
>>>end repeat
>>> end getStackConstants
>>>
>>> When I trace the handler, it does indeed set the values for the local
>>> variables, but as soon as the handler exits, the script local variables are
>>> all reset! This does not happen when I do the same thing in an object
>>> script. Is there something about behaviors preventing script local
>>> variables from retaining their values??
>>>
>>> Bob S
>>>
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Bob Sneidar via use-livecode]

> On Jun 26, 2018, at 13:30 , J. Landman Gay via use-livecode 
>  wrote:
> 
> Every instance of a behavior maintains its own separate variable values. This 
> is a feature. Globals are the solution if you want them to share the values.
> 

I don't want to share the variables. I want them to be local to the script. The 
trouble is, they reset as soon as the handler exits. Inside the handler, they 
all seem to be fine! And ONLY the openStack handler seems to be having the 
issue, because any other handler, even preOpenStack will retain the script 
local values! GAH!

Bob S


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[J. Landman Gay via use-livecode]

Every instance of a behavior maintains its own separate variable values. 
This is a feature. Globals are the solution if you want them to share 
the values.


On 6/26/18 3:19 PM, Bob Sneidar via use-livecode wrote:

Works with globals, but not script locals.

Bob S



On Jun 26, 2018, at 13:13 , Bob Sneidar via use-livecode 
 wrote:

Hi all.

I have a behavior script with a handler:

local cTableName, cDGName, cPriKey, cAltTable1

on getStackConstants pParentStack
   -- retrieve stack constants from stack property
   put the stackConstants of pParentStack into aStackConstants
   put the keys of aStackConstants into tConstantList

   repeat for each line tConstant in tConstantList
  do "put " & quote &  aStackConstants [tConstant] & quote & " into " & 
tConstant
   end repeat
end getStackConstants

When I trace the handler, it does indeed set the values for the local 
variables, but as soon as the handler exits, the script local variables are all 
reset! This does not happen when I do the same thing in an object script. Is 
there something about behaviors preventing script local variables from 
retaining their values??

Bob S



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not honoring script local variables??

[Bob Sneidar via use-livecode]

Works with globals, but not script locals. 

Bob S


> On Jun 26, 2018, at 13:13 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hi all. 
> 
> I have a behavior script with a handler:
> 
> local cTableName, cDGName, cPriKey, cAltTable1
> 
> on getStackConstants pParentStack
>   -- retrieve stack constants from stack property
>   put the stackConstants of pParentStack into aStackConstants
>   put the keys of aStackConstants into tConstantList
> 
>   repeat for each line tConstant in tConstantList
>  do "put " & quote &  aStackConstants [tConstant] & quote & " into " & 
> tConstant
>   end repeat
> end getStackConstants
> 
> When I trace the handler, it does indeed set the values for the local 
> variables, but as soon as the handler exits, the script local variables are 
> all reset! This does not happen when I do the same thing in an object script. 
> Is there something about behaviors preventing script local variables from 
> retaining their values??
> 
> Bob S


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Bob Sneidar via use-livecode]

Hi Devin. That actually works a peach, thanks. I'm excited about going to 
behaviors, as I have a LOT of identical code in my app and this is going to 
streamling everything a great deal. 

Bob S


> On Sep 18, 2017, at 16:23 , Devin Asay via use-livecode 
>  wrote:
> 
> Sorry, I should have said “Use 'before menuPick' or 'after menuPick' instead 
> of ‘on menuPick’.
> 
> 
> On Sep 18, 2017, at 5:21 PM, Devin Asay via use-livecode 
> > wrote:
> 
> Bob,
> 
> Maybe the best way to do this is to use the before or after control structure 
> in the behavior, rather than the menuPick.
> 
> before menuPick pItem
> # do common behavior stuff here
> end menuPick
> 
> That leaves the menuPick handler unencumbered in the actual object.
> 
> Devin
> 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Devin Asay via use-livecode]

Sorry, I should have said “Use 'before menuPick' or 'after menuPick' instead of 
‘on menuPick’.


On Sep 18, 2017, at 5:21 PM, Devin Asay via use-livecode 
> wrote:

Bob,

Maybe the best way to do this is to use the before or after control structure 
in the behavior, rather than the menuPick.

before menuPick pItem
 # do common behavior stuff here
end menuPick

That leaves the menuPick handler unencumbered in the actual object.

Devin

On Sep 18, 2017, at 5:14 PM, Bob Sneidar via use-livecode 
>
 wrote:

Hi all.

I've decided to start in on behaviors now as I have so much code that is 
effectively identical. So I took the code from a menu/button with a menuPick 
handler and put it in another button, then set the behavior of the first button 
to the long id of the second. I then set a breakpoint in the behavior script. I 
still have a menuPick handler in the first button to handle special case menu 
items for that card, but I commented out the code that is common between them.

The trouble is, selecting the menu item does not trigger the behavior. I tried 
setting pass menuPick in each one, but still no bueno. So which one gets the 
message first/at all? The behavior or the actual button?

Bob S



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Devin Asay via use-livecode]

Bob,

Maybe the best way to do this is to use the before or after control structure 
in the behavior, rather than the menuPick.

before menuPick pItem
  # do common behavior stuff here
end menuPick

That leaves the menuPick handler unencumbered in the actual object.

Devin

On Sep 18, 2017, at 5:14 PM, Bob Sneidar via use-livecode 
> wrote:

Hi all.

I've decided to start in on behaviors now as I have so much code that is 
effectively identical. So I took the code from a menu/button with a menuPick 
handler and put it in another button, then set the behavior of the first button 
to the long id of the second. I then set a breakpoint in the behavior script. I 
still have a menuPick handler in the first button to handle special case menu 
items for that card, but I commented out the code that is common between them.

The trouble is, selecting the menu item does not trigger the behavior. I tried 
setting pass menuPick in each one, but still no bueno. So which one gets the 
message first/at all? The behavior or the actual button?

Bob S



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[hh]

>> Mark wrote:
>> So... Either I'm not crazy or I've got company.
> 
> Bob wrote:
> 2 other options. Neither of you is crazy. Both of you are crazy.

These are not 'other' options!? Both cases are already included
in the listing of Mark.
Or is it a typo, did you mean "2 other options:"?


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Bob Sneidar]

2 other options. Neither of you is crazy. Both of you are crazy. What do they 
teach children in logic classes  these days?? ;-)

Bob S


On Dec 9, 2016, at 18:25 , Mark Wieder 
> wrote:

I think of them as private backscripts, available only the object to
which they are attached.

So... Either I'm not crazy or I've got company.

--
Mark Wieder

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Bleiler, Timothy]

Thanks for taking the time to explain this Mark. After I thought about it for 
awhile I expected that this would be your answer and again I’m very pleased 
with how you’ve implemented the behavior feature.


Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

> On Dec 12, 2016, at 4:38 AM, Mark Waddingham  wrote:
> 
> On 2016-12-09 19:44, Bleiler, Timothy wrote:
>> I still have one question though. Given the part of your answer I
>> quoted above, why does the “pass” control structure trigger handlers
>> along the behavior chain rather than skipping over them and going to
>> the next object in the ownership chain?
> 
> Because it is helpful for it to do so.
> 
> Either 'pass' could act as you say and skip the entire behavior chain; or it 
> could do as it currently does and pass to the next script in the list of 
> things which might want to process the message.
> 
> Given the utility of pass in the exisiting message path, it seemed sensible 
> that it should do the 'similar' thing in the behavior chain. As currently 
> implemented, it means that you can get a whole list of things to 'do 
> something' on a particular event; should each one pass (just as you can with 
> the 'normal' message path).
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Mark Waddingham]

On 2016-12-09 19:44, Bleiler, Timothy wrote:

I still have one question though. Given the part of your answer I
quoted above, why does the “pass” control structure trigger handlers
along the behavior chain rather than skipping over them and going to
the next object in the ownership chain?


Because it is helpful for it to do so.

Either 'pass' could act as you say and skip the entire behavior chain; 
or it could do as it currently does and pass to the next script in the 
list of things which might want to process the message.


Given the utility of pass in the exisiting message path, it seemed 
sensible that it should do the 'similar' thing in the behavior chain. As 
currently implemented, it means that you can get a whole list of things 
to 'do something' on a particular event; should each one pass (just as 
you can with the 'normal' message path).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[J. Landman Gay]

Actually I got the idea from you.  But so far it seems to hold.

Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On December 9, 2016 8:27:18 PM Mark Wieder  wrote:


On 12/09/2016 03:15 PM, J. Landman Gay wrote:

On 12/9/16 4:47 PM, mwieder wrote:

But at any rate, I believe conflating "extending" a script with
"concatenation" is the wrong way to think about behaviors.


I think of them as private backscripts, available only the object to
which they are attached.


So... Either I'm not crazy or I've got company.

--
  Mark Wieder
  ahsoftw...@gmail.com



___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Mark Wieder]

On 12/09/2016 03:15 PM, J. Landman Gay wrote:

On 12/9/16 4:47 PM, mwieder wrote:

But at any rate, I believe conflating "extending" a script with
"concatenation" is the wrong way to think about behaviors.


I think of them as private backscripts, available only the object to
which they are attached.


So... Either I'm not crazy or I've got company.

--
 Mark Wieder
 ahsoftw...@gmail.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[J. Landman Gay]

On 12/9/16 4:47 PM, mwieder wrote:

But at any rate, I believe conflating "extending" a script with
"concatenation" is the wrong way to think about behaviors.


I think of them as private backscripts, available only the object to 
which they are attached. If the behavior doesn't catch a messages, the 
message continues on to the next object after the backscript's owner.


One thing that surprised me recently was a behavior attached to a shared 
background field. A mouseUp message activated when I didn't expect it 
to. I finally realized that because the behavior was attached to a 
background field, it was being triggered after the card controls. I set 
the field's backgroundBehavior to false (but left the shared property 
true) and the unexpected responses stopped because the field was now a 
card object.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[mwieder]

Tim Bleiler wrote
> Maybe I didn’t explain what I’m actually doing correctly or we’re just
> doing something different, but after I assign the behavior I do NOT get
> the same result.

Er...yes, you're right. That's what happens when I try to multitask and type
without thinking.
The other project I was multitasking on didn't work that well either. :=P

Go by what I said earlier about overriding, ignore the bit about scoping.

But at any rate, I believe conflating "extending" a script with
"concatenation" is the wrong way to think about behaviors.



-
-- 
 Mark Wieder
 ahsoftw...@gmail.com
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Behaviors-and-the-message-path-tp4710941p4710975.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Behaviors and the message path

[Ralph DiMola]

"Me Too"...
Also, thanks to Tim for putting all these combinations in the lab and
reporting the results back to the community. I learned something valuable!

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Friday, December 09, 2016 3:22 PM
To: How to use LiveCode
Subject: Re: Behaviors and the message path

On 12/9/16 1:49 PM, mwieder wrote:
> ...and I want to echo your appreciation of Mr. Waddingham's 
> stewardship of the xtalk legacy. I have argued (and will continue to 
> do so) with him about fine points of interpretation and future 
> direction of the language, but I always appreciate his constant 
> conservative approach to making changes and his overview of how
modifications might affect the entire ecosystem.

Amen. I know that sounds like a "me too" but it deserves repetition. 
He's a marvel.

-- 
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Bleiler, Timothy]

> On Dec 9, 2016, at 2:44 PM, mwieder  wrote:
> 
> I think it's wrong to consider behavior scripts as concatenated onto the end
> of a script. If you rather think of the behavior script as a library or
> backscript, then the message path becomes a little clearer.


Thinking of behaviors as a library/backscript or concatenated onto the end of 
the owner script both end up missing some important characteristics of 
behaviors. Mark Waddingham in his reply used a different term, which in my head 
can encompass the full range. Mark said, “... behaviors aren't really objects - 
they are script extensions (for want of a better term).” 
 

> In your example 2, the message "you are in Script 3" appears because that 
> instance of
> ASharedHandlerName is in the same scope as TestScript, so it gets priority.
> If you then assign the behavior, you still have the same result.

Maybe I didn’t explain what I’m actually doing correctly or we’re just doing 
something different, but after I assign the behavior I do NOT get the same 
result. I get a result that I think is consistent with Mark Waddingham’s 
explanation that the engine treats the “first” object in the behavior chain as 
the only “real" object and so begins processing any message within the behavior 
chain at the object that is returned as “Me” in any behavior scripts.


> What happens when you uncomment the pass command is that control then passed
> out of the Button A object into the next item down the message path, which
> will be the behavior object. You should also have (untested because lazy)
> the same result without assigning the behavior: you will get "you are in
> Button A" followed by a "pass" statement that eventually ends up at the card
> script and triggers "you are in Script 3”.

I agree with you on this one and it doesn’t seem to fit with my understanding 
of Mark Waddingham’s explanation so I posted another question about this 
specifically. 


Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[J. Landman Gay]

On 12/9/16 1:49 PM, mwieder wrote:

...and I want to echo your appreciation of Mr. Waddingham's stewardship of
the xtalk legacy. I have argued (and will continue to do so) with him about
fine points of interpretation and future direction of the language, but I
always appreciate his constant conservative approach to making changes and
his overview of how modifications might affect the entire ecosystem.


Amen. I know that sounds like a "me too" but it deserves repetition. 
He's a marvel.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[mwieder]

...and I want to echo your appreciation of Mr. Waddingham's stewardship of
the xtalk legacy. I have argued (and will continue to do so) with him about
fine points of interpretation and future direction of the language, but I
always appreciate his constant conservative approach to making changes and
his overview of how modifications might affect the entire ecosystem.



-
-- 
 Mark Wieder
 ahsoftw...@gmail.com
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Behaviors-and-the-message-path-tp4710941p4710969.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[mwieder]

Tim-

I think it's wrong to consider behavior scripts as concatenated onto the end
of a script. If you rather think of the behavior script as a library or
backscript, then the message path becomes a little clearer. In your example
2, the message "you are in Script 3" appears because that instance of
ASharedHandlerName is in the same scope as TestScript, so it gets priority.
If you then assign the behavior, you still have the same result.

What happens when you uncomment the pass command is that control then passed
out of the Button A object into the next item down the message path, which
will be the behavior object. You should also have (untested because lazy)
the same result without assigning the behavior: you will get "you are in
Button A" followed by a "pass" statement that eventually ends up at the card
script and triggers "you are in Script 3".



-
-- 
 Mark Wieder
 ahsoftw...@gmail.com
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Behaviors-and-the-message-path-tp4710941p4710968.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Bleiler, Timothy]

On Dec 9, 2016, at 12:56 PM, Mark Waddingham 
> wrote:

Rule (2) preserves this semantic for behaviors and, indeed, codifies the fact 
that behaviors aren't really objects - they are script extensions (for want of 
a better term).

Thank you Mark, your explanation is very helpful. I’m reminded again how much I 
appreciate your excellent stewardship of the language.

I still have one question though. Given the part of your answer I quoted above, 
why does the “pass” control structure trigger handlers along the behavior chain 
rather than skipping over them and going to the next object in the ownership 
chain?



Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Mark Waddingham]

On 2016-12-08 21:23, Bleiler, Timothy wrote:

I’m curious about what appears to me to be a confusing aspect of the
implementation of behaviors. In short, behaviors have characteristics
of an isolated, local extension of the message path AND
characteristics of a concatenation of the parent control’s script. I’m
raising the issue for two reasons: 1) to clarify how to explain
behaviors to someone new to Livecode or just learning about the
feature and 2) to question if all the features of behaviors are
intentional or if some might be accidents of implementation and
therefore may be eliminated in the future.


The design of behaviors was to allow sharing of code amongst controls. 
Indeed, the premise was that, given any control A, the following steps 
would cause no change in functionality of A:


  1) create button B
  2) set the script of button B to the script of control A
  3) set the script of control A to empty
  4) set the behavior of control A to the long id of button B

In order for this to be the case, two things have to be true:

  1) Behaviors must keep a 'private' copy of their script locals for 
each control using that behavior


  2) 'me' must always resolve to the control using the behavior, even 
when in the behavior script


The key thing here is that when you call a handler from a script, unless 
it is bound to a private handler in the same script, the request will 
pass through the message path targeting 'me' - so first frontScripts 
will trigger, then me, then the owner of me etc. Rule (2) preserves this 
semantic for behaviors and, indeed, codifies the fact that behaviors 
aren't really objects - they are script extensions (for want of a better 
term).


The reason you see friction between what happens in the behavior chain, 
and what happens in the ownership chain simply comes down to the fact 
that when considering the ownership chain you are dealing with multiple 
distinct objects and thus there is more than one object which is being 
targetted by messages. In contrast, when you are considering the 
behavior chain there is only ever a single real object - the control 
using the chain - thus there is only one thing that can be the target of 
message sends.


Hope this helps,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Bleiler, Timothy]

On Dec 8, 2016, at 10:31 PM, Mark Wieder 
> wrote:
I think the best explanation of the message path is still Richard Gaskin's 
chart and web page. Although I have to give props to Dar Scott for his message 
primer as well.

I tend to think of behavior scripts (and I know there are other viewpoints on 
this, so ymmv) as private backscripts fitting into the message path right 
behind the objects that use them. And in that sense behavior scripts have the 
same functionality as other library scripts:

behavior handlers extend the functionality of an object or a group of similar 
objects

behaviors can be chained: for me this makes them more useful than substacks, 
since you can't have substacks of substacks, but behaviors allow me to have a 
library with compartmentalized functionality, i.e., a math library with a 
special section for imaginary or complex numbers.

behavior handlers can be overridden: a handler in the library script is in the 
message path unless a handler of the same name is earlier in the message path

Thanks again, Mark. Your conceptualization matches how I thought about 
behaviors until recently. I may not have accurately communicated exactly what 
I’ve seen, so I’ll take Mike Kerner’s advice and provide a couple of examples. 
Just to be clear - I don’t have a problem with behaviors, I don’t think there’s 
anything wrong with the current implementation of behaviors, and I’m not 
advocating for any changes. In fact, I think it’s pretty clever. I just wanted 
to make sure that this is the intended design and if it is, to highlight the 
potential power and complexity of behaviors that can easily be missed.

Example 1

Script of Button A
on mouseUp
   TestScript
end mouseUp

Command ScriptInA1
   Answer "you are in Button A"
end ScriptInA1

Script 2
command TestScript
   ScriptInA1
end TestScript

Given the script of button A and that script 2 is the script of the card that 
owns button A, then a mouseUp on Button A will result in a “can’t find handler 
error” when line 2 of script 2 is reached in the card. This is consistent with 
the traditional Livecode control based message path. Alternatively, if the 
behavior of Button A is set to a button with script 2, then the engine finds 
the script in button A and there is no error. This is consistent with the 
concept that script 2 is concatenated onto the end of the script of Button A. 
It is inconsistent with the traditional message path.


Example 2

Script of Button A
on mouseUp
   TestScript
end mouseUp

Command ASharedHandlerName
   Answer "you are in Button A"
   # pass ASharedHandlerName
end ASharedHandlerName

Script 3
command TestScript
   ASharedHandlerName
end TestScript

Command ASharedHandlerName
   Answer "you are in Script 3"
end ASharedHandlerName

Given the script of button A and that script 3 is the script of the card that 
owns button A, then a mouseUp on Button A will result in an answer dialog with 
“You are in Script 3” as the prompt. This is consistent with the traditional 
Livecode control based message path. Alternatively, if the behavior of Button A 
is set to a button with script 3 and you think that behaviors are a private 
message path as Mark described, you would expect that you’d still get an answer 
dialog with “You are in Script 3” as the prompt just like when script 3 was the 
card script; but you’d be wrong. Instead you get an answer dialog with the “you 
are in Button A” prompt, consistent with the idea that script 3 is concatenated 
onto the end of the script of button A rather than being the next step in the 
message path. Making things even more interesting - leaving script 3 as a 
behavior of Button A, if you uncomment the “pass” control structure in the 
script of button A, then a mouseUp on Button A will result in 
“ASharedHandlerName” being executed from Button A and then “ASharedHandlerName” 
executed in the behavior script in Script 3. This is a combination of the 
traditional message path and a concatenation of Script 3 with the script of 
Button A.

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Mark Wieder]

On 12/08/2016 04:40 PM, Bleiler, Timothy wrote:


Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my post. I 
agree, there are terrific benefits with the current implementation of the behavior 
feature. My main concern was insuring that what I observed was intended. If everything I 
described is by design, then the “inconsistencies” I noted are in my conceptual model of 
the language (extended object message path vs concatenation of scripts). Is there a 
better model that accounts for how the engine implements behaviors than an unpredictable 
combination of the two I’ve identified? An oversimplified understanding of how the engine 
processes scripts can get even experienced developers into trouble. The dictionary entry 
on "behavior" only hints at the full power of the feature and it might be 
difficult to expand it without invoking an accurate model of the engine’s rule set for 
behaviors.


I think the best explanation of the message path is still Richard 
Gaskin's chart and web page. Although I have to give props to Dar Scott 
for his message primer as well.


I tend to think of behavior scripts (and I know there are other 
viewpoints on this, so ymmv) as private backscripts fitting into the 
message path right behind the objects that use them. And in that sense 
behavior scripts have the same functionality as other library scripts:


behavior handlers extend the functionality of an object or a group of 
similar objects


behaviors can be chained: for me this makes them more useful than 
substacks, since you can't have substacks of substacks, but behaviors 
allow me to have a library with compartmentalized functionality, i.e., a 
math library with a special section for imaginary or complex numbers.


behavior handlers can be overridden: a handler in the library script is 
in the message path unless a handler of the same name is earlier in the 
message path


--
 Mark Wieder
 ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Mike Kerner]

I think I need an example, because I'm not understanding the problem that
you're having with the currentbehavior

On Thu, Dec 8, 2016 at 7:40 PM, Bleiler, Timothy 
wrote:

> > On Dec 8, 2016, at 5:09 PM, mwieder  wrote:
> >
> > I don't see these as anomalies or inconsistencies, but as features that
> help
> > implement proper object-oriented behavior. Tim- what "problems" do you
> see
> > with the way this is implemented? Am I missing something?
>
>
> Thanks Mark. I probably shouldn’t have used the word “problems” anywhere
> in my post. I agree, there are terrific benefits with the current
> implementation of the behavior feature. My main concern was insuring that
> what I observed was intended. If everything I described is by design, then
> the “inconsistencies” I noted are in my conceptual model of the language
> (extended object message path vs concatenation of scripts). Is there a
> better model that accounts for how the engine implements behaviors than an
> unpredictable combination of the two I’ve identified? An oversimplified
> understanding of how the engine processes scripts can get even experienced
> developers into trouble. The dictionary entry on "behavior" only hints at
> the full power of the feature and it might be difficult to expand it
> without invoking an accurate model of the engine’s rule set for behaviors.
>
> Tim Bleiler, Ph.D.
> Instructional Designer, HSIT
> University at Buffalo
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors and the message path

[Bleiler, Timothy]

> On Dec 8, 2016, at 5:09 PM, mwieder  wrote:
> 
> I don't see these as anomalies or inconsistencies, but as features that help
> implement proper object-oriented behavior. Tim- what "problems" do you see
> with the way this is implemented? Am I missing something?


Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my 
post. I agree, there are terrific benefits with the current implementation of 
the behavior feature. My main concern was insuring that what I observed was 
intended. If everything I described is by design, then the “inconsistencies” I 
noted are in my conceptual model of the language (extended object message path 
vs concatenation of scripts). Is there a better model that accounts for how the 
engine implements behaviors than an unpredictable combination of the two I’ve 
identified? An oversimplified understanding of how the engine processes scripts 
can get even experienced developers into trouble. The dictionary entry on 
"behavior" only hints at the full power of the feature and it might be 
difficult to expand it without invoking an accurate model of the engine’s rule 
set for behaviors.

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Behaviors and the message path

[mwieder]

(Different Mark here, but...)

Yes, that's by design and explicitly to allow for overriding.
It's *very* useful, for example, for setting up default behavior in a
behavior script and then selectively overriding that in some, but not all,
the objects that use that behavior script.

The issue of script-local variables only being available in the behavior
script is also by design, and is consistent with the way script-local
variables work in any script. It also enforces the scope of encapsulated
data in the objects in the message path.

I don't see these as anomalies or inconsistencies, but as features that help
implement proper object-oriented behavior. Tim- what "problems" do you see
with the way this is implemented? Am I missing something?



-
-- 
 Mark Wieder
 ahsoftw...@gmail.com
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Behaviors-and-the-message-path-tp4710941p4710943.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Behaviors and the message path

[Ralph DiMola]

> Tim Bleiler, Ph.D. wrote
>if the same handler name is present in the behavior script and the parent 
>script, the parent script handler is >the one that runs.

Wow! This is good to know. This could be very handy overriding a behavior 
handler for a specific control. As you said, there seems to be a message path 
conundrum here. I'm interested what Mark might have to say on this.


Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Bleiler, Timothy
Sent: Thursday, December 08, 2016 3:24 PM
To: How to use LiveCode
Subject: Behaviors and the message path

I’m curious about what appears to me to be a confusing aspect of the 
implementation of behaviors. In short, behaviors have characteristics of an 
isolated, local extension of the message path AND characteristics of a 
concatenation of the parent control’s script. I’m raising the issue for two 
reasons: 1) to clarify how to explain behaviors to someone new to Livecode or 
just learning about the feature and 2) to question if all the features of 
behaviors are intentional or if some might be accidents of implementation and 
therefore may be eliminated in the future.

I’ve used behaviors since they were first introduced and it’s worked well for 
me to think of them as an extension of the message path from the parent 
control. However, I recently discovered that a command in a behavior script can 
directly call a handler in the parent script. Furthermore, if the same handler 
name is present in the behavior script and the parent script, the parent script 
handler is the one that runs. This capability is consistent with 
conceptualizing the behavior script as a concatenation with the parent script 
and contradicts the idea that behaviors are an extension of the message path. 

However, script level variables in a behavior are accessible only in the object 
script in which they are declared, consistent with the idea of an extended 
message path. Finally, If a handler with the same name exists in the parent 
script and a behavior script, it’s possible to execute the handler in the 
behavior either after the parent version runs or instead of the parent version 
by treating the behavior script as an independent step in the message path and 
using control structures like “pass”, “send” and “dispatch”. There may be more 
of the these types of inconsistencies but that seems more than enough to 
provoke some discussion on this list. I realize that any problems with these 
features of behaviors can easily be avoided by common sense design but some 
discussion seems warranted for the reasons I cited above. Anybody want to weigh 
in on this?

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not behaving

[Peter Haworth]

On Mon, Dec 1, 2014 at 12:13 PM, Peter Haworth p...@lcsql.com wrote:

 Good news is that your trick of resetting the behaviors to themselves
 fixed the problem!  And it's really fast. Thanks for that.


I guess I spoke too soon.

Although the fix does work, controls with linked behaviors are now
misbehaving.  The second behavior in the chain works for some controls but
not for others.  So, goodbye linked behaviors.  Replaced them with a call
to a library handler.

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not behaving

[Scott Rossi]

From what you describe, there may be a timing thing going on as you suggest 
(controls opening before their behaviors are available).  You say your plugin 
“creates an application stack file” so another thing to check is correct 
behavior references applied to your controls.

If your behaviors need to initialize at all, you should double check your 
initializing routines are taking place — if not, there may be some script 
error/failure going on that’s not triggering a standard alert.

Another “trick” you might try is to force the behaviors to resolve after all 
stacks are open by running a loop through all controls that use behaviors and 
set the behavior of each control to its behavior.  Kind of goofy but assuming 
there are no reference issues, it should work.

Regards,

Scott Rossi 
Creative Director 
Tactile Media, UX/UI Design 

On Dec 1, 2014, at 10:31 AM, Peter Haworth p...@lcsql.com wrote:

 I'm working on a system that consists of a plugin, a library stack file and
 a stack file containing buttons with behavior scripts.
 
 The plugin creates an application stack file plus various controls within
 it that have their behaviors set to the buttons in the behavior stack file.
 
 Since the behaviors are not in the application stack file, I set the
 stackFiles property of the application stack to have an entry referencing
 the behaviors stack file.
 
 That setup all works fine most of the time, behaviors are resolved as they
 should be. However, on any subsequent runs of LC, if I open the plugin
 first then open the application file, none of the behavior scripts fire.
 All works fine if I open the application stack file first followed by the
 plugin.
 
 There are no references to the behaviors stack file in any of the plugin
 scripts or the library stack scripts and the plugin's stackFiles entry is
 empty as is the library stack's.
 
 I tried opening the behaviors stack file in the plugin so that it would be
 open when I opened the application stack but the behaviors still did not
 fire.
 
 What could there be in the plugin stack that would interfere with the
 resolution of behaviors in the application stack?
 
 Pete
 lcSQL Software http://www.lcsql.com
 Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
 SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
 ___
 use-livecode mailing list
 use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Behaviors not behaving

[Ralph DiMola]

Peter,

I run into this when I double click on a stack to open the IDE. My library
stacks are not yet fully loaded and calls to them fail. The trick for me is
to load the IDE then load the stack I'm working on. This only applies to the
library stacks in the MyLiveCode/Plugins folder when running in the IDE.
When running as standalone I load the library stacks in the preopenstack of
the main stack.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Peter Haworth
Sent: Monday, December 01, 2014 1:32 PM
To: How to use LiveCode
Subject: Behaviors not behaving

I'm working on a system that consists of a plugin, a library stack file and
a stack file containing buttons with behavior scripts.

The plugin creates an application stack file plus various controls within it
that have their behaviors set to the buttons in the behavior stack file.

Since the behaviors are not in the application stack file, I set the
stackFiles property of the application stack to have an entry referencing
the behaviors stack file.

That setup all works fine most of the time, behaviors are resolved as they
should be. However, on any subsequent runs of LC, if I open the plugin first
then open the application file, none of the behavior scripts fire.
All works fine if I open the application stack file first followed by the
plugin.

There are no references to the behaviors stack file in any of the plugin
scripts or the library stack scripts and the plugin's stackFiles entry is
empty as is the library stack's.

I tried opening the behaviors stack file in the plugin so that it would be
open when I opened the application stack but the behaviors still did not
fire.

What could there be in the plugin stack that would interfere with the
resolution of behaviors in the application stack?

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not behaving

[Peter Haworth]

Hi Ralph,
Might be a related issue but in this case, I'm opening stacks from within
the IDE not by double clicking them in the Finder.

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html

On Mon, Dec 1, 2014 at 11:06 AM, Ralph DiMola rdim...@evergreeninfo.net
wrote:

 Peter,

 I run into this when I double click on a stack to open the IDE. My library
 stacks are not yet fully loaded and calls to them fail. The trick for me is
 to load the IDE then load the stack I'm working on. This only applies to
 the
 library stacks in the MyLiveCode/Plugins folder when running in the IDE.
 When running as standalone I load the library stacks in the preopenstack of
 the main stack.

 Ralph DiMola
 IT Director
 Evergreen Information Services
 rdim...@evergreeninfo.net

 -Original Message-
 From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
 Behalf
 Of Peter Haworth
 Sent: Monday, December 01, 2014 1:32 PM
 To: How to use LiveCode
 Subject: Behaviors not behaving

 I'm working on a system that consists of a plugin, a library stack file and
 a stack file containing buttons with behavior scripts.

 The plugin creates an application stack file plus various controls within
 it
 that have their behaviors set to the buttons in the behavior stack file.

 Since the behaviors are not in the application stack file, I set the
 stackFiles property of the application stack to have an entry referencing
 the behaviors stack file.

 That setup all works fine most of the time, behaviors are resolved as they
 should be. However, on any subsequent runs of LC, if I open the plugin
 first
 then open the application file, none of the behavior scripts fire.
 All works fine if I open the application stack file first followed by the
 plugin.

 There are no references to the behaviors stack file in any of the plugin
 scripts or the library stack scripts and the plugin's stackFiles entry is
 empty as is the library stack's.

 I tried opening the behaviors stack file in the plugin so that it would be
 open when I opened the application stack but the behaviors still did not
 fire.

 What could there be in the plugin stack that would interfere with the
 resolution of behaviors in the application stack?

 Pete
 lcSQL Software http://www.lcsql.com
 Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
 SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
 ___
 use-livecode mailing list
 use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors not behaving

[Peter Haworth]

Hi Scott,
I stepped through my initialization code and it all goes through to the end
no matter which stack I open first.

Good news is that your trick of resetting the behaviors to themselves fixed
the problem!  And it's really fast. Thanks for that.

I'm still not understanding why that should be necessary but I guess at
this point, I'll just go with it.

I seem to recall that Richard Gaskin has an enhancement request to provide
a command to initialize behaviors.  In view of this weirdness, I think that
would be a great idea.

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html

On Mon, Dec 1, 2014 at 10:47 AM, Scott Rossi sc...@tactilemedia.com wrote:

 From what you describe, there may be a timing thing going on as you
 suggest (controls opening before their behaviors are available).  You say
 your plugin “creates an application stack file” so another thing to check
 is correct behavior references applied to your controls.

 If your behaviors need to initialize at all, you should double check your
 initializing routines are taking place — if not, there may be some script
 error/failure going on that’s not triggering a standard alert.

 Another “trick” you might try is to force the behaviors to resolve after
 all stacks are open by running a loop through all controls that use
 behaviors and set the behavior of each control to its behavior.  Kind of
 goofy but assuming there are no reference issues, it should work.

 Regards,

 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design

 On Dec 1, 2014, at 10:31 AM, Peter Haworth p...@lcsql.com wrote:

  I'm working on a system that consists of a plugin, a library stack file
 and
  a stack file containing buttons with behavior scripts.
 
  The plugin creates an application stack file plus various controls within
  it that have their behaviors set to the buttons in the behavior stack
 file.
 
  Since the behaviors are not in the application stack file, I set the
  stackFiles property of the application stack to have an entry referencing
  the behaviors stack file.
 
  That setup all works fine most of the time, behaviors are resolved as
 they
  should be. However, on any subsequent runs of LC, if I open the plugin
  first then open the application file, none of the behavior scripts fire.
  All works fine if I open the application stack file first followed by the
  plugin.
 
  There are no references to the behaviors stack file in any of the plugin
  scripts or the library stack scripts and the plugin's stackFiles entry is
  empty as is the library stack's.
 
  I tried opening the behaviors stack file in the plugin so that it would
 be
  open when I opened the application stack but the behaviors still did not
  fire.
 
  What could there be in the plugin stack that would interfere with the
  resolution of behaviors in the application stack?
 
  Pete
  lcSQL Software http://www.lcsql.com
  Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
  SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
  ___
  use-livecode mailing list
  use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Scott Rossi]

Hi Pete:

Not sure if this is true in your case, but one reason why this can
sometimes happen is if, for whatever reason, a control that has a behavior
assigned to it gets opened before is associated behavior is present in
memory.  You might check if there is any delay occurring when launching
the library stack. 

You can usually get around this without exiting LiveCode by using a script
to set a control's behavior to the same behavior reference.  You can also
try setting the control's behavior to empty first.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 9/24/14 3:46 PM, Peter Haworth p...@lcsql.com wrote:

I'm working with lots of controls that have behaviors.  The behavior
buttons are all in a library stack.  All works fine most of the time but
every now and again, none of the behavior scripts are executed (as
verified
with breakpoints at the start of them).  The message box shows the library
stack is still in use and the behavior properties all look valid

I can't pin down exactly what causes this but I think that editing a lot
of
the behavior scripts might cause this, but I'm pretty sure that shouldn't
happen. When it happens, the only way to get the behaviors to work again
is
to quit LC and run again.

Anyone else's applications' guilty of bad behavior like this and if so is
there a way to correct their behavior?

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Richard Gaskin]

Peter Haworth wrote:

Anyone else's applications' guilty of bad behavior like this and if so is
there a way to correct their behavior?


May be relevant:

Behavior resolution is too strict and is confusing
http://quality.runrev.com/show_bug.cgi?id=8993

The only workaround I've used is to walk through all objects, setting 
their behavior property to the value of their behavior property.  Yes, 
silly, but it works.  It's like behaviors need a kick start under 
certain circumstances.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Peter Haworth]

Thanks Scott.  I've come across that situation before but this is
different.  The behaviors all work fine when the stack is first opened,
 Then, after some time using the stack and adding new controls which refer
to the behaviors, the behaviors suddenly stop being resolved.

I'd file a QCC report but I don't have a reliable recipe to reproduce the
problem.

I recall seeing a post a while back suggesting it would be good to have a
method of re-connecting behaviors when things like this happen.

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html

On Wed, Sep 24, 2014 at 4:08 PM, Scott Rossi sc...@tactilemedia.com wrote:

 Hi Pete:

 Not sure if this is true in your case, but one reason why this can
 sometimes happen is if, for whatever reason, a control that has a behavior
 assigned to it gets opened before is associated behavior is present in
 memory.  You might check if there is any delay occurring when launching
 the library stack.

 You can usually get around this without exiting LiveCode by using a script
 to set a control's behavior to the same behavior reference.  You can also
 try setting the control's behavior to empty first.

 Regards,

 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design




 On 9/24/14 3:46 PM, Peter Haworth p...@lcsql.com wrote:

 I'm working with lots of controls that have behaviors.  The behavior
 buttons are all in a library stack.  All works fine most of the time but
 every now and again, none of the behavior scripts are executed (as
 verified
 with breakpoints at the start of them).  The message box shows the library
 stack is still in use and the behavior properties all look valid
 
 I can't pin down exactly what causes this but I think that editing a lot
 of
 the behavior scripts might cause this, but I'm pretty sure that shouldn't
 happen. When it happens, the only way to get the behaviors to work again
 is
 to quit LC and run again.
 
 Anyone else's applications' guilty of bad behavior like this and if so is
 there a way to correct their behavior?
 
 Pete
 lcSQL Software http://www.lcsql.com
 Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
 SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
 ___
 use-livecode mailing list
 use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Peter Haworth]

Hi Richard,
Our posts crossed, thanks for the QCC reference.

Your QCC report describes a situation very similar to mine - using a
library stack to hold the behaviors.  However, my behaviors start off
behaving themselves and only start misbehaving at some point later in using
the stack.

I think perhaps the library problem is not biting me because I set up a
reference to the library stack in my mainstack's stackFiles property.
Maybe that forces the library stack to be opened in time for the behaviors
to be resolved?  I still issue a start using command because the library
has a bunch of handlers in it in addition to the behavior buttons.

In spite of all that I agree with your QCC report and have added myself to
the list of interested folks.  Mark's solution seems to be a nice way to
resolve it.

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html

On Wed, Sep 24, 2014 at 4:11 PM, Richard Gaskin ambassa...@fourthworld.com
wrote:

 Peter Haworth wrote:

 Anyone else's applications' guilty of bad behavior like this and if so is
 there a way to correct their behavior?


 May be relevant:

 Behavior resolution is too strict and is confusing
 http://quality.runrev.com/show_bug.cgi?id=8993

 The only workaround I've used is to walk through all objects, setting
 their behavior property to the value of their behavior property.  Yes,
 silly, but it works.  It's like behaviors need a kick start under certain
 circumstances.

 --
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  
  ambassa...@fourthworld.comhttp://www.FourthWorld.com


 ___
 use-livecode mailing list
 use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Monte Goulding]

On 25 Sep 2014, at 10:06 am, Peter Haworth p...@lcsql.com wrote:

 The behaviors all work fine when the stack is first opened,
 Then, after some time using the stack and adding new controls which refer
 to the behaviors, the behaviors suddenly stop being resolved.

Hmm... behaviors are stored as an id and a stack name. If they are resolved 
already the only way I can thing they might stop being resolved is if something 
is changing either of those things about the behavior button.

There was at one time an idea to expose a resolveBehaviors command but I think 
Mark Waddingham had some other ideas he wanted to look at to make it more 
automatic. It certainly would be lovely to be able to change a stack name 
without having to set all the behaviors again...

Cheers

Monte

--
M E R Goulding 
Software development services
Bespoke application development for vertical markets

mergExt - There's an external for that!

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Behaviors

[Ralph DiMola]

Peter,

If this only happens in the IDE it might be related to bug
http://quality.runrev.com/show_bug.cgi?id=12508 
I couldn't nail this one down until today. I created a recipe for support.
Hanson reproduced it in the lab.


Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Peter Haworth
Sent: Wednesday, September 24, 2014 6:47 PM
To: How to use LiveCode
Subject: Behaviors

I'm working with lots of controls that have behaviors.  The behavior buttons
are all in a library stack.  All works fine most of the time but every now
and again, none of the behavior scripts are executed (as verified with
breakpoints at the start of them).  The message box shows the library stack
is still in use and the behavior properties all look valid

I can't pin down exactly what causes this but I think that editing a lot of
the behavior scripts might cause this, but I'm pretty sure that shouldn't
happen. When it happens, the only way to get the behaviors to work again is
to quit LC and run again.

Anyone else's applications' guilty of bad behavior like this and if so is
there a way to correct their behavior?

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Peter Haworth]

Thanks Monte.  Richard posted the link to the QCC report for the
resolveBehaviors enhancement and Mark's subsequent thoughts on it.

I don't think anything about the behaviors is being changed.  That's born
out by the fact that if I quit LC and re-run with the same stack,
everything works again.

There's another scenario that might be causing this.  I occasionally stop
code execution in the midst of stepping through code in debug mode.  In the
past, I've noticed odd side effects from doing that so maybe this is
another one of them.  I'
ll try to pay more attention to things I do in this stack to help pin it
down.

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html

On Wed, Sep 24, 2014 at 5:17 PM, Monte Goulding mo...@sweattechnologies.com
 wrote:


 On 25 Sep 2014, at 10:06 am, Peter Haworth p...@lcsql.com wrote:

  The behaviors all work fine when the stack is first opened,
  Then, after some time using the stack and adding new controls which refer
  to the behaviors, the behaviors suddenly stop being resolved.

 Hmm... behaviors are stored as an id and a stack name. If they are
 resolved already the only way I can thing they might stop being resolved is
 if something is changing either of those things about the behavior button.

 There was at one time an idea to expose a resolveBehaviors command but I
 think Mark Waddingham had some other ideas he wanted to look at to make it
 more automatic. It certainly would be lovely to be able to change a stack
 name without having to set all the behaviors again...

 Cheers

 Monte

 --
 M E R Goulding
 Software development services
 Bespoke application development for vertical markets

 mergExt - There's an external for that!

 ___
 use-livecode mailing list
 use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Behaviors

[Peter Haworth]

Thanks Ralph, I'll check into that.  This happens in a plugin so there
won't ever be a standalone to check.  And of course it's in one that is
about to go into beta proving yet again that those little buglets just bide
their time before surfacing at a time that guarantees they cause the most
frustration :-)

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html

On Wed, Sep 24, 2014 at 5:38 PM, Ralph DiMola rdim...@evergreeninfo.net
wrote:

 Peter,

 If this only happens in the IDE it might be related to bug
 http://quality.runrev.com/show_bug.cgi?id=12508 
 I couldn't nail this one down until today. I created a recipe for support.
 Hanson reproduced it in the lab.


 Ralph DiMola
 IT Director
 Evergreen Information Services
 rdim...@evergreeninfo.net

 -Original Message-
 From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
 Behalf
 Of Peter Haworth
 Sent: Wednesday, September 24, 2014 6:47 PM
 To: How to use LiveCode
 Subject: Behaviors

 I'm working with lots of controls that have behaviors.  The behavior
 buttons
 are all in a library stack.  All works fine most of the time but every now
 and again, none of the behavior scripts are executed (as verified with
 breakpoints at the start of them).  The message box shows the library stack
 is still in use and the behavior properties all look valid

 I can't pin down exactly what causes this but I think that editing a lot of
 the behavior scripts might cause this, but I'm pretty sure that shouldn't
 happen. When it happens, the only way to get the behaviors to work again is
 to quit LC and run again.

 Anyone else's applications' guilty of bad behavior like this and if so is
 there a way to correct their behavior?

 Pete
 lcSQL Software http://www.lcsql.com
 Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
 SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
 ___
 use-livecode mailing list
 use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode