Re: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

Brian,
That can of worms is why I was thinking that a handler similar to
"libraryStack" might be appropriate - like "behaviorStack"


On Mon, Jan 22, 2018 at 5:02 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> A script only stack has no place to hold properties which is what setting
> behaviors uses to "remember". (correct me if I am wrong)
>
> Bob S
>
>
> > On Jan 20, 2018, at 16:43 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Well that's too bad for anyone who's currently using chained behaviors
> and
> > wants to use source control (i.e. convert to script-only stacks).
>
>
> ___
> 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: Do script-only stacks support "chained" behaviors?

[Bob Sneidar via use-livecode]

A script only stack has no place to hold properties which is what setting 
behaviors uses to "remember". (correct me if I am wrong)

Bob S


> On Jan 20, 2018, at 16:43 , Geoff Canyon via use-livecode 
>  wrote:
> 
> Well that's too bad for anyone who's currently using chained behaviors and
> wants to use source control (i.e. convert to script-only stacks).


___
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: Do script-only stacks support "chained" behaviors?

[Brian Milby via use-livecode]

 To be more clear, after the BOM, the first word must be “script” followed
by a space and the stack name. The code to skip comment lines is not in the
source for .livecodescript files. This was adjusted when opening files with
a BOM over the internet was fixed.
On Mon, Jan 22, 2018 at 3:14 PM Brian Milby  wrote:

> First line comment is not legal for script only stacks.
> On Mon, Jan 22, 2018 at 1:29 PM Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> @Geoff, well, then my work here is done!
>> @Dr Hawk, do you mean in general?  That would require a change in LC, too,
>> and if we were going to do that, then I'd want it to be more LC-like,
>> perhaps with a handler.
>>
>> On Mon, Jan 22, 2018 at 1:28 PM, Dr. Hawkins via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> > On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
>> > use-livecode@lists.runrev.com> wrote:
>> >
>> > >
>> > > The way he suggested structuring the projects was putting the ui
>> elements
>> > > and their behaviors into /ui/stackName (and then the behaviors for
>> that
>> > > stack into /ui/stackName/behaviors/).
>> >
>> >
>> > How about something similar to the unix convention of  indicating the
>> shell
>> > to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
>> > comment?
>> >
>> > so the first line starting with, perhaps, "--#" would indicate that
>> what
>> > follows is an expression which evaluates to a button or other stack
>> that is
>> > to be the behavior of the stack?
>> >
>> > --
>> > Dr. Richard E. Hawkins, Esq.
>> > (702) 508-8462
>> > ___
>> > 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: Do script-only stacks support "chained" behaviors?

[Brian Milby via use-livecode]

First line comment is not legal for script only stacks.
On Mon, Jan 22, 2018 at 1:29 PM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> @Geoff, well, then my work here is done!
> @Dr Hawk, do you mean in general?  That would require a change in LC, too,
> and if we were going to do that, then I'd want it to be more LC-like,
> perhaps with a handler.
>
> On Mon, Jan 22, 2018 at 1:28 PM, Dr. Hawkins via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > >
> > > The way he suggested structuring the projects was putting the ui
> elements
> > > and their behaviors into /ui/stackName (and then the behaviors for that
> > > stack into /ui/stackName/behaviors/).
> >
> >
> > How about something similar to the unix convention of  indicating the
> shell
> > to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
> > comment?
> >
> > so the first line starting with, perhaps, "--#" would indicate that  what
> > follows is an expression which evaluates to a button or other stack that
> is
> > to be the behavior of the stack?
> >
> > --
> > Dr. Richard E. Hawkins, Esq.
> > (702) 508-8462
> > ___
> > 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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

@Geoff, well, then my work here is done!
@Dr Hawk, do you mean in general?  That would require a change in LC, too,
and if we were going to do that, then I'd want it to be more LC-like,
perhaps with a handler.

On Mon, Jan 22, 2018 at 1:28 PM, Dr. Hawkins via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > The way he suggested structuring the projects was putting the ui elements
> > and their behaviors into /ui/stackName (and then the behaviors for that
> > stack into /ui/stackName/behaviors/).
>
>
> How about something similar to the unix convention of  indicating the shell
> to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
> comment?
>
> so the first line starting with, perhaps, "--#" would indicate that  what
> follows is an expression which evaluates to a button or other stack that is
> to be the behavior of the stack?
>
> --
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> 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: Do script-only stacks support "chained" behaviors?

[Dr. Hawkins via use-livecode]

On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> The way he suggested structuring the projects was putting the ui elements
> and their behaviors into /ui/stackName (and then the behaviors for that
> stack into /ui/stackName/behaviors/).


How about something similar to the unix convention of  indicating the shell
to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
comment?

so the first line starting with, perhaps, "--#" would indicate that  what
follows is an expression which evaluates to a button or other stack that is
to be the behavior of the stack?

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

I definitely considered that, but I put it off for 2.0.

