lace 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
d 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
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
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
@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 <
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/).
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
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
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)
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
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
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
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
8 at 6:43 PM Geoff Canyon <gcan...@gmail.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).
>> >
>> Yes it is.
>>
>&g
wrote:
> On Sat, Jan 20, 2018 at 6:43 PM Geoff Canyon <gcan...@gmail.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).
> >
> Yes it is.
>
> For now
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?
> > >>
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
<
>>> 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 n
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 goi
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 conver
t; > 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, Trev
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
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
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 <gcan...@gmail.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).
>
Yes it is.
For now I just set the chained behaviors for
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
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
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
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 butt
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 i
mwieder wrote:
Hopefully that's a typo and not a circular reference.
So
A
|
BC
|
D
Is perfectly reasonable. B has access to A, C has access to A, D has access
to C and A. But not B.
To use a textbook example,
@gmail.com
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Why-Chained-Behaviors-May-Be-A-Bad-Idea-tp4708303p4708354.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing
Mark Weider wrote:
That is indeed classical inheritance.
Multiple inheritance is properly not allowed in LiveCode and would look like
this
Behavior_button A
Behavior Button B
Behavior Button C
# has both button A and button B assigned as behaviors
bject.
--
Mark Wieder
ahsoftw...@gmail.com
-
--
Mark Wieder
ahsoftw...@gmail.com
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Why-Chained-Behaviors-May-Be-A-Bad-Idea-tp4708303p4708332.html
Sent from the Revolu
Mark Wieder" wrote:
Well, most of the article rants about multiple inheritance, which is
indeed a bad idea. But of course you know that's different from chained
behaviors, so no worries there.
BR: actually I don't know how that is different, probably I just don't
under
is
indeed a bad idea. But of course you know that's different from chained
behaviors, so no worries there.
I had to laugh about a self-proclaimed "Perl expert" arguing about OOP,
but he does have one great quote:
"If none of the AOP stuff that I wrote made any sense
A bit OT, but this was interesting to me..
https://www.quora.com/Is-inheritance-bad-practice-in-OOP
"kinda" validated my gut feeling about nesting behaviors
BR
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to
Happy to say I found a use for chained behavior at last!
However I'm using it in a utility that could be used with any version of
LC. Does anyone recall when chained behaviors were introduced?
I'd be OK with stating that the utility is compatible with a versions of LC
after a certain release
-revolution.278305.n4.nabble.com/Chained-Behaviors-tp4685441p4685444.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
6.1
http://newsletters.livecode.com/july/issue152/newsletter1.php
-
Some are born coders, some achieve coding, and some have coding thrust
upon them. - William Shakespeare Hugh Senior
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Chained-Behaviors
I keep seeing the references to nested or chained behaviors, but is
there an actual explanation of what this *is* somewhere?
Is it multiple inheritance? A linked list? Everything I've seen so
far assumes that you already know what it is.
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
-Original Message-
From: Dr. Hawkins doch...@gmail.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Sat, Aug 24, 2013 10:38 am
Subject: A basic explanation of what nested or chained behaviors are?
I keep seeing the references to nested or chained behaviors
Dr. Hawkins wrote:
I keep seeing the references to nested or chained behaviors, but is
there an actual explanation of what this*is* somewhere?
It's in the dictionary under the behavior entry, which has been
updated for LiveCode 6.1. Basically, chained behaviors let you assign
more than one
On Sat, Aug 24, 2013 at 1:00 PM, J. Landman Gay
jac...@hyperactivesw.com wrote:
It's in the dictionary under the behavior entry, which has been updated
for LiveCode 6.1. Basically, chained behaviors let you assign more than one
behavior to an object. The normal inheritance path determines what
Can you share this 200-line handler?
Sent from my iPad
On Jul 12, 2013, at 3:31 PM, J. Landman Gay jac...@hyperactivesw.com wrote:
One of the mouseUp behaviors is 200 lines long.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please
Has anyone got any real world examples of the benefits of the new chained
behaviors feature?
I just read the latest newsletter article about them and while I understand
the concept, I didn't see benefit in the example scenario over a single
behavior with some common logic and a switch statement
Hi Peter,
Am 12.07.2013 um 19:04 schrieb Peter Haworth p...@lcsql.com:
Has anyone got any real world examples of the benefits of the new chained
behaviors feature?
I just read the latest newsletter article about them and while I understand
the concept, I didn't see benefit in the example
Peter Haworth wrote:
Has anyone got any real world examples of the benefits of the new chained
behaviors feature?
I just read the latest newsletter article about them and while I understand
the concept, I didn't see benefit in the example scenario over a single
behavior with some common logic
On 7/12/13 12:04 PM, Peter Haworth wrote:
Has anyone got any real world examples of the benefits of the new chained
behaviors feature?
I just read the latest newsletter article about them and while I understand
the concept, I didn't see benefit in the example scenario over a single
behavior
Date: Fri, 12 Jul 2013 10:58:29 -0700
From: ambassa...@fourthworld.com
To: use-livecode@lists.runrev.com
Subject: Re: Chained Behaviors
Nested behaviors simply extend the value of such a mechanism, at long
last giving xTalk one of the most valuable aspects of OOP: subclasses.
Richard
...@fourthworld.com
To: use-livecode@lists.runrev.com
Subject: Re: Chained Behaviors
Nested behaviors simply extend the value of such a mechanism, at long
last giving xTalk one of the most valuable aspects of OOP: subclasses.
Richard...
I hear what you say, but does an xTalk language need to go down
:
Date: Fri, 12 Jul 2013 10:58:29 -0700
From: ambassa...@fourthworld.com
To: use-livecode@lists.runrev.com
Subject: Re: Chained Behaviors
Nested behaviors simply extend the value of such a mechanism, at long
last giving xTalk one of the most valuable aspects of OOP: subclasses
Subject: Re: Chained Behaviors
From: jacques.cla...@gmail.com
Date: Fri, 12 Jul 2013 21:07:55 +0200
To: use-livecode@lists.runrev.com
John,
in my opinion, behaviors is simplicity. You don't have to deal with the name
of the buttons (for example), just use me. It is completely
John Dixon wrote:
Richard...
I hear what you say, but does an xTalk language need to go down this
road ?... or to perhaps put a direct way... Should an xTalk language
be going down this road ?... What I am worried about is that there
are a lot of people jumping on the 'open source'
Richard
I hear what you're saying about the risk of becoming too complex, and I
agree we should evaluate such proposed extensions very carefully.
On this we agree... with emphasis on 'very carefully'...
In the end what I learned is that he's deeply passionate about
preserving the
On Fri, Jul 12, 2013 at 10:58 AM, Richard Gaskin ambassa...@fourthworld.com
wrote:
t obviates the switch statement.
We could take this question one step back and ask why we'd want behaviors
at all, when we could just use frontScripts with switch statements instead.
But that thought
On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay
jac...@hyperactivesw.comwrote:
Remember that behaviors are not a single handler, they are whole scripts.
I have several sprites that require different behaviors on mouseUp but they
all have the same behaviors on mouseDown. With a chained
Because each sprite would then have its own script, which would be identical to
all the other sprites' scripts. Then if a change were needed, you'd have to go
in and modify each additional script. Quite a nightmare if you have hundreds of
them..
Chris
--
Chris Sheffield
Read Naturally, Inc.
I meant to say individual, not additional. Sorry 'bout that.
On Jul 12, 2013, at 1:53 PM, Chris Sheffield cmsheffi...@icloud.com wrote:
Because each sprite would then have its own script, which would be identical
to all the other sprites' scripts. Then if a change were needed, you'd have
to
On Fri, Jul 12, 2013 at 11:40 AM, Scott Rossi sc...@tactilemedia.comwrote:
have built a system that uses one behavior for a wide range of controls
using switch statements, and the higher the number of controls you have to
support, the more complex and messier the code gets. Chained behaviors
On 07/12/2013 08:58 PM, Richard Gaskin wrote:
Peter Haworth wrote:
Has anyone got any real world examples of the benefits of the new
chained
behaviors feature?
I just read the latest newsletter article about them and while I
understand
the concept, I didn't see benefit in the example
On 7/12/13 2:47 PM, Peter Haworth wrote:
On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay
jac...@hyperactivesw.comwrote:
Remember that behaviors are not a single handler, they are whole scripts.
I have several sprites that require different behaviors on mouseUp but they
all have the same
On 07/12/2013 10:43 PM, John Dixon wrote:
Richard
I hear what you're saying about the risk of becoming too complex, and I
agree we should evaluate such proposed extensions very carefully.
On this we agree... with emphasis on 'very carefully'...
In the end what I learned is that he's
Richmond wrote:
On 07/12/2013 08:58 PM, Richard Gaskin wrote:
Peter Haworth wrote:
Has anyone got any real world examples of the benefits of the new
chained
behaviors feature?
I just read the latest newsletter article about them and while I
understand
the concept, I didn't see benefit
Ah OK, that makes sense. I had the impression that each sprite needed
mouseUp logic that was unique to it. I think I'm now seeing the usefulness
of this.
I'm thinking there might be a spot for a utility that, for any given
control, lists the message handlers it uses and where they reside.
On Fri, Jul 12, 2013 at 12:36 PM, Richard Gaskin ambassa...@fourthworld.com
wrote:
Having once had a disagreement with Mark Waddingham over a language design
issue, my respect for his good judgment in this regard was only amplified
by that momentary conflict.
I remember a while back you
with all the
responses in it. Alternately, every sprite would need at least a
mouseDown and mouseUp handler that at least called another handler in
the stack.
Now try it with chained behaviors. No branching, no altering existing
mouse handlers, no big switch statements, no custom property
guys are working on updating the IDE, so maybe
we'll see something new there.
In the end, as Richard stated, no one is being forced to use behaviors, or
chained behaviors. Use them or ignore them as you see fit.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
On 7/12/13 1:04
John-
Friday, July 12, 2013, 12:12:45 PM, you wrote:
I understand 'behaviors', I use them quite a lot of the time... I
just don't see the need to continue with the 'chain' in xTalk... I
You don't *need* to chain them at all. Just continue working the way
you do and nothing changes.
I think
Monte,
If you read my later post, you'd see that I get the issue with the mouseUp
handlers, just wasn't clear from Jacque's original diagram.
As for the what's in it for me issue, that wasn't my question. I simply
asked for real life examples of the practical use of chained behaviors
since I
Monte-
Friday, July 12, 2013, 1:38:06 PM, you wrote:
a money for jam investment as far as RunRev was concerned. It was
just a case of out of sight out of mind until a few of us spotted
the tantalisingly named FEATURE_INHERITED_PARENTSCRIPTS ...
Well, to be fair about that, the feature was
to it.
As for the what's in it for me issue, that wasn't my question. I simply
asked for real life examples of the practical use of chained behaviors
since I wasn't seeing anything particularly useful in the simple newsletter
example. Now the good people on this list have enlightened me and I see
the use
On 13/07/2013, at 8:52 AM, Mark Wieder mwie...@ahsoftware.net wrote:
whoa! look at that!.
Ah.. happy memories ;-)
If anything the open source move gives everyone a chance to become
involved in feature development discussions and implementations to
ensure all the Xtalk ducks are in a row.
Peter Haworth wrote:
I remember a while back you mentioned the need for a Community Manager
(or something similar) in the open source world. Is Mark that person then?
As the number of contributors grows, the role of Community Manager can
be expected to outgrow Mark's availability, so I
Richard Gaskin wrote...
As the number of contributors grows, the role of Community Manager can
be expected to outgrow Mark's availability, so I believe RunRev plans on
having someone to handle that soon. But in the meantime, when it comes
to stewarding the code base, right now Mark is
On 7/12/13 6:08 PM, Monte Goulding wrote:
Basically nothing gets in the engine unless it goes
through Mark and he thinks it's both a good thing and ready.
For which I am very grateful. Mark has an expansive vision and solid
knowledge of both the language and the people who use it, and so far,
On 13/07/2013, at 10:37 AM, J. Landman Gay jac...@hyperactivesw.com wrote:
For which I am very grateful. Mark has an expansive vision and solid
knowledge of both the language and the people who use it, and so far, I think
everything he's decided has been spot-on. I trust him to make the
Great thread.
I think I got this inspiration from Jacque. Chained behaviors allow one to
create a well defined sub-message hierarchy distinct from the ordinary one. You
can, in other words, write your own message path, encompassing specific aspects
of your program that make sense
80 matches
Mail list logo
