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
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 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
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 goin
@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.runre
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/).
Ho
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
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,
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 unique
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 me
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) wa
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 wo
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 t
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,
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
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
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 t
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.run
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
> i
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
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
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 w
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 fro
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
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 2
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
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
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 t
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 ma
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 behav
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 a
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, alt
32 matches
Mail list logo