On Mon, Jan 22, 2018 at 7:41 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> One of the things I was going to add to Scriptifier that it would be cool
> to have in Navigator is giving the user the option to change the naming
> convention/template, so for instance if I want spaces instead of
> underscores or I want to change the order of the components of the name I
> can.
>
> On Mon, Jan 22, 2018 at 10:28 AM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I'm leaving the "make a copy" step to the user (with a stern warning to
> do
> > so).
> >
> > I'm using the stack name, the control type, the control name, the control
> > id, and "Behavior" as the SoS name, something like:
> >
> > SoS_Test_Thing_2_button_Behavior_Source_1011_Behavior
> >
> > I think that alone guarantees uniqueness, but I'm also tracking:
> >
> > 1. The file names already in the folder
> > 2. All open stack names
> > 3. All created stacks as I do the conversion
> >
> > And if there is ever a collision, I use an indexing function to avoid it,
> > adding a 2, 3, 4, etc. if necessary. So I'm pretty confident there will
> be
> > no collisions.
> >
> > The user gets to select which controls to convert, so apart from the fact
> > that it's not trivial to select only controls with a behavior, I'm
> calling
> > it done for now on that front. There used to be a setting in Navigator to
> > show only objects with scripts, but (in the UI at least) that seems to
> have
> > gone away at some point. There is the filter command, and this works just
> > fine to show only objects with scripts or behaviors in the list:
> >
> > the behavior of tID is not empty or the script of tID is not empty
> >
> > On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > Geoff,
> > > Since Trevor didn't answer the Levure question,
> > > The way he suggested structuring the projects was putting the ui
> elements
> > > and their behaviors into /ui/stackName (and then the behaviors for that
> > > stack into /ui/stackName/behaviors/).  As for naming the stacks,
> > > Scriptifier does it one (long) way in an attempt to make all the names
> > > unique.  Trevor had suggested objectTypeobjectName"behavior",
> > but
> > > of course there is no reason why you would would have to be held to
> that.
> > >
> > > It's not that you can't have scripts all over the Levure project,
> because
> > > you will with libraries, components, etc. but those aren't the major
> > PITA,
> > > and that isn't what you're trying to address with Navigator.
> > >
> > > SO, if I was going to convert a stack automagically, I would want to
> > > 1) make a copy of the stackfile, placing it in the /ui/stackname folder
> > and
> > > work on the copy
> > > 2) pull the various behaviors and put them in the
> /ui/stackfile/behaviors
> > > folder
> > > From there, we can argue a lot about the structure of the behaviors
> > > folder.  On the one hand, if you keep everything in there together,
> then
> > > you can kind-of use the names to keep everything straight, because as
> > long
> > > as you don't change the names of the SOS's, it doesn't matter if you
> move
> > > the objects they are tied to from one card to another.  It's just that
> > the
> > > /behaviors folder can become the storage for hundreds of SOS's.  On the
> > > other, it might be good to give the developer an option to have
> > subfolders
> > > for each card, but as soon as they move an object from one card to
> > another
> > > you have a gigantic mess of the developer wanting the SOS's to move,
> but
> > > that will break the references, etc.
> > >
> > > I'm glad you're working on this!  Now I can stop thinking about working
> > on
> > > it and go do something else.
> > >
> > > On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > > > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> > > > use-livecode@lists.runrev.com> wrote:
> > > >
> > > > > It occurs to me that this isn't as much of a problem as I thought
> --
> > > any
> > > > > button being converted to a stack is highly unlikely to have an
> > > openstack
> > > > > handler already in it, and therefore it would be safe to add one
> and
> > > > > include setting the behavior of the script-only stack to the
> > > appropriate
> > > > > stack up the chain. If there were already an openstack handler in
> the
> > > > > chain, then the conversion process could stop at that point, or
> > perhaps
> > > > log
> > > > > the error to the user. Unless I'm missing something?
> > > >
> > > >
> > > > Geoff,
> > > >
> > > > Keep in mind that script only stacks that are loaded into memory by
> the
> > > > engine because they are referenced in the stackfiles of another stack
> > > won’t
> > > > be sent any messages.
> > > >
> > > > 

Re: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

One of the things I was going to add to Scriptifier that it would be cool
to have in Navigator is giving the user the option to change the naming
convention/template, so for instance if I want spaces instead of
underscores or I want to change the order of the components of the name I
can.

On Mon, Jan 22, 2018 at 10:28 AM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'm leaving the "make a copy" step to the user (with a stern warning to do
> so).
>
> I'm using the stack name, the control type, the control name, the control
> id, and "Behavior" as the SoS name, something like:
>
> SoS_Test_Thing_2_button_Behavior_Source_1011_Behavior
>
> I think that alone guarantees uniqueness, but I'm also tracking:
>
> 1. The file names already in the folder
> 2. All open stack names
> 3. All created stacks as I do the conversion
>
> And if there is ever a collision, I use an indexing function to avoid it,
> adding a 2, 3, 4, etc. if necessary. So I'm pretty confident there will be
> no collisions.
>
> The user gets to select which controls to convert, so apart from the fact
> that it's not trivial to select only controls with a behavior, I'm calling
> it done for now on that front. There used to be a setting in Navigator to
> show only objects with scripts, but (in the UI at least) that seems to have
> gone away at some point. There is the filter command, and this works just
> fine to show only objects with scripts or behaviors in the list:
>
> the behavior of tID is not empty or the script of tID is not empty
>
> On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Geoff,
> > Since Trevor didn't answer the Levure question,
> > The way he suggested structuring the projects was putting the ui elements
> > and their behaviors into /ui/stackName (and then the behaviors for that
> > stack into /ui/stackName/behaviors/).  As for naming the stacks,
> > Scriptifier does it one (long) way in an attempt to make all the names
> > unique.  Trevor had suggested objectTypeobjectName"behavior",
> but
> > of course there is no reason why you would would have to be held to that.
> >
> > It's not that you can't have scripts all over the Levure project, because
> > you will with libraries, components, etc. but those aren't the major
> PITA,
> > and that isn't what you're trying to address with Navigator.
> >
> > SO, if I was going to convert a stack automagically, I would want to
> > 1) make a copy of the stackfile, placing it in the /ui/stackname folder
> and
> > work on the copy
> > 2) pull the various behaviors and put them in the /ui/stackfile/behaviors
> > folder
> > From there, we can argue a lot about the structure of the behaviors
> > folder.  On the one hand, if you keep everything in there together, then
> > you can kind-of use the names to keep everything straight, because as
> long
> > as you don't change the names of the SOS's, it doesn't matter if you move
> > the objects they are tied to from one card to another.  It's just that
> the
> > /behaviors folder can become the storage for hundreds of SOS's.  On the
> > other, it might be good to give the developer an option to have
> subfolders
> > for each card, but as soon as they move an object from one card to
> another
> > you have a gigantic mess of the developer wanting the SOS's to move, but
> > that will break the references, etc.
> >
> > I'm glad you're working on this!  Now I can stop thinking about working
> on
> > it and go do something else.
> >
> > On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > > > It occurs to me that this isn't as much of a problem as I thought --
> > any
> > > > button being converted to a stack is highly unlikely to have an
> > openstack
> > > > handler already in it, and therefore it would be safe to add one and
> > > > include setting the behavior of the script-only stack to the
> > appropriate
> > > > stack up the chain. If there were already an openstack handler in the
> > > > chain, then the conversion process could stop at that point, or
> perhaps
> > > log
> > > > the error to the user. Unless I'm missing something?
> > >
> > >
> > > Geoff,
> > >
> > > Keep in mind that script only stacks that are loaded into memory by the
> > > engine because they are referenced in the stackfiles of another stack
> > won’t
> > > be sent any messages.
> > >
> > > http://quality.livecode.com/show_bug.cgi?id=18223
> > >
> > > You have to complete the behavior chain in the openStack handler of the
> > > stack that is being opened. I think in your case you would process the
> > > openStack message in the stack you are setting the stackFiles on.
> > >
> > > Trevor DeVore
> > > ScreenSteps
> > >
> > > >
> > > ___
> > > use-livecode mailing list

