Do script-only stacks support "chained" behaviors?

[Geoff Canyon]

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 at 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 objectType<sp>objectName<sp>"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 at lists.runrev.com> wrote:
>
> > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> > use-livecode at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>