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 to
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 curre
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
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 j
gt; 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
; > 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
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 c
ode@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&#x
; >> 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 Naviga
, 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 con
27;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 a
ying 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, Trev
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.
O
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 stack
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, unsub
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 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,
if
der
ahsoftw...@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-l
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
ild object.
--
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 R
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&#
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, le
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 subsc
y appeared in LC 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 i
http://runtime-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, unsubscr
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 certa
On Sat, Aug 24, 2013 at 1:00 PM, J. Landman Gay
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 dete
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 as
-Original Message-
From: Dr. Hawkins
To: How to use LiveCode
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, but is
there an actual explanation of what this *is* somewhere
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
On 7/13/13 1:11 AM, Geoff Canyon wrote:
Can you share this 200-line handler?
No, they'd sue me. But if you can say why you're interested, I could
probably describe it in generic terms. It isn't actually a single
mouseUp, that was just the quickest way to describe it. It's actually a
mouseUp
On 7/12/13 7:57 PM, Monte Goulding wrote:
On 13/07/2013, at 10:37 AM, "J. Landman Gay"
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
hi
Can you share this 200-line handler?
Sent from my iPad
On Jul 12, 2013, at 3:31 PM, "J. Landman Gay" wrote:
> One of the mouseUp behaviors is 200 lines long.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscri
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 for it
On 13/07/2013, at 10:37 AM, "J. Landman Gay" 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 right
> decisions.
I
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,
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
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 beli
On 13/07/2013, at 8:52 AM, Mark Wieder 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.
>
> Absolut
se
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 th
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
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 practic
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
unRev 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/
the correct behavior, and write a long switch structure 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,
On Fri, Jul 12, 2013 at 12:36 PM, Richard Gaskin 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 mentioned the need for a "Co
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.
Pe
It has a small amount of code that's only in there for
development support... standalone building, drag and drop of images onto the
app etc. This code really shouldn't be in the built app. With chained behaviors
I can put it in a support behavior that doesn't get's copied to the 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 i
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 deep
On 7/12/13 2:47 PM, Peter Haworth wrote:
On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay
wrote:
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
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 ex
On 07/12/2013 08: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
beh
On Fri, Jul 12, 2013 at 11:40 AM, Scott Rossi wrote:
> 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
> gives
I meant to say "individual", not "additional". Sorry 'bout that.
On Jul 12, 2013, at 1:53 PM, Chris Sheffield 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 go in and modif
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.
ww
On Fri, Jul 12, 2013 at 11:36 AM, J. Landman Gay
wrote:
> 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 behavior, I could
> have plac
On Fri, Jul 12, 2013 at 10:58 AM, Richard Gaskin 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 experiment (hopefully) makes
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 e
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' ba
ther languages... so what ?!
Dixie
> 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
>
>
>> 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 givin
thworld.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
> 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 o
In my case, I've been waiting years for something like chained behaviors.
I create a lot of custom controls, and the limit of a single behavior per
control was not enough.
At the control level, I use functions and commands are exclusive to a
single control. But at a higher level, I want a s
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
beh
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
Hi Peter,
Am 12.07.2013 um 19:04 schrieb Peter Haworth :
> 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
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 stat
85 matches
Mail list logo