Re: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

I'm leaving the "make a copy" step to the user (with a stern warning to do
so).

I'm using the stack name, the control type, the control name, the control
id, and "Behavior" as the SoS name, something like:

SoS_Test_Thing_2_button_Behavior_Source_1011_Behavior

I think that alone guarantees uniqueness, but I'm also tracking:

1. The file names already in the folder
2. All open stack names
3. All created stacks as I do the conversion

And if there is ever a collision, I use an indexing function to avoid it,
adding a 2, 3, 4, etc. if necessary. So I'm pretty confident there will be
no collisions.

The user gets to select which controls to convert, so apart from the fact
that it's not trivial to select only controls with a behavior, I'm calling
it done for now on that front. There used to be a setting in Navigator to
show only objects with scripts, but (in the UI at least) that seems to have
gone away at some point. There is the filter command, and this works just
fine to show only objects with scripts or behaviors in the list:

the behavior of tID is not empty or the script of tID is not empty

On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Geoff,
> Since Trevor didn't answer the Levure question,
> The way he suggested structuring the projects was putting the ui elements
> and their behaviors into /ui/stackName (and then the behaviors for that
> stack into /ui/stackName/behaviors/).  As for naming the stacks,
> Scriptifier does it one (long) way in an attempt to make all the names
> unique.  Trevor had suggested objectTypeobjectName"behavior", but
> of course there is no reason why you would would have to be held to that.
>
> It's not that you can't have scripts all over the Levure project, because
> you will with libraries, components, etc. but those aren't the major PITA,
> and that isn't what you're trying to address with Navigator.
>
> SO, if I was going to convert a stack automagically, I would want to
> 1) make a copy of the stackfile, placing it in the /ui/stackname folder and
> work on the copy
> 2) pull the various behaviors and put them in the /ui/stackfile/behaviors
> folder
> From there, we can argue a lot about the structure of the behaviors
> folder.  On the one hand, if you keep everything in there together, then
> you can kind-of use the names to keep everything straight, because as long
> as you don't change the names of the SOS's, it doesn't matter if you move
> the objects they are tied to from one card to another.  It's just that the
> /behaviors folder can become the storage for hundreds of SOS's.  On the
> other, it might be good to give the developer an option to have subfolders
> for each card, but as soon as they move an object from one card to another
> you have a gigantic mess of the developer wanting the SOS's to move, but
> that will break the references, etc.
>
> I'm glad you're working on this!  Now I can stop thinking about working on
> it and go do something else.
>
> On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > It occurs to me that this isn't as much of a problem as I thought --
> any
> > > button being converted to a stack is highly unlikely to have an
> openstack
> > > handler already in it, and therefore it would be safe to add one and
> > > include setting the behavior of the script-only stack to the
> appropriate
> > > stack up the chain. If there were already an openstack handler in the
> > > chain, then the conversion process could stop at that point, or perhaps
> > log
> > > the error to the user. Unless I'm missing something?
> >
> >
> > Geoff,
> >
> > Keep in mind that script only stacks that are loaded into memory by the
> > engine because they are referenced in the stackfiles of another stack
> won’t
> > be sent any messages.
> >
> > http://quality.livecode.com/show_bug.cgi?id=18223
> >
> > You have to complete the behavior chain in the openStack handler of the
> > stack that is being opened. I think in your case you would process the
> > openStack message in the stack you are setting the stackFiles on.
> >
> > Trevor DeVore
> > ScreenSteps
> >
> > >
> > ___
> > 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 

Re: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

That's disappointing.

On Mon, Jan 22, 2018 at 3:38 AM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
>
> Keep in mind that script only stacks that are loaded into memory by the
> engine because they are referenced in the stackfiles of another stack won’t
> be sent any messages.
>
> http://quality.livecode.com/show_bug.cgi?id=18223
>
> You have to complete the behavior chain in the openStack handler of the
> stack that is being opened. I think in your case you would process the
> openStack message in the stack you are setting the stackFiles on.
___
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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

Geoff,
Since Trevor didn't answer the Levure question,
The way he suggested structuring the projects was putting the ui elements
and their behaviors into /ui/stackName (and then the behaviors for that
stack into /ui/stackName/behaviors/).  As for naming the stacks,
Scriptifier does it one (long) way in an attempt to make all the names
unique.  Trevor had suggested objectTypeobjectName"behavior", but
of course there is no reason why you would would have to be held to that.

It's not that you can't have scripts all over the Levure project, because
you will with libraries, components, etc. but those aren't the major PITA,
and that isn't what you're trying to address with Navigator.

SO, if I was going to convert a stack automagically, I would want to
1) make a copy of the stackfile, placing it in the /ui/stackname folder and
work on the copy
2) pull the various behaviors and put them in the /ui/stackfile/behaviors
folder
From there, we can argue a lot about the structure of the behaviors
folder.  On the one hand, if you keep everything in there together, then
you can kind-of use the names to keep everything straight, because as long
as you don't change the names of the SOS's, it doesn't matter if you move
the objects they are tied to from one card to another.  It's just that the
/behaviors folder can become the storage for hundreds of SOS's.  On the
other, it might be good to give the developer an option to have subfolders
for each card, but as soon as they move an object from one card to another
you have a gigantic mess of the developer wanting the SOS's to move, but
that will break the references, etc.

I'm glad you're working on this!  Now I can stop thinking about working on
it and go do something else.

On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > It occurs to me that this isn't as much of a problem as I thought -- any
> > button being converted to a stack is highly unlikely to have an openstack
> > handler already in it, and therefore it would be safe to add one and
> > include setting the behavior of the script-only stack to the appropriate
> > stack up the chain. If there were already an openstack handler in the
> > chain, then the conversion process could stop at that point, or perhaps
> log
> > the error to the user. Unless I'm missing something?
>
>
> Geoff,
>
> Keep in mind that script only stacks that are loaded into memory by the
> engine because they are referenced in the stackfiles of another stack won’t
> be sent any messages.
>
> http://quality.livecode.com/show_bug.cgi?id=18223
>
> You have to complete the behavior chain in the openStack handler of the
> stack that is being opened. I think in your case you would process the
> openStack message in the stack you are setting the stackFiles on.
>
> Trevor DeVore
> ScreenSteps
>
> >
> ___
> 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: Do script-only stacks support "chained" behaviors?

[Trevor DeVore via use-livecode]

On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> It occurs to me that this isn't as much of a problem as I thought -- any
> button being converted to a stack is highly unlikely to have an openstack
> handler already in it, and therefore it would be safe to add one and
> include setting the behavior of the script-only stack to the appropriate
> stack up the chain. If there were already an openstack handler in the
> chain, then the conversion process could stop at that point, or perhaps log
> the error to the user. Unless I'm missing something?


Geoff,

Keep in mind that script only stacks that are loaded into memory by the
engine because they are referenced in the stackfiles of another stack won’t
be sent any messages.

http://quality.livecode.com/show_bug.cgi?id=18223

You have to complete the behavior chain in the openStack handler of the
stack that is being opened. I think in your case you would process the
openStack message in the stack you are setting the stackFiles on.

Trevor DeVore
ScreenSteps

>
___
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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

Heisenbug -- as far as I remember the last twenty minutes, the sequence of
edits was:

1. Answer commands die without warning
2. Wrap the problematic answer commands in a try...catch structure.
3. Run the command; get no error from the try, and the command runs all the
way through.
4. Comment out the try...catch structure, leaving the answer commands in
place.
5. Run the command; no errors, everything works fine.

So...something changed, obviously, but I have no idea what. Testing now...

On Sun, Jan 21, 2018 at 10:35 PM, Geoff Canyon  wrote:

> Double-grrr. I put the warning dialogs in the menuPick handler instead of
> the conversion handler, and it works fine. That's *not* where the warnings
> should be, since it means that it's possible to call the conversion handler
> and receive no warnings. I'm testing further. Once I'm comfortable enough
> to try it on (a copy of) Navigator itself, I'll post an update.
>
> gc
>
> On Sun, Jan 21, 2018 at 10:22 PM, Geoff Canyon  wrote:
>
>> Also, status update: grr. I'm finding that the answer dialog I'm using to
>> warn the user that the script conversion process is dangerous and to work
>> on a backup is causing my script to die, no warning, and no error message.
>> The exact same script *not* running in Navigator works fine. Answer dialogs
>> in other Navigator handlers also work fine. I have zero idea why this might
>> be. Other than this I'd be testing away and releasing :-(
>>
>
___
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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

Another key difference in our implementations that I find fascinating: you
create script-only stacks by creating the stacks, then saving the stacks. I
created them by constructing a variable with the text contents of the
stacks, then writing that out to files with put into url etc.

On Sun, Jan 21, 2018 at 3:30 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Cool, scriptifier was/is just a tool I wrote because it took about the
> same about of time to write as to tediously scriptify a stack so I thought
> it would be a win in the end. If anyone is keen to make it more robust or
> start from scratch then have at it. FWIW it would probably be a good idea
> to check scriptified scripts for the conditional messages that are only
> sent if an object has them (idle, mouseStillDown etc) and warn about
> scriptifying those. We got caught with idle in an old script in an IDE
> stack once.
>
> Cheers
>
> Monte
___
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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

Double-grrr. I put the warning dialogs in the menuPick handler instead of
the conversion handler, and it works fine. That's *not* where the warnings
should be, since it means that it's possible to call the conversion handler
and receive no warnings. I'm testing further. Once I'm comfortable enough
to try it on (a copy of) Navigator itself, I'll post an update.

gc

On Sun, Jan 21, 2018 at 10:22 PM, Geoff Canyon  wrote:

> Also, status update: grr. I'm finding that the answer dialog I'm using to
> warn the user that the script conversion process is dangerous and to work
> on a backup is causing my script to die, no warning, and no error message.
> The exact same script *not* running in Navigator works fine. Answer dialogs
> in other Navigator handlers also work fine. I have zero idea why this might
> be. Other than this I'd be testing away and releasing :-(
>
___
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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

Also, status update: grr. I'm finding that the answer dialog I'm using to
warn the user that the script conversion process is dangerous and to work
on a backup is causing my script to die, no warning, and no error message.
The exact same script *not* running in Navigator works fine. Answer dialogs
in other Navigator handlers also work fine. I have zero idea why this might
be. Other than this I'd be testing away and releasing :-(

On Sun, Jan 21, 2018 at 10:19 PM, Geoff Canyon  wrote:

> It occurs to me that this isn't as much of a problem as I thought -- any
> button being converted to a stack is highly unlikely to have an openstack
> handler already in it, and therefore it would be safe to add one and
> include setting the behavior of the script-only stack to the appropriate
> stack up the chain. If there were already an openstack handler in the
> chain, then the conversion process could stop at that point, or perhaps log
> the error to the user. Unless I'm missing something?
>
> On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> On Sat, Jan 20, 2018 at 6:43 PM Geoff Canyon  wrote:
>>
>> > Well that's too bad for anyone who's currently using chained behaviors
>> and
>> > wants to use source control (i.e. convert to script-only stacks).
>> >
>> Yes it is.
>>
>> For now I just set the chained behaviors for any script only stacks that
>> require them when the app starts up. Not ideal, but worth it in order to
>> manage the scripts with source control.
>>
>> Trevor DeVore
>> ScreenSteps
>> ___
>> 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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

It occurs to me that this isn't as much of a problem as I thought -- any
button being converted to a stack is highly unlikely to have an openstack
handler already in it, and therefore it would be safe to add one and
include setting the behavior of the script-only stack to the appropriate
stack up the chain. If there were already an openstack handler in the
chain, then the conversion process could stop at that point, or perhaps log
the error to the user. Unless I'm missing something?

On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Sat, Jan 20, 2018 at 6:43 PM Geoff Canyon  wrote:
>
> > Well that's too bad for anyone who's currently using chained behaviors
> and
> > wants to use source control (i.e. convert to script-only stacks).
> >
> Yes it is.
>
> For now I just set the chained behaviors for any script only stacks that
> require them when the app starts up. Not ideal, but worth it in order to
> manage the scripts with source control.
>
> Trevor DeVore
> ScreenSteps
> ___
> 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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

How does Levure organize SOS's? The present setup already allows the user
to specify a target folder into which to place the newly created stacks,
and correctly sets the relative path in the stackfiles property.

On Sun, Jan 21, 2018 at 1:34 PM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> As long as you're at it, it would be cool if you added an option to
> organize the SOS's the way Levure would.  I was working on Scriptifier to
> do the same thing, but I haven't gotten around to finishing it.  If
> Navigator does it, then I can just stop fiddling with my hack.
>
> On Sun, Jan 21, 2018 at 2:28 AM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > At a fundamental level (unless I'm misreading it) Scriptifier parses a
> > whole stack and looks for objects with a script and no behavior, and
> turns
> > them into an object with no script and a script-only stack behavior.
> > Navigator will work on whatever controls you tell it to, and will look
> for
> > objects with a script and no behavior, and turn them into an object with
> no
> > script and a script-only stack behavior, but it will also find objects
> with
> > a button behavior (that does not itself have a behavior), and create a
> > script-only stack with that button's script, and set those objects'
> > behavior to the resulting stacks (and the original button, so if there
> are
> > unconverted controls, they'll still work. I'm definitely going to have to
> > add an "and enclosed controls" option in Navigator. There are several
> other
> > differences, as there always will be when two different people look at a
> > problem.
> >
> > On Sat, Jan 20, 2018 at 11:01 PM, Geoff Canyon 
> wrote:
> >
> > > I built my own, for several reasons, among them:
> > >
> > > 1. In the context of Navigator, I needed to support creating stack
> > > behaviors for an arbitrary collection of controls, rather than
> recursing
> > > through a stack.
> > > 2. I figured that Monte and I would approach the task differently, and
> we
> > > did on several fronts.
> > > 3. I thought it would be fun to code. (and it was, I royally borked my
> > > first implementation in the product definition phase)
> > >
> > > I just ran my first test, and it seems to be working.
> > >
> > > I'm going to build some more tests for it, then release it with stern
> > > warnings that anyone using it on a non-backed-up project is foolish,
> and
> > I
> > > am not responsible for the horrible things they do with it. It should
> be
> > > available sometime tomorrow.
> > >
> > > gc
> > >
> > > On Sat, Jan 20, 2018 at 7:16 PM, Mike Kerner via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > >> Dumb question, Geoff, are you going to embed/call Scriptifier to
> achieve
> > >> that or are you going to do something else?
> > >>
> > >> On Sat, Jan 20, 2018 at 8:25 PM, Geoff Canyon via use-livecode <
> > >> use-livecode@lists.runrev.com> wrote:
> > >>
> > >> > I get that it can be done, I just hesitate to start monkeying with
> > >> people's
> > >> > scripts like that in Navigator (which is going to have a conversion
> > >> > function in the next update). For now I'm thinking that I just skip
> > >> > anything with chained behaviors, unless someone has a better
> > suggestion.
> > >> >
> > >> > On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
> > >> > use-livecode@lists.runrev.com> wrote:
> > >> > >
> > >> > > For now I just set the chained behaviors for any script only
> stacks
> > >> that
> > >> > > require them when the app starts up. Not ideal, but worth it in
> > order
> > >> to
> > >> > > manage the scripts with source control.
> > >> > >
> > >> > >
> > >> > ___
> > >> > 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
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, 

Re: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

That's a nice idea about the warnings.

On Sun, Jan 21, 2018 at 3:30 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Cool, scriptifier was/is just a tool I wrote because it took about the
> same about of time to write as to tediously scriptify a stack so I thought
> it would be a win in the end. If anyone is keen to make it more robust or
> start from scratch then have at it. FWIW it would probably be a good idea
> to check scriptified scripts for the conditional messages that are only
> sent if an object has them (idle, mouseStillDown etc) and warn about
> scriptifying those. We got caught with idle in an old script in an IDE
> stack once.
>
> Cheers
>
> Monte
>
> > On 21 Jan 2018, at 6:28 pm, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > At a fundamental level (unless I'm misreading it) Scriptifier parses a
> > whole stack and looks for objects with a script and no behavior, and
> turns
> > them into an object with no script and a script-only stack behavior.
> > Navigator will work on whatever controls you tell it to, and will look
> for
> > objects with a script and no behavior, and turn them into an object with
> no
> > script and a script-only stack behavior, but it will also find objects
> with
> > a button behavior (that does not itself have a behavior), and create a
> > script-only stack with that button's script, and set those objects'
> > behavior to the resulting stacks (and the original button, so if there
> are
> > unconverted controls, they'll still work. I'm definitely going to have to
> > add an "and enclosed controls" option in Navigator. There are several
> other
> > differences, as there always will be when two different people look at a
> > problem.
> >
> > On Sat, Jan 20, 2018 at 11:01 PM, Geoff Canyon 
> wrote:
> >
> >> I built my own, for several reasons, among them:
> >>
> >> 1. In the context of Navigator, I needed to support creating stack
> >> behaviors for an arbitrary collection of controls, rather than recursing
> >> through a stack.
> >> 2. I figured that Monte and I would approach the task differently, and
> we
> >> did on several fronts.
> >> 3. I thought it would be fun to code. (and it was, I royally borked my
> >> first implementation in the product definition phase)
> >>
> >> I just ran my first test, and it seems to be working.
> >>
> >> I'm going to build some more tests for it, then release it with stern
> >> warnings that anyone using it on a non-backed-up project is foolish,
> and I
> >> am not responsible for the horrible things they do with it. It should be
> >> available sometime tomorrow.
> >>
> >> gc
> >>
> >> On Sat, Jan 20, 2018 at 7:16 PM, Mike Kerner via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>> Dumb question, Geoff, are you going to embed/call Scriptifier to
> achieve
> >>> that or are you going to do something else?
> >>>
> >>> On Sat, Jan 20, 2018 at 8:25 PM, Geoff Canyon via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> >>>
>  I get that it can be done, I just hesitate to start monkeying with
> >>> people's
>  scripts like that in Navigator (which is going to have a conversion
>  function in the next update). For now I'm thinking that I just skip
>  anything with chained behaviors, unless someone has a better
> suggestion.
> 
>  On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
>  use-livecode@lists.runrev.com> wrote:
> >
> > For now I just set the chained behaviors for any script only stacks
> >>> that
> > require them when the app starts up. Not ideal, but worth it in order
> >>> to
> > manage the scripts with source control.
> >
> >
>  ___
>  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
> 

Re: Do script-only stacks support "chained" behaviors?

[Monte Goulding via use-livecode]

Cool, scriptifier was/is just a tool I wrote because it took about the same 
about of time to write as to tediously scriptify a stack so I thought it would 
be a win in the end. If anyone is keen to make it more robust or start from 
scratch then have at it. FWIW it would probably be a good idea to check 
scriptified scripts for the conditional messages that are only sent if an 
object has them (idle, mouseStillDown etc) and warn about scriptifying those. 
We got caught with idle in an old script in an IDE stack once.

Cheers

Monte

> On 21 Jan 2018, at 6:28 pm, Geoff Canyon via use-livecode 
>  wrote:
> 
> At a fundamental level (unless I'm misreading it) Scriptifier parses a
> whole stack and looks for objects with a script and no behavior, and turns
> them into an object with no script and a script-only stack behavior.
> Navigator will work on whatever controls you tell it to, and will look for
> objects with a script and no behavior, and turn them into an object with no
> script and a script-only stack behavior, but it will also find objects with
> a button behavior (that does not itself have a behavior), and create a
> script-only stack with that button's script, and set those objects'
> behavior to the resulting stacks (and the original button, so if there are
> unconverted controls, they'll still work. I'm definitely going to have to
> add an "and enclosed controls" option in Navigator. There are several other
> differences, as there always will be when two different people look at a
> problem.
> 
> On Sat, Jan 20, 2018 at 11:01 PM, Geoff Canyon  wrote:
> 
>> I built my own, for several reasons, among them:
>> 
>> 1. In the context of Navigator, I needed to support creating stack
>> behaviors for an arbitrary collection of controls, rather than recursing
>> through a stack.
>> 2. I figured that Monte and I would approach the task differently, and we
>> did on several fronts.
>> 3. I thought it would be fun to code. (and it was, I royally borked my
>> first implementation in the product definition phase)
>> 
>> I just ran my first test, and it seems to be working.
>> 
>> I'm going to build some more tests for it, then release it with stern
>> warnings that anyone using it on a non-backed-up project is foolish, and I
>> am not responsible for the horrible things they do with it. It should be
>> available sometime tomorrow.
>> 
>> gc
>> 
>> On Sat, Jan 20, 2018 at 7:16 PM, Mike Kerner via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Dumb question, Geoff, are you going to embed/call Scriptifier to achieve
>>> that or are you going to do something else?
>>> 
>>> On Sat, Jan 20, 2018 at 8:25 PM, Geoff Canyon via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 I get that it can be done, I just hesitate to start monkeying with
>>> people's
 scripts like that in Navigator (which is going to have a conversion
 function in the next update). For now I'm thinking that I just skip
 anything with chained behaviors, unless someone has a better suggestion.
 
 On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
 use-livecode@lists.runrev.com> wrote:
> 
> For now I just set the chained behaviors for any script only stacks
>>> that
> require them when the app starts up. Not ideal, but worth it in order
>>> to
> manage the scripts with source control.
> 
> 
 ___
 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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

As long as you're at it, it would be cool if you added an option to
organize the SOS's the way Levure would.  I was working on Scriptifier to
do the same thing, but I haven't gotten around to finishing it.  If
Navigator does it, then I can just stop fiddling with my hack.

On Sun, Jan 21, 2018 at 2:28 AM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> At a fundamental level (unless I'm misreading it) Scriptifier parses a
> whole stack and looks for objects with a script and no behavior, and turns
> them into an object with no script and a script-only stack behavior.
> Navigator will work on whatever controls you tell it to, and will look for
> objects with a script and no behavior, and turn them into an object with no
> script and a script-only stack behavior, but it will also find objects with
> a button behavior (that does not itself have a behavior), and create a
> script-only stack with that button's script, and set those objects'
> behavior to the resulting stacks (and the original button, so if there are
> unconverted controls, they'll still work. I'm definitely going to have to
> add an "and enclosed controls" option in Navigator. There are several other
> differences, as there always will be when two different people look at a
> problem.
>
> On Sat, Jan 20, 2018 at 11:01 PM, Geoff Canyon  wrote:
>
> > I built my own, for several reasons, among them:
> >
> > 1. In the context of Navigator, I needed to support creating stack
> > behaviors for an arbitrary collection of controls, rather than recursing
> > through a stack.
> > 2. I figured that Monte and I would approach the task differently, and we
> > did on several fronts.
> > 3. I thought it would be fun to code. (and it was, I royally borked my
> > first implementation in the product definition phase)
> >
> > I just ran my first test, and it seems to be working.
> >
> > I'm going to build some more tests for it, then release it with stern
> > warnings that anyone using it on a non-backed-up project is foolish, and
> I
> > am not responsible for the horrible things they do with it. It should be
> > available sometime tomorrow.
> >
> > gc
> >
> > On Sat, Jan 20, 2018 at 7:16 PM, Mike Kerner via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> Dumb question, Geoff, are you going to embed/call Scriptifier to achieve
> >> that or are you going to do something else?
> >>
> >> On Sat, Jan 20, 2018 at 8:25 PM, Geoff Canyon via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >> > I get that it can be done, I just hesitate to start monkeying with
> >> people's
> >> > scripts like that in Navigator (which is going to have a conversion
> >> > function in the next update). For now I'm thinking that I just skip
> >> > anything with chained behaviors, unless someone has a better
> suggestion.
> >> >
> >> > On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
> >> > use-livecode@lists.runrev.com> wrote:
> >> > >
> >> > > For now I just set the chained behaviors for any script only stacks
> >> that
> >> > > require them when the app starts up. Not ideal, but worth it in
> order
> >> to
> >> > > manage the scripts with source control.
> >> > >
> >> > >
> >> > ___
> >> > 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
>



-- 
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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

At a fundamental level (unless I'm misreading it) Scriptifier parses a
whole stack and looks for objects with a script and no behavior, and turns
them into an object with no script and a script-only stack behavior.
Navigator will work on whatever controls you tell it to, and will look for
objects with a script and no behavior, and turn them into an object with no
script and a script-only stack behavior, but it will also find objects with
a button behavior (that does not itself have a behavior), and create a
script-only stack with that button's script, and set those objects'
behavior to the resulting stacks (and the original button, so if there are
unconverted controls, they'll still work. I'm definitely going to have to
add an "and enclosed controls" option in Navigator. There are several other
differences, as there always will be when two different people look at a
problem.

On Sat, Jan 20, 2018 at 11:01 PM, Geoff Canyon  wrote:

> I built my own, for several reasons, among them:
>
> 1. In the context of Navigator, I needed to support creating stack
> behaviors for an arbitrary collection of controls, rather than recursing
> through a stack.
> 2. I figured that Monte and I would approach the task differently, and we
> did on several fronts.
> 3. I thought it would be fun to code. (and it was, I royally borked my
> first implementation in the product definition phase)
>
> I just ran my first test, and it seems to be working.
>
> I'm going to build some more tests for it, then release it with stern
> warnings that anyone using it on a non-backed-up project is foolish, and I
> am not responsible for the horrible things they do with it. It should be
> available sometime tomorrow.
>
> gc
>
> On Sat, Jan 20, 2018 at 7:16 PM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Dumb question, Geoff, are you going to embed/call Scriptifier to achieve
>> that or are you going to do something else?
>>
>> On Sat, Jan 20, 2018 at 8:25 PM, Geoff Canyon via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> > I get that it can be done, I just hesitate to start monkeying with
>> people's
>> > scripts like that in Navigator (which is going to have a conversion
>> > function in the next update). For now I'm thinking that I just skip
>> > anything with chained behaviors, unless someone has a better suggestion.
>> >
>> > On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
>> > use-livecode@lists.runrev.com> wrote:
>> > >
>> > > For now I just set the chained behaviors for any script only stacks
>> that
>> > > require them when the app starts up. Not ideal, but worth it in order
>> to
>> > > manage the scripts with source control.
>> > >
>> > >
>> > ___
>> > 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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

I built my own, for several reasons, among them:

1. In the context of Navigator, I needed to support creating stack
behaviors for an arbitrary collection of controls, rather than recursing
through a stack.
2. I figured that Monte and I would approach the task differently, and we
did on several fronts.
3. I thought it would be fun to code. (and it was, I royally borked my
first implementation in the product definition phase)

I just ran my first test, and it seems to be working.

I'm going to build some more tests for it, then release it with stern
warnings that anyone using it on a non-backed-up project is foolish, and I
am not responsible for the horrible things they do with it. It should be
available sometime tomorrow.

gc

On Sat, Jan 20, 2018 at 7:16 PM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Dumb question, Geoff, are you going to embed/call Scriptifier to achieve
> that or are you going to do something else?
>
> On Sat, Jan 20, 2018 at 8:25 PM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I get that it can be done, I just hesitate to start monkeying with
> people's
> > scripts like that in Navigator (which is going to have a conversion
> > function in the next update). For now I'm thinking that I just skip
> > anything with chained behaviors, unless someone has a better suggestion.
> >
> > On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >
> > > For now I just set the chained behaviors for any script only stacks
> that
> > > require them when the app starts up. Not ideal, but worth it in order
> to
> > > manage the scripts with source control.
> > >
> > >
> > ___
> > 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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

Dumb question, Geoff, are you going to embed/call Scriptifier to achieve
that or are you going to do something else?

On Sat, Jan 20, 2018 at 8:25 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I get that it can be done, I just hesitate to start monkeying with people's
> scripts like that in Navigator (which is going to have a conversion
> function in the next update). For now I'm thinking that I just skip
> anything with chained behaviors, unless someone has a better suggestion.
>
> On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > For now I just set the chained behaviors for any script only stacks that
> > require them when the app starts up. Not ideal, but worth it in order to
> > manage the scripts with source control.
> >
> >
> ___
> 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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

I get that it can be done, I just hesitate to start monkeying with people's
scripts like that in Navigator (which is going to have a conversion
function in the next update). For now I'm thinking that I just skip
anything with chained behaviors, unless someone has a better suggestion.

On Sat, Jan 20, 2018 at 5:15 PM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> For now I just set the chained behaviors for any script only stacks that
> require them when the app starts up. Not ideal, but worth it in order to
> manage the scripts with source control.
>
>
___
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: Do script-only stacks support "chained" behaviors?

[Ali Lloyd via use-livecode]

I should clarify: say you want stack 1 to have behavior stack 2 which has
behavior stack 3.

In the IDE we commonly do:
Stack 1:

on preOpenStack
   dispatch "setAsBehavior" to stack "Stack 2" with the long id of me
end preOpenStack

Stack 2:
on setAsBehavior pTarget
   dispatch "setAsBehavior" to stack "Stack 3" with the long id of this me
   set the behavior of pTarget to the long id of this me
end setAsBehavior

Stack 3:
on setAsBehavior pTarget
   set the behavior of pTarget to the long id of this me
end setAsBehavior

On Sun, Jan 21, 2018 at 1:12 AM Ali Lloyd  wrote:

> There are also plenty of examples in the IDE - most of the palettes have
> their own specific behavior chained to the generic palette behavior.
>
> Most of them do something like the following handler:
> on setAsBehavior pTarget dispatch "setAsBehavior" to stack
> revIDEFrameBehavior() with the long id of this me set the behavior of
> pTarget to the long id of this me end setAsBehavior
>
> They then call the setAsBehavior handler on preOpenStack.
>
> On Sun, Jan 21, 2018 at 12:14 AM Trevor DeVore via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> On Sat, Jan 20, 2018 at 5:53 PM Mike Kerner via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> > I believe they do, because I think Trevor is doing this with Levure.
>>
>>
>> You can’t specify the behavior property of a script only stack in the
>> script only stack itself. You have to assign the behavior of the script
>> only stack using code after the stack has been loaded into memory. The
>> behavior property setting won’t persist however.
>>
>> Trevor DeVore
>> ScreenSteps
>>
>> >
>> ___
>> 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: Do script-only stacks support "chained" behaviors?

[Trevor DeVore via use-livecode]

On Sat, Jan 20, 2018 at 6:43 PM Geoff Canyon  wrote:

> Well that's too bad for anyone who's currently using chained behaviors and
> wants to use source control (i.e. convert to script-only stacks).
>
Yes it is.

For now I just set the chained behaviors for any script only stacks that
require them when the app starts up. Not ideal, but worth it in order to
manage the scripts with source control.

Trevor DeVore
ScreenSteps
___
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: Do script-only stacks support "chained" behaviors?

[Ali Lloyd via use-livecode]

There are also plenty of examples in the IDE - most of the palettes have
their own specific behavior chained to the generic palette behavior.

Most of them do something like the following handler:
on setAsBehavior pTarget dispatch "setAsBehavior" to stack
revIDEFrameBehavior() with the long id of this me set the behavior of
pTarget to the long id of this me end setAsBehavior

They then call the setAsBehavior handler on preOpenStack.

On Sun, Jan 21, 2018 at 12:14 AM Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Sat, Jan 20, 2018 at 5:53 PM Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I believe they do, because I think Trevor is doing this with Levure.
>
>
> You can’t specify the behavior property of a script only stack in the
> script only stack itself. You have to assign the behavior of the script
> only stack using code after the stack has been loaded into memory. The
> behavior property setting won’t persist however.
>
> Trevor DeVore
> ScreenSteps
>
> >
> ___
> 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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

Well that's too bad for anyone who's currently using chained behaviors and
wants to use source control (i.e. convert to script-only stacks).
___
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: Do script-only stacks support "chained" behaviors?

[Trevor DeVore via use-livecode]

On Sat, Jan 20, 2018 at 5:53 PM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I believe they do, because I think Trevor is doing this with Levure.


You can’t specify the behavior property of a script only stack in the
script only stack itself. You have to assign the behavior of the script
only stack using code after the stack has been loaded into memory. The
behavior property setting won’t persist however.

Trevor DeVore
ScreenSteps

>
___
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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

I believe they do, because I think Trevor is doing this with Levure.

On Sat, Jan 20, 2018 at 5:51 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This page http://livecode.wikia.com/wiki/Behavior describes "chained"
> behaviors, saying that button 1 can have button 2 as its behavior, and if
> button 2 has button 3 as *its* behavior, then button 1 will have access to
> the handlers in both button 2 and button 3.
>
> This seems to work in LC 8.1.8, although chained behaviors seem to be
> somewhat brittle -- I'm seeing that sometimes closing and opening a stack
> causes button 1 in the above example to inherit from button 2, but not from
> button 3.
>
> SO: is there a way to support this for script-only stacks? As far as I
> know, script-only stacks only support defining the name and script of the
> stack, and no properties at all, i.e. no ability to set a behavior for the
> script-only stack. So in the above example, button 3 could be replaced by a
> script-only stack, but button 2 could not (without losing the inheritance
> from button 3).
>
> Is that correct?
>
> gc
> ___
> 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