Re: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

I'm just working on the next issue of Hinduism Today and checking articles in 
and out of version control system dedicated to Indesign that I built... we have 
been using it for 8 years, team loves it..super, super easy, never lost a 
single file... having finally bailed on Adobe's ridiculously complicated and 
error prone VersionCue which they killed (thank god) I said to the team, "We 
don't need to waste any more time or money on any DAM software, let me build 
it." (smile)

In house app here are used to post to our blog daily; and volunteers around the 
world use an LC stand alone to pull audio files from our server and transcript 
them and post the transcript back. That thing has been running flawlessing 
since 2001 (really!) I get auto notifications. Another app, built by Andre is 
also used globally by everyone from "your little sister" to our team work on 
the upload media and enter the metadata of media on our web server.

And here at my desk, if I have to do something twice, I will do it twice; if I 
have to do something three times I will use Livecode. e.g. get the rect and 
filenames of 5,000 images, write out data to a tab delimited file, upload the 
images to the web server and use RevIgniter to read the metadata and add 
records to the database. I don't see how it could be any better or more 
efficient.

But i don't this this is so unusual, I bet there are a lot of such user stories 
hidden away

BR


On April 4, 2016 at 11:23:49 AM, Mark Wieder 
(mwie...@ahsoftware.net) wrote:

> HAP stands for Himalayan Academy Publication (http://himalayanacademy.com/).
> Where we use LC everyday

Sometimes twice a day, I'll bet.

--
Mark Wieder
ahsoftw...@gmail.com
___
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: Script Only Stack Architecture

[Mark Wieder]

On 04/04/2016 01:59 PM, Andre Garzia wrote:


HAP stands for Himalayan Academy Publication (http://himalayanacademy.com/).
Where we use LC everyday


Sometimes twice a day, I'll bet.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
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: Script Only Stack Architecture

[Andre Garzia]

Hey Richard,

I miss you and the gang everyday! I am trying to be more present and want
to learn all the goodies from LC8.

HAP stands for Himalayan Academy Publication (http://himalayanacademy.com/).
Where we use LC everyday

:-D

On Mon, Apr 4, 2016 at 5:10 PM, Richard Gaskin 
wrote:

> Andre Garzia wrote:
>
> > Hey Friends,
> >
> > Long time no see! Loved this thread! In the spirit of working in
> > the open and sharing unfinished (and potentially broken) stuff,
> > I'd welcome you all to take a look into some documentation we're
> > putting into place at:
> >
> >   https://bitbucket.org/hapdevelopers/devdocs/wiki/Home
> >
> > We welcome feedback, advise, suggestions and comments! :D Give use
> > your two livecents! :D
> >
> > PS: The objective is to have a bit of documentation on best practices
> > that we can point developers (internal and external) to.
>
> I have no idea what "HAP" stands for, but I'm very glad to see you back on
> this list!
>
> Hope we'll be seeing more of you.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> 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
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
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: Script Only Stack Architecture

[Richard Gaskin]

Andre Garzia wrote:

> Hey Friends,
>
> Long time no see! Loved this thread! In the spirit of working in
> the open and sharing unfinished (and potentially broken) stuff,
> I'd welcome you all to take a look into some documentation we're
> putting into place at:
>
>   https://bitbucket.org/hapdevelopers/devdocs/wiki/Home
>
> We welcome feedback, advise, suggestions and comments! :D Give use
> your two livecents! :D
>
> PS: The objective is to have a bit of documentation on best practices
> that we can point developers (internal and external) to.

I have no idea what "HAP" stands for, but I'm very glad to see you back 
on this list!


Hope we'll be seeing more of you.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Andre Garzia]

Hey Friends,

Long time no see! Loved this thread! In the spirit of working in the open
and sharing unfinished (and potentially broken) stuff, I'd welcome you all
to take a look into some documentation  we're putting into place at:

  https://bitbucket.org/hapdevelopers/devdocs/wiki/Home

We welcome feedback, advise, suggestions and comments! :D Give use your two
livecents! :D

PS: The objective is to have a bit of documentation on best practices that
we can point developers (internal and external) to.

Cheers
andre

On Mon, Apr 4, 2016 at 5:32 AM, Ali Lloyd  wrote:

> localPath() &
> "main-stack-scripts/generic-mobile-functions_behavior.livecode" is not a
> valid stack reference - it's just a path. Try:
>
> on assignBehaviors
>
> set the behavior of stack "siva-portal-links_behavior" to the long id of
> stack (localPath() &
> "main-stack-scripts/generic-mobile-functions_behavior.livecode")
>
> end assignBehaviors
>
> On Mon, Apr 4, 2016 at 5:42 AM Sannyasin Brahmanathaswami <
> bra...@hindu.org>
> wrote:
>
> > But FWIW.. this does not work
> >
> > on assignBehaviors
> >
> > set the behavior of stack "siva-portal-links_behavior" to (localPath() &
> > "main-stack-scripts/generic-mobile-functions_behavior.livecode")
> >
> > end assignBehaviors
> >
> > OTOH: if you assign the behavior via the inspector to the script-only
> > stack it *does* work..
> >
> > So there must be a syntax for that that we can use also.
> >
> > What is it?
> >
> > On March 31, 2016 at 12:30:50 PM, Ali Lloyd (ali.ll...@livecode.com
> > ) wrote:
> >
> > My solution to this:
> >
> > Stack "MyTestStack" has a field, which is assigned stack
> > "MyBehaviorStack" as its behavior property.
> >
> > Stack "MyBehaviorStack" is a separate stack file.
> >
> > would be to also include the behavior *setting* in the preOpenStack
> handler
> > of "MyTestStack".
> >
> > on preOpenStack
> > set the behavior of field "FieldWithBehavior" of me to  > MyBehaviorStack>
> > end preOpenStack
> > ___
> > 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
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
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: Script Only Stack Architecture

[Ali Lloyd]

localPath() &
"main-stack-scripts/generic-mobile-functions_behavior.livecode" is not a
valid stack reference - it's just a path. Try:

on assignBehaviors

set the behavior of stack "siva-portal-links_behavior" to the long id of
stack (localPath() &
"main-stack-scripts/generic-mobile-functions_behavior.livecode")

end assignBehaviors

On Mon, Apr 4, 2016 at 5:42 AM Sannyasin Brahmanathaswami 
wrote:

> But FWIW.. this does not work
>
> on assignBehaviors
>
> set the behavior of stack "siva-portal-links_behavior" to (localPath() &
> "main-stack-scripts/generic-mobile-functions_behavior.livecode")
>
> end assignBehaviors
>
> OTOH: if you assign the behavior via the inspector to the script-only
> stack it *does* work..
>
> So there must be a syntax for that that we can use also.
>
> What is it?
>
> On March 31, 2016 at 12:30:50 PM, Ali Lloyd (ali.ll...@livecode.com
> ) wrote:
>
> My solution to this:
>
> Stack "MyTestStack" has a field, which is assigned stack
> "MyBehaviorStack" as its behavior property.
>
> Stack "MyBehaviorStack" is a separate stack file.
>
> would be to also include the behavior *setting* in the preOpenStack handler
> of "MyTestStack".
>
> on preOpenStack
> set the behavior of field "FieldWithBehavior" of me to  MyBehaviorStack>
> end preOpenStack
> ___
> 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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

But FWIW.. this does not work

on assignBehaviors

set the behavior of stack "siva-portal-links_behavior" to (localPath() & 
"main-stack-scripts/generic-mobile-functions_behavior.livecode")

end assignBehaviors

OTOH: if you assign the behavior via the inspector to the script-only stack it 
*does* work..

So there must be a syntax for that that we can use also.

What is it?

On March 31, 2016 at 12:30:50 PM, Ali Lloyd 
(ali.ll...@livecode.com) wrote:

My solution to this:

Stack "MyTestStack" has a field, which is assigned stack
"MyBehaviorStack" as its behavior property.

Stack "MyBehaviorStack" is a separate stack file.

would be to also include the behavior *setting* in the preOpenStack handler
of "MyTestStack".

on preOpenStack
set the behavior of field "FieldWithBehavior" of me to 
end preOpenStack
___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

Interesting caveat here.  Could be "Major"

You can edit the script as you say, and save

But if you go to the stack inspector for the script only stack and assign a 
behavior...ala class, super class
it will begin to work in this session...So you think "aha. how cool, cascading 
hierarchy..." So then you pay very careful attention save everthing, save the 
whole universe! Ha!

Reboot your stack... inspect the script only stack and the parent behavior 
script you assigned is gone.

I guess this make sense from one point of view, as Mark pointed out in his 
blog, these are just text files with zero additional properties.

So the Inspector "fakes you out" by implying that you can set a behavior for a 
script only stack, but in fact, that appears, for the moment, impossible 
(unless you were to set them run time)

So this is one of the causes of my thinking the stacks were not in the message 
path... in fact they were, but the assigned behaviors I given those script only 
stack was missing and *not* in the msg path, even though the uber parent was 
open and in memory.

So, Richard, your vision of class/super class etc. I'm not seeing how that can 
be done with script only stacks.

Or, are we missing something? I'll report this and perhaps HQ will respond on 
the ticket with ideas.


On April 2, 2016 at 8:22:22 PM, J. Landman Gay 
(jac...@hyperactivesw.com) wrote:

If you have the script editor in focus and frontmost (i.e., you're
working in it) you can just Cmd-S and the stack will save.
___
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: Script Only Stack Architecture

[J. Landman Gay]

On 4/3/2016 7:31 AM, Kay C Lan wrote:

PS Unfortunately if you click on the 'button' link against
Associations it doesn't take you back to the relevant button page with
all it's Associations. Hopefully they are working on that.


Works okay here in dp16.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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: Script Only Stack Architecture

[Kay C Lan]

On Sun, Apr 3, 2016 at 2:18 PM, Richard Gaskin
 wrote:

> Yeah, not my favorite either.

Whilst I don't wish to kerb anyone's enthusiasm to contribute to Max's
or anyone else's Wiki, I do have two concerns. Clearly, the spare time
of this Community to contribute to any community effort (be it bug
reports, code or documentation) is very limited. 5 min contributing to
a Wiki is 5 min not improving the actual Dictionary entry. Also,
Wiki's generally need an internet connection to access. I spend a LOT
of time with slow or no internet.

Richard wrote: "Drafting a functional spec and work plan would take
much more time", but clearly a LOT of thought and time has already
gone into the new Dictionary, it's markup, what kind of beast it is. I
like the fact that it's becoming the centralised location for
documentation, be it language (API) entries or guides - hopefully also
these new style Tutorials. Thankfully I can access everything
offline!!

When I wrote the Dictionary is a glorified Wiki, sometimes the term
'glorified' can have negative connotations. My intention was far more
positive, the Dictionary is a couple of steps up, on a much higher
plain than a Wiki. Although we've had Easter, here's a Dictionary
Easter Egg (although I'll probably discover everyone else knew this
but me)

In the LC 8 dp15+ Dictionary search box Enter 'button' - you should
have 3 exact matches. If you click on the 3rd one, you should get a
list of all* the messages that can be sent/received by a button,
followed by all* properties associated with a button.

*all being determined by each specific Dictionary entry having the
correct markup. If you click on the first Message link: arrowKey -
you'll be taken to it's specific Dictionary entry. Note the 3rd line:
Associations button. This is how the Dictionary knows. This is why the
Dictionary is better than a Wiki because the team has already spent a
lot of time with the Dictionary spec to take it well beyond a simple
Wiki.

PS Unfortunately if you click on the 'button' link against
Associations it doesn't take you back to the relevant button page with
all it's Associations. Hopefully they are working on that.

PPS I think Charles' offer to help handle DOC PRs for the Gitphobic is
a much better road to go down.

___
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: Script Only Stack Architecture

[J. Landman Gay]

On 4/3/2016 12:37 AM, Sannyasin Brahmanathaswami wrote:

If setting the stack files and opening them in the preopenhandler
works, that's what I'll do, if the only certain way to save script
only stacks is by clicking on the contextual menu and explicitely
choosing "Save" (in  the AB and PB) that's what I'll do.


If you have the script editor in focus and frontmost (i.e., you're 
working in it) you can just Cmd-S and the stack will save.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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: Script Only Stack Architecture

[Richard Gaskin]

Bill Prothero wrote:

> I wonder how hard it would be to port max's Wikia wiki to a less
> commercial host. I am  skeptical of those free sites dedicated to
> scraping user information for data mining purposes.

Yeah, not my favorite either. The one advantage is the price, but as 
they say, you get what you pay for.


I'd host it at LiveCode Journal or anywhere else Max is willing to move it.

Anyone interested in heading this up enough to drop him a note to see if 
he's up for a move?


> Livecode could support it as part of their resources, as an
> experiment to see how it develops?

They certainly have the web space, but it's been more than two years 
since I started what's become a surprisingly long process to try to 
coordinate some community web efforts, so I'm happy to let them focus on 
the engine right now and for things like this explore options that 
neither distract them nor hold us back.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> ... if the only certain way to save script only stacks is by clicking
> on the contextual menu and explicitely choosing "Save" (in  the AB
> and PB) that's what I'll do.

...or typing Cmd-S while in the Script Editor, or choosing File->Save 
from the main menu bar, or any other way you normally save any stack.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Earthednet-wp]

I wonder how hard it would be to port max's Wikia wiki to a less commercial 
host. I am  skeptical of those free sites dedicated to scraping user 
information for data mining purposes. Livecode could support it as part of 
their resources, as an experiment to see how it develops?

Bill

William Prothero
http://es.earthednet.org

> On Apr 2, 2016, at 2:44 PM, Richard Gaskin  wrote:
> 
> Sannyasin Brahmanathaswami
> 
> > Kay C Lan wrote:
> >>
> >> IMO the ideal solution would be the Dictionary act like a Wiki
> >> Editor.
> >
> > I had a parallel thought this morning. Many languages have their
> > "wiki space"
> >
> > Given the enormity of the task of turning the dictionary into
> > something like that...don't bother... let it be what it is. Just
> > start a new empty wiki.
> >
> > Begin simply: As soon as subject arise of value, instantiate the
> > subject / theme and put the info there.
> >
> > I would be happy to participate.
> 
> MaxV already started one - dive in:
> 
> 
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> 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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

I think I'm too bitten (happily so) now with the class/super/class behaviors 
hierarchy ( have already set the behavior of a behavior, fantastic!)   In fact 
it's hard to stop envisioning all the ways to use this feature, and I don't 
want the bound up in a single binary file object... as the goal is, in the next 
few months to distribute the developement across a bigger team.

So I'm going to get work done now ... I have flown to the world of WHEW  
(WHatEver Works)

If setting the stack files and opening them in the preopenhandler works, that's 
what I'll do, if the only certain way to save script only stacks is by clicking 
on the contextual menu and explicitely choosing "Save" (in  the AB and PB) 
that's what I'll do.

My auto save is working (every 30  min), and I'm saving more frequently,  so I 
can recover quickly.

I got a lot done today...

What I will  give myself a break on is reporting all the bugs in LC816 and just 
push to work around them...or ask here, since (as we are seeing with formatted 
height) others have worked around bugs before.

BR



On April 2, 2016 at 5:43:32 PM, Richard Gaskin 
(ambassa...@fourthworld.com) wrote:

You've had a wide range of issues to contend with, from file corruption
to mysterious plugins and more. Give yourself a break for a day or two:
get one thing working, and only then change something else.

Sorting out the behaviors would seem to merit attention. If script-only
files are a distraction setting them aside and just using the binary
stacks you seem more comfortable with for now will let you focus on one
thing at a time.
___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Small addendum, now that I'm actually using them. Today, though I
> had added them as stack files, my three external stack file
> behaviors were still not in the message path.

That's contrary to my own experience, which I'd tested again to make 
double-sure just the other morning before I posted the note about 
stackFiles.


There must be something else going on.  Without seeing the complete 
collection of stack files I'm unable to offer further advice on this.



> Not clear to me yet exactly when and how you can trigger a save of
> an external script only stack.

Have you tried the "save" command?


The other day I wrote:

   It may be helpful while demystifying this to work with ordinary
   stack files for your behavior scripts.  There's really no
   difference between ordinary stack files and script-only stack
   files beyond the storage format, but if nothing else sense
   you're already confident in your use of normal stacks it may
   help you focus on the things that may actually be the source of
   the problem.

You've had a wide range of issues to contend with, from file corruption 
to mysterious plugins and more.  Give yourself a break for a day or two: 
 get one thing working, and only then change something else.


Sorting out the behaviors would seem to merit attention.  If script-only 
files are a distraction setting them aside and just using the binary 
stacks you seem more comfortable with for now will let you focus on one 
thing at a time.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

 
Small addendum, now that I'm actually using them. Today, though I had added 
them as stack files, my three external stack file behaviors were still not in 
the message path.

But, now, having added them it the stack files.. you can open them without 
declaring a path.  


command initializeInterface
set the defaultstack to "SivaSiva"
open stack "generic-mobile-functions_behavior"
open stack "siva_fields_behavior
open stack "siva_portal-links_behavior"


Now they a) appear in the behaviors area to be chosen and applied b) work... 

STILL MYSTERIOUS

Not clear to me yet exactly when and how you can trigger a save of an external 
script only stack.

Once you get the hang of this, the new edit script button in the behaviors for 
your object is going to be your go to button.. edit the exteral script apply.. 
let's say you have done extensive changes in to that script only stack behavior.

At that moment, how do you save it? When I save the main stack, the Modal 
feedback does not show the external stacks being saved... on the main stack and 
1 binary substack.



On April 1, 2016 at 4:34:56 AM, Ali Lloyd 
(ali.ll...@livecode.com(mailto:ali.ll...@livecode.com)) wrote:

> > > > ergo: merely opening a script-only stack that is applied as a
> > > > behavior to a control (not global in scope) does *not* place
> > > > into the msg path.
___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami

> Kay C Lan wrote:
>>
>> IMO the ideal solution would be the Dictionary act like a Wiki
>> Editor.
>
> I had a parallel thought this morning. Many languages have their
> "wiki space"
>
> Given the enormity of the task of turning the dictionary into
> something like that...don't bother... let it be what it is. Just
> start a new empty wiki.
>
> Begin simply: As soon as subject arise of value, instantiate the
> subject / theme and put the info there.
>
> I would be happy to participate.

MaxV already started one - dive in:



--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

Kay C Lan wrote:

IMO the ideal solution would be the Dictionary act like a Wiki Editor.


I had a parallel thought this morning. Many languages have their "wiki space"

Given the enormity of the task of turning the dictionary into something like 
that...don't bother... let it be what it is. Just start a new empty wiki.

Begin simply: As soon as subject arise of value, instantiate the subject / 
theme and put the info there.

I would be happy to participate. I probably would be better than what I do now: 
copy out and save snippets from email to files on disk...

So if you want to learn more about "behavior" just search the wiki... not the 
dictionary.

of course even managing a wiki is more over head for someone.
___
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: Script Only Stack Architecture

[Richard Gaskin]

Kay C Lan wrote:

And now stepping on very thin ice I will go against the grain of 'User
Notes' as previously implemented and currently re-suggested. Again, as
an interim step I see them as very useful for capturing nuggets of
information. The great thing about them is, as stated by Jacque, you
don't need to learn any markup (or Git), and you can (could) do it
immediately.

IMO the ideal solution would be the Dictionary act like a Wiki Editor.
Those with Contributor Accounts get Edit buttons in each of the
relevant sections of each Dictionary entry. You want to add an
excellent example, then you click the Example section Edit button and
you add it right there, where it should be, and where it will be
automatically colour coded; not at the bottom of a dozen other
people's User Notes in lost black and white. You have a Warning,
Caution or Tip that needs highlighting, then that is how it's
presented; again not hidden amongst other User Notes in the same bland
font. Also, a one line Example entry would be just that, a one line
entry. The User Note format bloats it out with inclusion of who added
it, and a time stamp and a couple of blank lines around the entry so a
single line of relevance takes up 4 or 5 lines of Dictionary screen
space. I personally don't need my name attached to every contribution
I make - for those that do, maybe a list of Doc Contributor names in
the About Livecode box similar to the list of names of LC Community
contributors that currently appears.

The Dictionary is really only a glorified Wiki. I suspect most people
believe the success of Wikis is due to community contribution, but I
believe just as important is Wikis FORCE a standard format and
presentation, everything in it's right place, everything found where
it should be. I think one of the problems Richard alludes to re bloat
can be avoided if people are forced to think where exactly in the
Dictionary entry structure does my nugget of information fit in and
how do I word it so it does fit with the paragraph before and after.
As a bonus, you can also quickly correct that minor spelling error in
the preceding paragraph.

The Dictionary is just another Livecode stack, so this is all possible
with the talent and technology we have in front of us, the hardest
thing to implement would be the Git integration so that each
addition/amendment is vetted before inclusion with the next release
and visible to the rest of us.

Actually the biggest problem is who(s) is going to do build it. I
believe the Team is still looking for a Community Docs advocate/leader
to corral those with such inclinations and ideas. The reality is the
former idea of User Notes is probably a lot easier/quicker to
implement than turning the Dictionary into an .lcdoc Editor/Git
Integrator.

I should probably keep my big mouth shut from now on as the ice has
surely broken and I'm in very deep water.


Au contraire.  I've quoted the meat of that post intact, long as it is, 
because I feel it merits a second read.  It's a very good collection of 
ideas which, if implemented, could greatly streamline community 
contributions to the Dictionary.


And like the rest of the clarity expressed there, you hit the hardest 
part spot-on:


   Actually the biggest problem is who(s) is going to do build it.

A project of this scope would be a considerable undertaking.  The team 
could do it, but it would need to go into queue after the current 
objectives and the rest of the Kickstarter goals, so let's politely just 
file that notion under "Not Soon". :)


The community could do it, but finding the intersection of interest, 
skill, and available time would be at best very difficult.  It's not 
like one of the joyous one-offs we toss together, like Richmond's IDE 
mods or my 20-line script that makes revMenubar look more Ubuntu-like. 
This is a big task, big enough to warrant a team and a Gantt chart.


Conceiving such a system is brilliant but takes only a few minutes to 
draft an outline like the one above.  Drafting a functional spec and 
workplan would take much more time, and coding it, testing it, and 
building maintenance systems for it would be a pretty hefty commitment.


All of it is indeed very achievable in LiveCode.  The project I work on 
for emergency medicine is similar in scope, and all of it -- from the 
client to the server all the way down to the data store and Web 
publishing subsystem -- was built entirely in LiveCode.  But it was 
funded by a fairly large company with a clear upside for the investment.


Here the ROI is arguably strong but not quite as strong, when we 
consider that Github's Markdown is fairly easy to learn and can be used 
gracefully in any text editor, even their online form.


So I like the idea.  Very much.  And if we can get resources who could 
commit to seeing it through I'd love to work with it.  But the ROI may 
be difficult to justify, as it would require a lot of people's time away 
from other activities.


--
 Richard Gaskin
 Fourth 

Re: Script Only Stack Architecture

[Kay C Lan]

On Sat, Apr 2, 2016 at 9:45 AM, Sannyasin Brahmanathaswami
 wrote:
> How do we do that. Via Git hub? we pull the entry edit and then push back 
> with changes?
>
Those who want to contribute will find Ali's guide essential:

https://github.com/livecode/livecode/blob/community-docs/docs/contributing_to_docs.md

Richard has also linked a couple of times to this Blog post which
links to the above:

https://livecode.com/putting-the-you-in-documentation/

And now stepping on very thin ice I will go against the grain of 'User
Notes' as previously implemented and currently re-suggested. Again, as
an interim step I see them as very useful for capturing nuggets of
information. The great thing about them is, as stated by Jacque, you
don't need to learn any markup (or Git), and you can (could) do it
immediately.

IMO the ideal solution would be the Dictionary act like a Wiki Editor.
Those with Contributor Accounts get Edit buttons in each of the
relevant sections of each Dictionary entry. You want to add an
excellent example, then you click the Example section Edit button and
you add it right there, where it should be, and where it will be
automatically colour coded; not at the bottom of a dozen other
people's User Notes in lost black and white. You have a Warning,
Caution or Tip that needs highlighting, then that is how it's
presented; again not hidden amongst other User Notes in the same bland
font. Also, a one line Example entry would be just that, a one line
entry. The User Note format bloats it out with inclusion of who added
it, and a time stamp and a couple of blank lines around the entry so a
single line of relevance takes up 4 or 5 lines of Dictionary screen
space. I personally don't need my name attached to every contribution
I make - for those that do, maybe a list of Doc Contributor names in
the About Livecode box similar to the list of names of LC Community
contributors that currently appears.

The Dictionary is really only a glorified Wiki. I suspect most people
believe the success of Wikis is due to community contribution, but I
believe just as important is Wikis FORCE a standard format and
presentation, everything in it's right place, everything found where
it should be. I think one of the problems Richard alludes to re bloat
can be avoided if people are forced to think where exactly in the
Dictionary entry structure does my nugget of information fit in and
how do I word it so it does fit with the paragraph before and after.
As a bonus, you can also quickly correct that minor spelling error in
the preceding paragraph.

The Dictionary is just another Livecode stack, so this is all possible
with the talent and technology we have in front of us, the hardest
thing to implement would be the Git integration so that each
addition/amendment is vetted before inclusion with the next release
and visible to the rest of us.

Actually the biggest problem is who(s) is going to do build it. I
believe the Team is still looking for a Community Docs advocate/leader
to corral those with such inclinations and ideas. The reality is the
former idea of User Notes is probably a lot easier/quicker to
implement than turning the Dictionary into an .lcdoc Editor/Git
Integrator.

I should probably keep my big mouth shut from now on as the ice has
surely broken and I'm in very deep water.

___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

How do we do that. Via Git hub? we pull the entry edit and then push back with 
changes?

The user notes option is still not available. So, yes Jacque is right, but we 
can do it

On April 1, 2016 at 4:51:23 AM, Richard Gaskin 
(ambassa...@fourthworld.com) wrote:

And I continue to believe that
adding whatever notes to a Dictionary entry one feels will prevent a
similar question
___
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: Script Only Stack Architecture

[James Hale]

Mark wrote:
> 
> In addition, the Project Browser that I'm usually kicking has a very 
> nice feature in that if there is a behavior object associated with a 
> stack or control you will see that indicated to the left of the script 
> lines, and it also shows the number of lines in the behavior script. 
> Right-click or control-click on that and you can directly edit the 
> behavior script.

Or just double-click (I am on a Mac)
Use it all the time.
Can't remember the last time I have actually gone to my card with the behavior 
buttons.

James

___
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: Script Only Stack Architecture

[Richard Gaskin]

William Prothero wrote:
> I think the salient points are the various ways of getting behaviors
> to instantiate properly. There have been a number of ideas that all
> seem to work. So what I suggest, is that a brief description of each
> strategy (1-2 sentences) and a bit of sample code (where appropriate)
> like the sample that Ali provided. The long discussions about message
> paths, etc should be shortened to “just the beef”. The code snippets
> that demo the “working” way to implement the strategy would then make
> sure folks understood how to make it work.

Sounds good.  Who wants to write it?  And where should it go?

It's also worth noting that Ali's method is an uncommon one, useful in 
the IDE and other somewhat specialized cases, but not ideal for many, 
for the reasons I outlined earlier:



--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[William Prothero]

Richard and Matt:
I think the salient points are the various ways of getting behaviors to 
instantiate properly. There have been a number of ideas that all seem to work. 
So what I suggest, is that a brief description of each strategy (1-2 sentences) 
and a bit of sample code (where appropriate) like the sample that Ali provided. 
The long discussions about message paths, etc should be shortened to “just the 
beef”. The code snippets that demo the “working” way to implement the strategy 
would then make sure folks understood how to make it work.
Bill

> On Apr 1, 2016, at 3:04 PM, Richard Gaskin  wrote:
> 
> Matt Maier wrote:
>> I never suggested you write it.
> 
> The word "you" threw me off.  Thanks for the clarification.
> 
>> I objected to you advising the mailing list not to include this
>> discussion in the Dictionary because it would start down a slippery
>> slope towards "too big."
> 
> This discussion is many pages long and involves a wide range of keywords and 
> concepts, begging the question:  What should be written, and where?
> 
> Many here have expressed the opinion that something should be added 
> somewhere, but so far only two have offered specific suggestions, and they 
> differ from one another.
> 
> In both of those cases (and more than a few others) I've very explicitly 
> encouraged them to contribute their additions to the docs - once more in case 
> it was missed:
> 
>As I've noted here before, this blog post offers some helpful
>guidance for community members to get started contributing to
>the documentation to make it more of they want:
>
> 
> My "Yes" was indeed a "Yes, and.." with the "and" being to please be mindful 
> of the different types of documentation people use, and the intended audience 
> and scope for each.
> 
> Specifically, I wrote:  "Go for it, but please be brief in Dictionary 
> entries."
> 
> Hardly seems the stuff of wholesale discouragement.
> 
> And all the while the core question remains outstanding with no submission to 
> the docs: What should be written, and where?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> 
> ___
> 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: Script Only Stack Architecture

[Richard Gaskin]

Matt Maier wrote:

I never suggested you write it.


The word "you" threw me off.  Thanks for the clarification.


I objected to you advising the mailing list not to include this
discussion in the Dictionary because it would start down a slippery
slope towards "too big."


This discussion is many pages long and involves a wide range of keywords 
and concepts, begging the question:  What should be written, and where?


Many here have expressed the opinion that something should be added 
somewhere, but so far only two have offered specific suggestions, and 
they differ from one another.


In both of those cases (and more than a few others) I've very explicitly 
encouraged them to contribute their additions to the docs - once more in 
case it was missed:


As I've noted here before, this blog post offers some helpful
guidance for community members to get started contributing to
the documentation to make it more of they want:


My "Yes" was indeed a "Yes, and.." with the "and" being to please be 
mindful of the different types of documentation people use, and the 
intended audience and scope for each.


Specifically, I wrote:  "Go for it, but please be brief in Dictionary 
entries."


Hardly seems the stuff of wholesale discouragement.

And all the while the core question remains outstanding with no 
submission to the docs: What should be written, and where?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Matt Maier]

I never suggested you write it. I objected to you advising the mailing list
not to include this discussion in the Dictionary because it would start
down a slippery slope towards "too big."

On Fri, Apr 1, 2016 at 7:50 AM, Richard Gaskin 
wrote:

> Kay C Lan wrote:
>
> > On Fri, Apr 1, 2016 at 9:43 AM, Richard Gaskin wrote:
> >>
> >> That's precisely why I advocate maintaining the Dictionary as
> >> an essential reference (as in "essence"); it should be easy
> >> to link to relevant tutorials and guides for more complete
> >> discussion when desired.
> >>
> > Could you give me an example of a Dictionary entry that has a link
> > to a Guide or Tutorial?
>
> So many things in my life would be much simpler if "advocate" meant the
> same as "have been given authority and resources to have done it".
>
> But unfortunately my world is not so simple. :)
>
> So in short, "not yet".
>
>
> > Would they just be included in the Reference Tag or as a basic html
> > link to Tutorials?
>
> Matt's request (in keeping with many others') is that we try to avoid
> requiring users to go to a generic Search or index to find things, that we
> "put the information where they need it", and I've wholeheartedly agreed.
>
> To support that I would advocate that such links would be included
> directly in the Markdown of relevant Dictionary entries.
>
> As for the alternative, in v8 I believe all tutorials and guides are
> already listed in the Help index, no?
>
>
> > Whilst I agree with you in principle, and that is certainly the
> > destination we need to be headed
>
> Glad to hear it.  Peter Brett and I have some similar ideas about how to
> take advantage of the new docs format, now that the team has completed the
> considerable task of converting everything to Markdown.  If you like that
> idea I'm sure you'll like many of Peter's even more.
>
>
> > at this point in time I've got to agree with Matt.
>
> As I have.  I've very explicitly and repeatedly encouraged people here to
> have exactly what they want by making it so:
>
>As I've noted here before, this blog post offers some helpful
>guidance for community members to get started contributing to
>the documentation to make it more of they want:
>
>
> The only place Matt and I disagree is the suggestion that I write it.
>
> My work with LC is as a volunteer, not an employee.  And since my own
> experience has me inclined to try to meet the need expressed in this thread
> through different means, I'm not able to guess what other people may find
> ideal for this.
>
> In short, I have neither the time nor talent to do what's been requested
> of me.
>
> But I have encouraged others to do so.  And I continue to believe that
> adding whatever notes to a Dictionary entry one feels will prevent a
> similar question from coming up in the future is best done by doing it, or
> at least submitting it as an enhancement request to the bug queue for
> someone else to do, as opposed to just writing it here in a mailing list
> where it's almost guaranteed to be forgotten.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> 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: Script Only Stack Architecture

[Richard Gaskin]

J. Landman Gay wrote:

> I think a lot of the issues being discussed here could be easily
> solved if the user notes feature was reimplemented.

Agreed.

That's been discussed here before, but it seems no one had mentioned it 
in a bug report where it could become actionable - Mark Waddingham 
finally did so on Feb 10:



Thanks, Mark.  It'll be good to see that back in place.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Phil Davis]

Well said Jacque! (Like I'm surprised)

Phil Davis


On 4/1/16 9:10 AM, J. Landman Gay wrote:
I think a lot of the issues being discussed here could be easily 
solved if the user notes feature was reimplemented. I found those very 
helpful. And there are many advantages: users can contribute quickly, 
no one needs to learn a foreign tracking system, users are more likely 
to jot down concepts they've struggled with and solved if it's easy to 
do, and the comments don't interfere with the basic structure of the 
actual dictionary entries.


It was a great solution to the problems we're discussing.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
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



--
Phil Davis


___
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: Script Only Stack Architecture

[Peter Haworth]

lcStackbrowser shows an icon for the object's script and one icon for each
of its behavior scripts. Clicking on any of them opens the appropriate
script.  In addition, the tooltip for an object lists how many lines are in
its script, the objects in its behavior chain and how many lines are in
each behavior script.

On Fri, Apr 1, 2016 at 8:39 AM Mark Wieder  wrote:

> On 04/01/2016 07:34 AM, Ali Lloyd wrote:
> >> It's a pain to open the object inspector and copy the behavior reference
> >> then use the message box to to "open script of…"
> >
> > This is no longer necessary in the latest DPs of 8.0 - the behavior
> > property in the property inspector has an 'edit script' button.
>
> In addition, the Project Browser that I'm usually kicking has a very
> nice feature in that if there is a behavior object associated with a
> stack or control you will see that indicated to the left of the script
> lines, and it also shows the number of lines in the behavior script.
> Right-click or control-click on that and you can directly edit the
> behavior script.
>
> --
>   Mark Wieder
>   ahsoftw...@gmail.com
>
> ___
> 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: Script Only Stack Architecture

[J. Landman Gay]

I think a lot of the issues being discussed here could be easily solved if 
the user notes feature was reimplemented. I found those very helpful. And 
there are many advantages: users can contribute quickly, no one needs to 
learn a foreign tracking system, users are more likely to jot down concepts 
they've struggled with and solved if it's easy to do, and the comments 
don't interfere with the basic structure of the actual dictionary entries.


It was a great solution to the problems we're discussing.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
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: Script Only Stack Architecture

[Mark Wieder]

On 04/01/2016 07:34 AM, Ali Lloyd wrote:

It's a pain to open the object inspector and copy the behavior reference
then use the message box to to "open script of…"


This is no longer necessary in the latest DPs of 8.0 - the behavior
property in the property inspector has an 'edit script' button.


In addition, the Project Browser that I'm usually kicking has a very 
nice feature in that if there is a behavior object associated with a 
stack or control you will see that indicated to the left of the script 
lines, and it also shows the number of lines in the behavior script. 
Right-click or control-click on that and you can directly edit the 
behavior script.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
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: Script Only Stack Architecture

[Richard Gaskin]

Kay C Lan wrote:

> On Fri, Apr 1, 2016 at 9:43 AM, Richard Gaskin wrote:
>>
>> That's precisely why I advocate maintaining the Dictionary as
>> an essential reference (as in "essence"); it should be easy
>> to link to relevant tutorials and guides for more complete
>> discussion when desired.
>>
> Could you give me an example of a Dictionary entry that has a link
> to a Guide or Tutorial?

So many things in my life would be much simpler if "advocate" meant the 
same as "have been given authority and resources to have done it".


But unfortunately my world is not so simple. :)

So in short, "not yet".


> Would they just be included in the Reference Tag or as a basic html
> link to Tutorials?

Matt's request (in keeping with many others') is that we try to avoid 
requiring users to go to a generic Search or index to find things, that 
we "put the information where they need it", and I've wholeheartedly agreed.


To support that I would advocate that such links would be included 
directly in the Markdown of relevant Dictionary entries.


As for the alternative, in v8 I believe all tutorials and guides are 
already listed in the Help index, no?



> Whilst I agree with you in principle, and that is certainly the
> destination we need to be headed

Glad to hear it.  Peter Brett and I have some similar ideas about how to 
take advantage of the new docs format, now that the team has completed 
the considerable task of converting everything to Markdown.  If you like 
that idea I'm sure you'll like many of Peter's even more.



> at this point in time I've got to agree with Matt.

As I have.  I've very explicitly and repeatedly encouraged people here 
to have exactly what they want by making it so:


   As I've noted here before, this blog post offers some helpful
   guidance for community members to get started contributing to
   the documentation to make it more of they want:
   

The only place Matt and I disagree is the suggestion that I write it.

My work with LC is as a volunteer, not an employee.  And since my own 
experience has me inclined to try to meet the need expressed in this 
thread through different means, I'm not able to guess what other people 
may find ideal for this.


In short, I have neither the time nor talent to do what's been requested 
of me.


But I have encouraged others to do so.  And I continue to believe that 
adding whatever notes to a Dictionary entry one feels will prevent a 
similar question from coming up in the future is best done by doing it, 
or at least submitting it as an enhancement request to the bug queue for 
someone else to do, as opposed to just writing it here in a mailing list 
where it's almost guaranteed to be forgotten.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Ali Lloyd]

> It's a pain to open the object inspector and copy the behavior reference
> then use the message box to to "open script of…"

This is no longer necessary in the latest DPs of 8.0 - the behavior
property in the property inspector has an 'edit script' button.

On Fri, Apr 1, 2016 at 3:21 PM Peter M. Brigham  wrote:

> Re this discussion on behaviors and chained behaviors, would there be any
> use for a new engine-based property like "the effective scripts of
> " that would return the script of the object and all the behavior
> scripts in its chain? Perhaps as an array, with the control references as
> keys? I don't use behaviors much, but I sometimes run into the problem of
> needing to access the behavior script of an object, when I've forgotten
> which behavior button I used. It's a pain to open the object inspector and
> copy the behavior reference then use the message box to to "open script of…"
>
> But as I say, I don't use behaviors as much as I should, perhaps. Those
> who use them a lot will be better able to chime in on how useful or
> superfluous the idea might be.
>
> -- Peter
>
> Peter M. Brigham
> pmb...@gmail.com
> http://home.comcast.net/~pmbrig
>
>
> On Mar 31, 2016, at 3:43 PM, Richard Gaskin wrote:
>
> > Sannyasin Brahmanathaswami wrote:
> >
> > > ergo: merely opening a script-only stack that is applied as a
> > > behavior to a control (not global in scope) does *not* place
> > > into the msg path.
> >
> > Respectfully, your recipe would be easier to follow without the steps
> unrelated to the actions we're exploring (making folders and such - the
> folder locations are unrelated to the problem).
> >
> > Remember guideline #2 in my earlier post:
> >
> >  2. When using behaviors, the object containing the behavior script
> > must be in memory when anything relying on it is brought into
> > memory.
> > 
> >
> > If I'm following your recipe correctly, the field object that uses the
> behavior is in a stack that opens and then loads the stack used to define
> the behavior.
> >
> > This means that at the moment the field object is unpacked for use it
> contains a reference to a behavior object not yet in memory.
> >
> > The engine (in its current form; we can expect this to be improved later
> as time permits) will only attempt to resolve a behavior once, when the
> object dependent on the behavior is brought into memory.
> >
> > Even if you later open a stack containing the behavior script, by that
> time it's too late.  The object depending on it has already been unpacked,
> the behavior reference already attempted, and having failed it will not be
> retried as other stacks are later opened.
> >
> > For the moment let's forget that in your case the stack file used as a
> behavior object is a script-only stack.  The storage format doesn't affect
> anything at runtime, and may be distracting here.  Let's just focus on the
> load order:
> >
> >
> > SIMPLIFIED RECIPE
> > -
> > Stack "MyTestStack" has a field, which is assigned stack
> "MyBehaviorStack" as its behavior property.
> >
> > Stack "MyBehaviorStack" is a separate stack file.
> >
> >
> > POSSIBLE SOLUTIONS
> > --
> > Options for correct behavior esolution when "MyTestStack" is loaded
> include:
> >
> >
> > a) Open "MyBehaviorStack" first.
> >   -
> >   In an application this may mean introducing one more stack, which
> >   we could call "MyBootStack", which first opens "MyBehaviorStack"
> >   and then opens "MyTestStack".
> >
> >
> > b) Load "MyBehaviorStack" into memory without opening it.
> >   --
> >   This can be done by accessing a property of "MyBehaviorStack",
> >   such as the stack's name.  This still requires "MyBootStack"
> >   to make sure that "MyBehaviorStack" is in memory before
> >   "MyTestStack" is opened, but has the minor convenience of
> >   not being visible to the user and triggers no opening messages.
> >
> >
> > c) Include "MyBehaviorStack" in the stackFiles prop of "MyTestStack".
> >   -
> >   Any stack files specified in the stackFiles property of a stack
> >   are loaded into memory at the same time the stack containing that
> >   list is loaded.  In terms of boot sequence it's functionally
> >   similar to having those separate stack files as substacks, but
> >   with the advantage of keeping them separate.
> >
> >
> > a) and b) conform to Guideline #2 above in an obvious way, explicitly
> putting "MyBehaviorStack" into memory before "MyTestStack" will be opened
> to need it.
> >
> > c) works because stack files listed in the stackFiles property are all
> loaded with the stack listing them, before behavior resolution takes place.
> >
> >
> > This seems harder than it is in part because you're super smart and are
> just thinking too hard. :)

Re: Script Only Stack Architecture

[Peter M. Brigham]

Re this discussion on behaviors and chained behaviors, would there be any use 
for a new engine-based property like "the effective scripts of " that 
would return the script of the object and all the behavior scripts in its 
chain? Perhaps as an array, with the control references as keys? I don't use 
behaviors much, but I sometimes run into the problem of needing to access the 
behavior script of an object, when I've forgotten which behavior button I used. 
It's a pain to open the object inspector and copy the behavior reference then 
use the message box to to "open script of…" 

But as I say, I don't use behaviors as much as I should, perhaps. Those who use 
them a lot will be better able to chime in on how useful or superfluous the 
idea might be.

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig


On Mar 31, 2016, at 3:43 PM, Richard Gaskin wrote:

> Sannyasin Brahmanathaswami wrote:
> 
> > ergo: merely opening a script-only stack that is applied as a
> > behavior to a control (not global in scope) does *not* place
> > into the msg path.
> 
> Respectfully, your recipe would be easier to follow without the steps 
> unrelated to the actions we're exploring (making folders and such - the 
> folder locations are unrelated to the problem).
> 
> Remember guideline #2 in my earlier post:
> 
>  2. When using behaviors, the object containing the behavior script
> must be in memory when anything relying on it is brought into
> memory.
> 
> 
> If I'm following your recipe correctly, the field object that uses the 
> behavior is in a stack that opens and then loads the stack used to define the 
> behavior.
> 
> This means that at the moment the field object is unpacked for use it 
> contains a reference to a behavior object not yet in memory.
> 
> The engine (in its current form; we can expect this to be improved later as 
> time permits) will only attempt to resolve a behavior once, when the object 
> dependent on the behavior is brought into memory.
> 
> Even if you later open a stack containing the behavior script, by that time 
> it's too late.  The object depending on it has already been unpacked, the 
> behavior reference already attempted, and having failed it will not be 
> retried as other stacks are later opened.
> 
> For the moment let's forget that in your case the stack file used as a 
> behavior object is a script-only stack.  The storage format doesn't affect 
> anything at runtime, and may be distracting here.  Let's just focus on the 
> load order:
> 
> 
> SIMPLIFIED RECIPE
> -
> Stack "MyTestStack" has a field, which is assigned stack "MyBehaviorStack" as 
> its behavior property.
> 
> Stack "MyBehaviorStack" is a separate stack file.
> 
> 
> POSSIBLE SOLUTIONS
> --
> Options for correct behavior esolution when "MyTestStack" is loaded include:
> 
> 
> a) Open "MyBehaviorStack" first.
>   -
>   In an application this may mean introducing one more stack, which
>   we could call "MyBootStack", which first opens "MyBehaviorStack"
>   and then opens "MyTestStack".
> 
> 
> b) Load "MyBehaviorStack" into memory without opening it.
>   --
>   This can be done by accessing a property of "MyBehaviorStack",
>   such as the stack's name.  This still requires "MyBootStack"
>   to make sure that "MyBehaviorStack" is in memory before
>   "MyTestStack" is opened, but has the minor convenience of
>   not being visible to the user and triggers no opening messages.
> 
> 
> c) Include "MyBehaviorStack" in the stackFiles prop of "MyTestStack".
>   -
>   Any stack files specified in the stackFiles property of a stack
>   are loaded into memory at the same time the stack containing that
>   list is loaded.  In terms of boot sequence it's functionally
>   similar to having those separate stack files as substacks, but
>   with the advantage of keeping them separate.
> 
> 
> a) and b) conform to Guideline #2 above in an obvious way, explicitly putting 
> "MyBehaviorStack" into memory before "MyTestStack" will be opened to need it.
> 
> c) works because stack files listed in the stackFiles property are all loaded 
> with the stack listing them, before behavior resolution takes place.
> 
> 
> This seems harder than it is in part because you're super smart and are just 
> thinking too hard. :)
> 
> Relax.  Put script-only stuff out of your mind, and just think about the load 
> order.
> 
> Behaviors are among the most powerful things ever introduced in the xTalk 
> family of languages.  I waited literally 20 years for them, since Allegiant 
> first accepted my proposal for parentScripts but then went belly-up before 
> they could implement it.  Well worth even that wait: they greatly simplify so 
> many aspects of building complex systems, and 

Re: Script Only Stack Architecture

[Kay C Lan]

On Fri, Apr 1, 2016 at 9:43 AM, Richard Gaskin
 wrote:
>
> That's precisely why I advocate maintaining the Dictionary as an essential
> reference (as in "essence"); it should be easy to link to relevant tutorials
> and guides for more complete discussion when desired.
>
Could you give me an example of a Dictionary entry that has a link to
a Guide or Tutorial? I did a quick look for the obvious; database,
datagrid, behaviour. At this stage I'm not sure there is a Dictionary
Tag for Guides and Tutorials. Would they just be included in the
Reference Tag or as a basic html link to Tutorials?

Whilst I agree with you in principle, and that is certainly the
destination we need to be headed, at this point in time I've got to
agree with Matt. I think there are plenty of nuggets out there that
the community could put into the Dictionary. When the load gets to
large to carry (or the guides and tutorials have been created along
with a way to link to them) then some sifting can happen.

___
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: Script Only Stack Architecture

[Richard Gaskin]

James Hale wrote:
> I fail to see the inclusion of examples of the syntax to a dictionary
> entry as bloat.

Excellent.  That makes it unanimous, as I've not seen anyone else here 
argue against having syntax examples in the Dictionary either.


In fact, I can't think of any Dictionary entry that doesn't have at 
least one, and many have several.



> I may be one of only a few but I find many of the dictionary entries
> opaque to say the least.

Aye, there's the rub: examples are good, excellent examples are great.


> Ali's example of how one would employ a script only stack as a
> behavior is a case in point. It immediately makes employing this
> method accessible and understandable.

As we've seen throughout this thread, there are many ways to solve 
problems, and some will resonate well with some readers and other forms 
with other readers.


For example, the form Ali offered is useful for the unusual demands of 
the IDE but isn't commonly used elsewhere.  It reads nicely, but it's 
not nearly as lean as no code at all.


As noted very early on in this thread, there are reasons why it's 
sometimes necessary to write extra scripts that assign behaviors to 
objects at runtime.  But the beauty of a property setting is that you 
set it once in the IDE and never have to touch it again.


Writing a script to do that for you isn't the hardest thing in the 
world, but if you have a hundreds objects it can get tedious to type. 
And with the IDE tools in most cases you don't need to be scripting that 
at all.


Its good choice where it's used in the IDE, but the IDE has unusual 
requirements.


For example, the revMenubar stack creates all of its objects and sets 
all of their properties on the fly in script.  Useful for the very 
specific reasons they did it, but most of us just use the GUI tools and 
enjoy not having to define every visual element in long code blocks like 
C coders are accustomed to.  Indeed, having an integrated GUI is often a 
big part of why we choose xTalks.


All that said, it never hurts to have another syntax example.  Feel free 
to add it - these guidelines can help you get started:

https://livecode.com/putting-the-you-in-documentation/

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Richard Gaskin]

Matt Maier wrote:


You keep citing the theoretically limitless number of contingencies
that, if addressed, could bloat the dictionary beyond readability.
There's a simple solution to that problem: don't go looking for
theoretical problems.

Instead, just correct, massage, or add to the dictionary entry when
someone has a problem relevant to that entry.


I like "just".  It makes everything sound so easy, which I suppose it is 
when it's about things for other people to do.


I'm a volunteer, like most here.  In addition to helping others learn 
LiveCode I also have other obligations.


So while I might enjoy writing the documentation enhancements proposed 
here, as a practical matter I must admit my limitations and continue to 
encourage others here to write whatever they feel is important to include.


As I've noted here before, this blog post offers some helpful guidance 
for community members to get started contributing to the documentation 
to make it more of they want:





That's a big part of helping people learn on their own. Putting the
information they need right where they need it, rather than putting it
somewhere and challenging them to go find it.


Please.  No one is attempting to make things unnecessarily difficult to 
find.


I agree that it's important to put information *right where they need 
it*.  That implies the information have a discernible taxonomy.


I see no harm, and indeed much value, in having different kinds of 
documentation for different purposes.


In this thread there are maybe half a dozen language tokens at play. 
The central issue doesn't appear to be specific to any one of them, but 
deals more with the relationships between them.


Given this, a single Dictionary entry seems a challenging place for such 
a discussion; replicating the discussion in all relevant entries more so.


A tutorial seems a better fit.  So I wrote one.  And given more time 
later on I'll work with the team to integrate it into the docs.  But at 
least at the moment the OP has what he was looking for, and along the 
way Bill and I planned a lunch. :)


For the long term, I see the biggest opportunity in maintaining the 
different types of documentation we have, but making them more modular 
and interlinked.  So rather than replicate a tutorial within each 
related token entry, the entries could just include a link to it.  This 
provides ready access to in-depth discussion for those who want it, 
while leaving the Dictionary content efficiently focused for everyone 
else who may not have the same question.


But that's just my own opinion.

If you feel this is better suited in the Dictionary specifically, let's 
move beyond the theoretical and get down to business:  what is it that 
should be written, and where?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[James Hale]

I fail to see the inclusion of examples of the syntax to a dictionary entry as 
bloat.
I may be one of only a few but I find many of the dictionary entries opaque to 
say the least.
Ali's example of how one would employ a script only stack as a behavior is a 
case in point. It immediately makes employing this method accessible and 
understandable.
It would have also saved a lot of head scratching on the part of the OP as well 
as a lot of divergent discussion, which although helpful in explaining 
behaviors to the uninitiated (thank you Richard), still was,no where near as 
clear as Ali's (corrected) example in answering the original question.

James

___
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: Script Only Stack Architecture

[Matt Maier]

You keep citing the theoretically limitless number of contingencies that,
if addressed, could bloat the dictionary beyond readability. There's a
simple solution to that problem: don't go looking for theoretical problems.

Instead, just correct, massage, or add to the dictionary entry when someone
has a problem relevant to that entry.

I've also maintained gigantic technical references (fighter aircraft
weapons systems, satellite operations, and ground control systems) and we
followed that simple process. The TOs (technical orders) started out with
just the instructions from the factory. Over time they accumulated
corrections, warnings, cautions, and notes in response to actual events.
That way the extra information appeared right where it was needed and
nobody wasted time on any theoretically necessary information.

That's a big part of helping people learn on their own. Putting the
information they need right where they need it, rather than putting it
somewhere and challenging them to go find it.

On Thu, Mar 31, 2016 at 6:43 PM, Richard Gaskin 
wrote:

> Matt Maier wrote:
>
> > I just want to chime in to disagree with the idea that we should leave
> > useful information out of the Dictionary.
>
> When you put it like that it sounds silly indeed.  Fortunately I wasn't
> advocating omitting useful information, just suggesting we may want to
> maintain an awareness for the scope of doc options at our disposal, and be
> mindful about which details go where.
>
> If you were advocating silliness we might put the User Guide, the Lessons,
> and every LiveCode blog into the Dictionary.  But I know you're not.
>
> We want useful information, where it's most useful.
>
>
> > There's no such thing as a document that's too big when we have
> > networks and search.
>
> That's precisely why I advocate maintaining the Dictionary as an essential
> reference (as in "essence"); it should be easy to link to relevant
> tutorials and guides for more complete discussion when desired.
>
>
> > If it takes a while to explain, then it takes a while to explain.
>
> One of the products I work in is a medial reference for pediatric
> emergency specialists.  Much of its info is in the Physician's Desk
> Reference and a large number of current research papers, but what
> distinguishes our product is that it has LESS information than other
> available sources.
>
> "What's that?  Less?"
>
> Yes.  The PDR is too big to read.  Every doctor has it; few open it. And
> the wealth of information at PubMed is too vast to sift through when you
> have an ER case load stacked up.
>
> So our team is comprised of ER specialists from around the world who
> gather the best information on modern practice available, and work
> diligently to distill it to its most valuable essence useful in a clinical
> setting.
>
> The LiveCode Dictionary need not be quite as sparse; no one's dying on an
> ER table waiting for us to find the parameters to "import snapshot" (and
> God help them if they were ).
>
> But there are different forms of docs because each serves a different
> purpose.
>
>
> > If there are a lot of caveats, then there are a lot of caveats.
> > That sounds like a good reason to simplify the application, not
> > a good reason to keep secrets.
>
> Simplifying the app is indeed the first goal.  Mark Waddingham has already
> slated behavior resolution for cleanup, so it will become simpler at some
> point in the future.
>
> But in the here and now, rest assured there's no conspiracy to keep
> anything secret.
>
> The question on the table is: what is most appropriate in the Dictionary,
> and what is most appropriate for another resource?
>
> The Dictionary is not a User Guide, nor a tutorial.  It's a reference for
> understanding what an API token expects, and what will be returned.
>
> There are many caveats throughout the Dictionary, and arguably there
> should be more.
>
> But I would caution against turning it into the most comprehensive
> collection of all possible things one might mistakenly do and how to avoid
> them.  Each page could be 1MB or more with just mistakes I've made alone. :)
>
> In this specific case, a key part of the original confusion resulted not
> from something missing from the "behavior" entry, but by not consulting the
> "start using" entry.  I've been teaching xTalks for decades, and that's one
> mismatch I'd not previously encountered.  In retrospect it's
> understandable, and I won't completely rule out the possibility that a note
> about "start using" not being relevant to "behavior" may be worth putting
> in.
>
> But so many things aren't relevant to so many others, it seems more
> helpful to guide the user to the things that are.  Rather than talk their
> ear off with entries longer than my posts here about all the possible ways
> things might go wrong, it seems simpler and more respectful of their time
> to just show them the way to do things right and let them enjoy success and
> move on.

Re: Script Only Stack Architecture

[Richard Gaskin]

Matt Maier wrote:

> I just want to chime in to disagree with the idea that we should leave
> useful information out of the Dictionary.

When you put it like that it sounds silly indeed.  Fortunately I wasn't 
advocating omitting useful information, just suggesting we may want to 
maintain an awareness for the scope of doc options at our disposal, and 
be mindful about which details go where.


If you were advocating silliness we might put the User Guide, the 
Lessons, and every LiveCode blog into the Dictionary.  But I know you're 
not.


We want useful information, where it's most useful.


> There's no such thing as a document that's too big when we have
> networks and search.

That's precisely why I advocate maintaining the Dictionary as an 
essential reference (as in "essence"); it should be easy to link to 
relevant tutorials and guides for more complete discussion when desired.



> If it takes a while to explain, then it takes a while to explain.

One of the products I work in is a medial reference for pediatric 
emergency specialists.  Much of its info is in the Physician's Desk 
Reference and a large number of current research papers, but what 
distinguishes our product is that it has LESS information than other 
available sources.


"What's that?  Less?"

Yes.  The PDR is too big to read.  Every doctor has it; few open it. 
And the wealth of information at PubMed is too vast to sift through when 
you have an ER case load stacked up.


So our team is comprised of ER specialists from around the world who 
gather the best information on modern practice available, and work 
diligently to distill it to its most valuable essence useful in a 
clinical setting.


The LiveCode Dictionary need not be quite as sparse; no one's dying on 
an ER table waiting for us to find the parameters to "import snapshot" 
(and God help them if they were ).


But there are different forms of docs because each serves a different 
purpose.



> If there are a lot of caveats, then there are a lot of caveats.
> That sounds like a good reason to simplify the application, not
> a good reason to keep secrets.

Simplifying the app is indeed the first goal.  Mark Waddingham has 
already slated behavior resolution for cleanup, so it will become 
simpler at some point in the future.


But in the here and now, rest assured there's no conspiracy to keep 
anything secret.


The question on the table is: what is most appropriate in the 
Dictionary, and what is most appropriate for another resource?


The Dictionary is not a User Guide, nor a tutorial.  It's a reference 
for understanding what an API token expects, and what will be returned.


There are many caveats throughout the Dictionary, and arguably there 
should be more.


But I would caution against turning it into the most comprehensive 
collection of all possible things one might mistakenly do and how to 
avoid them.  Each page could be 1MB or more with just mistakes I've made 
alone. :)


In this specific case, a key part of the original confusion resulted not 
from something missing from the "behavior" entry, but by not consulting 
the "start using" entry.  I've been teaching xTalks for decades, and 
that's one mismatch I'd not previously encountered.  In retrospect it's 
understandable, and I won't completely rule out the possibility that a 
note about "start using" not being relevant to "behavior" may be worth 
putting in.


But so many things aren't relevant to so many others, it seems more 
helpful to guide the user to the things that are.  Rather than talk 
their ear off with entries longer than my posts here about all the 
possible ways things might go wrong, it seems simpler and more 
respectful of their time to just show them the way to do things right 
and let them enjoy success and move on.



> What feels like a "hefty tome" to someone with decades of experience
> feels like a "gold mine" to someone with no experience. A lot of gold
> is heavy; that's just how it works.

Agreed.  Some of the best reading I've had is with technical specs.

I believe in-depth discussion of collections of related concepts are 
best handled in User Guides.


The Dictionary serves a more specialized role.

Tutorials serve yet another role.

All are important.  And each distinct.

And we have to face an important consideration with all learning 
materials in all fields of human endeavor:  no matter how complete, no 
matter how well written, only part of it will be read, and mistakes will 
be made.


Learning happens only in a small way from reading.  The greatest depth 
and retention occurs through hands-on practice.  And the nature of 
practice means making mistakes, understanding the nature of the specific 
mistake made, and correcting it.  You can read about a piano all day 
long, and never understand as much about it as an hour at the keyboard. 
 Similarly, I believe interactive media is best learned through 
interaction.


Not that we shouldn't aim high with the docs.  But it's 

Re: Script Only Stack Architecture

[Matt Maier]

I just want to chime in to disagree with the idea that we should leave
useful information out of the Dictionary.

There's no such thing as a document that's too big when we have networks
and search. Even if we're forced to browse and read we can just put the
information in order of importance so that the more trivial stuff is at the
end.

If it takes a while to explain, then it takes a while to explain. If there
are a lot of caveats, then there are a lot of caveats. That sounds like a
good reason to simplify the application, not a good reason to keep secrets.
What feels like a "hefty tome" to someone with decades of experience feels
like a "gold mine" to someone with no experience. A lot of gold is heavy;
that's just how it works.

On Thu, Mar 31, 2016 at 1:41 PM, Richard Gaskin 
wrote:

> Sannyasin Brahmanathaswami wrote:
>
> > I think the idea that you have to open an external behavior stack
> > *before* you open the main stack that has controls which point to
> > it as their parent, is totally unintuitive and when a newbie reads
> > "load, open, put into memory" etc... he/she will always assume this
> > can happen in the preopenstack handler.
>
> Perhaps.  Ideally we'd need to user-test that to affirm the assumption. It
> wouldn't have occurred to me, but I've spent too long using xTalks to be a
> reliable gauge of what it takes to learn them (which is why the older I get
> the more ardent I've become about listening carefully to people who know
> nothing about the software; that precious naivety leaves so quickly, and is
> invaluable during that brief moment it still exists).
>
> The one thing everyone agrees on is that the current need to be so aware
> of load order for behavior resolution is undesirable and needs to be
> changed at first opportunity.  Mark Waddingham doesn't much care for it any
> more than you or I do.  I'd be surprised if it isn't resolved (all puns
> intended) by 8.2 if not sooner.
>
> Fortunately we have the convenient stackFiles property to make this a bit
> simpler in the meantime.
>
>
> > "Load "MyBehaviorStack" into memory without opening it. "
> >
> > It is or is not open after you query the property? do you really mean:
> >
> > "You can query a property to open the stack in the background and put
> > its stack script into memory."
>
> Whether a stack is "open" if loaded into memory without using an "open" or
> "go" command is perhaps a philosophical question.
>
> Personally I try to use "open" to describe a stack's runtime state only in
> cases where I brought it into RAM with "open" or "go", and the rare case of
> anything else as simply "in memory".
>
>
> > a) b) (with explanation above)  c) below + Jacque's explanation could
> > go in the dictionary... I don't think that's over loading it. had
> > that been what I read at Git Hub, we could have avoided several days
> > for lost time.
>
> Go for it, but please be brief in Dictionary entries.   This thread is as
> long as it is in part because of a misunderstanding of what "start using"
> does, which may merit mention there but on the other hand if we included
> caveats in every Dictionary entry to cover mistakes I've made trying to
> misapply commands it would be a tome too hefty to read. :)
>
> Rather than enumerate all possible ways do not do something, just focus on
> what you want them to do.
>
>
> > OTOH, we did get the gold out of it:  your nested behaviors/as-
> >classes tutorial...
> >
> > So it was all worth it!
>
> Glad that was helpful.   Nested behaviors are da bombdiggety!
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> 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: Script Only Stack Architecture

[William Prothero]

Thanks for the comments. Very interesting. And I guess the big advantage of 
behaviors over a library is the scope issue.

I’ll put this info into my toolchest.
Best,
Bill

> On Mar 31, 2016, at 3:33 PM, Ali Lloyd  wrote:
> 
> Or more accurately
> on preOpenStack
>  local tBehaviorLongID
>  put the long id of stack "" into tBehaviorLongID
>  set the behavior of field "FieldWithBehavior" of me to tBehaviorLongID
> end preOpenStack
> 
> On Thu, Mar 31, 2016 at 11:31 PM Ali Lloyd  wrote:
> 
>> My solution to this:
>> 
>> Stack "MyTestStack" has a field, which is assigned stack
>> "MyBehaviorStack" as its behavior property.
>> 
>> Stack "MyBehaviorStack" is a separate stack file.
>> 
>> would be to also include the behavior *setting* in the preOpenStack
>> handler of "MyTestStack".
>> 
>> on preOpenStack
>>  set the behavior of field "FieldWithBehavior" of me to > MyBehaviorStack>
>> end preOpenStack
>> 
>> This is the model used repeatedly for such things in the IDE.
>> 
>> On Thu, Mar 31, 2016 at 10:10 PM William Prothero 
>> wrote:
>> 
>>> Richard:
>>> Ok, for the sake of argument (and my learning), compare that to:
>>> 
>>> 1. Make  new stack and call it “Alt Behavior Playground”
>>> 
>>> 2. Make a new button and enter the script:
>>> on mouseDown
>>> 
>>>   put the long ID of the target into theTarg
>>> 
>>>   doABehavior theTarg
>>> 
>>> end mouseDown
>>> 
>>> 3. Make a substack and call it “myBehaviorLib”  —just for the heck of it.
>>> Put the following script in it:
>>> 
>>> on doABehavior tCtl
>>> 
>>>doTheGrab tCtl
>>> 
>>> end doABehavior
>>> 
>>> 
>>> on doTheGrab tCtl
>>> 
>>>   grab tCtl
>>> 
>>> end doTheGrab
>>> 
>>> 4. Better do: start using stack “myBehaviorLib”
>>> 
>>> Run it and drag the button you made. This will work in all stacks with
>>> the on mouseDown script in it.
>>> 
>>> So, the “myBehaviorLib” substack could be simply a script only stack that
>>> contains some reasonable number of separate behavior type scripts, and once
>>> the “start using” is invoked, say on a preopenStack script, all common code
>>> for button behaviors becomes a single code element. Inheritance, like
>>> adding new behavior is just adding another script to the “on doABehavior”
>>> handler in the “myBehaviorLib” stack. What you don’t get is the ability to
>>> have the same name for a bunch of different behaviors, but …… perhaps it’s
>>> easier to keep track of handler names that are different anyway.
>>> 
>>> Somehow, this seems more direct to me. It also avoids the need for a
>>> preloader stack the opens a bunch of small files that are behaviors.
>>> 
>>> What do you think?
>>> Bill
>>> 
>>> 
>>> 
 On Mar 31, 2016, at 9:52 AM, Richard Gaskin 
>>> wrote:
 
 William Prothero wrote:
 
> Reading this kinda makes my head spin. Now I’m thinking it is going
> to be a heck of a lot more robust for my situation, as a single
> developer, to not use behaviors at all, but to have a single
> (possibly script only) substack that holds all of the handlers that I
> would normally use as behaviors, and just put a call to that handler
> in each button. I can use “the target”  or “me” as a passed variable
> to make the action specific to a particular control.
> 
> This approach seems a lot less prone to idiosyncrasies and more
> easily transportable to other apps, to me. It also means that all of
> my “behavior type scripts” would sit in a single script-only stack,
> which would make it a lot more convenient to access and edit than a
> bunch of small script only stacks sitting in my project browser.
> 
> Am I wrong. misguided, foolish, or brilliant?
 
 Behaviors are very powerful for all sorts of things, whether you work
>>> alone or in a team of twenty.
 
 The biggest benefit for teamwork comes from the very separate question
>>> of whether to use script-only stacks to define behaviors.  Script-only
>>> stacks are an ideal solution for Github-based workflows, but have minimal
>>> value (some, but not as much) for anyone not dependent on a version control
>>> system designed for other languages.
 
 Ditch script-only stacks for now and continue to explore behaviors.
>>> You'll thank me.  You'll want to buy me lunch next time I'm in Santa
>>> Barbara.  I'll accept.  Behaviors will change everything, very powerfully,
>>> the more you explore and use them.
 
 Once we step away from the very separate issue of script-only stacks,
>>> we have really only two guidelines for using behaviors effectively:
 
 - A behavior definition can be any button or stack.
 
 - When using behaviors, the object containing the behavior script
 must be in memory when anything relying on it is brought into
 memory.
 
 That's it.
 
 When exploring a new feature I like to make a simple stack I can use as

Re: Script Only Stack Architecture

[Ali Lloyd]

Or more accurately
on preOpenStack
  local tBehaviorLongID
  put the long id of stack "" into tBehaviorLongID
  set the behavior of field "FieldWithBehavior" of me to tBehaviorLongID
end preOpenStack

On Thu, Mar 31, 2016 at 11:31 PM Ali Lloyd  wrote:

> My solution to this:
>
> Stack "MyTestStack" has a field, which is assigned stack
> "MyBehaviorStack" as its behavior property.
>
> Stack "MyBehaviorStack" is a separate stack file.
>
> would be to also include the behavior *setting* in the preOpenStack
> handler of "MyTestStack".
>
> on preOpenStack
>   set the behavior of field "FieldWithBehavior" of me to  MyBehaviorStack>
> end preOpenStack
>
> This is the model used repeatedly for such things in the IDE.
>
> On Thu, Mar 31, 2016 at 10:10 PM William Prothero 
> wrote:
>
>> Richard:
>> Ok, for the sake of argument (and my learning), compare that to:
>>
>> 1. Make  new stack and call it “Alt Behavior Playground”
>>
>> 2. Make a new button and enter the script:
>> on mouseDown
>>
>>put the long ID of the target into theTarg
>>
>>doABehavior theTarg
>>
>> end mouseDown
>>
>> 3. Make a substack and call it “myBehaviorLib”  —just for the heck of it.
>> Put the following script in it:
>>
>> on doABehavior tCtl
>>
>> doTheGrab tCtl
>>
>> end doABehavior
>>
>>
>> on doTheGrab tCtl
>>
>>grab tCtl
>>
>> end doTheGrab
>>
>> 4. Better do: start using stack “myBehaviorLib”
>>
>> Run it and drag the button you made. This will work in all stacks with
>> the on mouseDown script in it.
>>
>> So, the “myBehaviorLib” substack could be simply a script only stack that
>> contains some reasonable number of separate behavior type scripts, and once
>> the “start using” is invoked, say on a preopenStack script, all common code
>> for button behaviors becomes a single code element. Inheritance, like
>> adding new behavior is just adding another script to the “on doABehavior”
>> handler in the “myBehaviorLib” stack. What you don’t get is the ability to
>> have the same name for a bunch of different behaviors, but …… perhaps it’s
>> easier to keep track of handler names that are different anyway.
>>
>> Somehow, this seems more direct to me. It also avoids the need for a
>> preloader stack the opens a bunch of small files that are behaviors.
>>
>> What do you think?
>> Bill
>>
>>
>>
>> > On Mar 31, 2016, at 9:52 AM, Richard Gaskin 
>> wrote:
>> >
>> > William Prothero wrote:
>> >
>> > > Reading this kinda makes my head spin. Now I’m thinking it is going
>> > > to be a heck of a lot more robust for my situation, as a single
>> > > developer, to not use behaviors at all, but to have a single
>> > > (possibly script only) substack that holds all of the handlers that I
>> > > would normally use as behaviors, and just put a call to that handler
>> > > in each button. I can use “the target”  or “me” as a passed variable
>> > > to make the action specific to a particular control.
>> > >
>> > > This approach seems a lot less prone to idiosyncrasies and more
>> > > easily transportable to other apps, to me. It also means that all of
>> > > my “behavior type scripts” would sit in a single script-only stack,
>> > > which would make it a lot more convenient to access and edit than a
>> > > bunch of small script only stacks sitting in my project browser.
>> > >
>> > > Am I wrong. misguided, foolish, or brilliant?
>> >
>> > Behaviors are very powerful for all sorts of things, whether you work
>> alone or in a team of twenty.
>> >
>> > The biggest benefit for teamwork comes from the very separate question
>> of whether to use script-only stacks to define behaviors.  Script-only
>> stacks are an ideal solution for Github-based workflows, but have minimal
>> value (some, but not as much) for anyone not dependent on a version control
>> system designed for other languages.
>> >
>> > Ditch script-only stacks for now and continue to explore behaviors.
>> You'll thank me.  You'll want to buy me lunch next time I'm in Santa
>> Barbara.  I'll accept.  Behaviors will change everything, very powerfully,
>> the more you explore and use them.
>> >
>> > Once we step away from the very separate issue of script-only stacks,
>> we have really only two guidelines for using behaviors effectively:
>> >
>> > - A behavior definition can be any button or stack.
>> >
>> > - When using behaviors, the object containing the behavior script
>> >  must be in memory when anything relying on it is brought into
>> >  memory.
>> >
>> > That's it.
>> >
>> > When exploring a new feature I like to make a simple stack I can use as
>> a playground to poke around and experiment without mucking up anything
>> important I'm working on.
>> >
>> > Here's a quick tutorial that may get you hooked on the power of
>> behaviors:
>> >
>> > 1. Make a new stack titled "Behavior Playground"
>> >
>> > 2. Add a button named "MyClass"
>> >
>> > 3. Set the script of that button to:
>> >
>> >on mouseUp
>> 

Re: Script Only Stack Architecture

[Ali Lloyd]

My solution to this:

Stack "MyTestStack" has a field, which is assigned stack
"MyBehaviorStack" as its behavior property.

Stack "MyBehaviorStack" is a separate stack file.

would be to also include the behavior *setting* in the preOpenStack handler
of "MyTestStack".

on preOpenStack
  set the behavior of field "FieldWithBehavior" of me to 
end preOpenStack

This is the model used repeatedly for such things in the IDE.

On Thu, Mar 31, 2016 at 10:10 PM William Prothero 
wrote:

> Richard:
> Ok, for the sake of argument (and my learning), compare that to:
>
> 1. Make  new stack and call it “Alt Behavior Playground”
>
> 2. Make a new button and enter the script:
> on mouseDown
>
>put the long ID of the target into theTarg
>
>doABehavior theTarg
>
> end mouseDown
>
> 3. Make a substack and call it “myBehaviorLib”  —just for the heck of it.
> Put the following script in it:
>
> on doABehavior tCtl
>
> doTheGrab tCtl
>
> end doABehavior
>
>
> on doTheGrab tCtl
>
>grab tCtl
>
> end doTheGrab
>
> 4. Better do: start using stack “myBehaviorLib”
>
> Run it and drag the button you made. This will work in all stacks with the
> on mouseDown script in it.
>
> So, the “myBehaviorLib” substack could be simply a script only stack that
> contains some reasonable number of separate behavior type scripts, and once
> the “start using” is invoked, say on a preopenStack script, all common code
> for button behaviors becomes a single code element. Inheritance, like
> adding new behavior is just adding another script to the “on doABehavior”
> handler in the “myBehaviorLib” stack. What you don’t get is the ability to
> have the same name for a bunch of different behaviors, but …… perhaps it’s
> easier to keep track of handler names that are different anyway.
>
> Somehow, this seems more direct to me. It also avoids the need for a
> preloader stack the opens a bunch of small files that are behaviors.
>
> What do you think?
> Bill
>
>
>
> > On Mar 31, 2016, at 9:52 AM, Richard Gaskin 
> wrote:
> >
> > William Prothero wrote:
> >
> > > Reading this kinda makes my head spin. Now I’m thinking it is going
> > > to be a heck of a lot more robust for my situation, as a single
> > > developer, to not use behaviors at all, but to have a single
> > > (possibly script only) substack that holds all of the handlers that I
> > > would normally use as behaviors, and just put a call to that handler
> > > in each button. I can use “the target”  or “me” as a passed variable
> > > to make the action specific to a particular control.
> > >
> > > This approach seems a lot less prone to idiosyncrasies and more
> > > easily transportable to other apps, to me. It also means that all of
> > > my “behavior type scripts” would sit in a single script-only stack,
> > > which would make it a lot more convenient to access and edit than a
> > > bunch of small script only stacks sitting in my project browser.
> > >
> > > Am I wrong. misguided, foolish, or brilliant?
> >
> > Behaviors are very powerful for all sorts of things, whether you work
> alone or in a team of twenty.
> >
> > The biggest benefit for teamwork comes from the very separate question
> of whether to use script-only stacks to define behaviors.  Script-only
> stacks are an ideal solution for Github-based workflows, but have minimal
> value (some, but not as much) for anyone not dependent on a version control
> system designed for other languages.
> >
> > Ditch script-only stacks for now and continue to explore behaviors.
> You'll thank me.  You'll want to buy me lunch next time I'm in Santa
> Barbara.  I'll accept.  Behaviors will change everything, very powerfully,
> the more you explore and use them.
> >
> > Once we step away from the very separate issue of script-only stacks, we
> have really only two guidelines for using behaviors effectively:
> >
> > - A behavior definition can be any button or stack.
> >
> > - When using behaviors, the object containing the behavior script
> >  must be in memory when anything relying on it is brought into
> >  memory.
> >
> > That's it.
> >
> > When exploring a new feature I like to make a simple stack I can use as
> a playground to poke around and experiment without mucking up anything
> important I'm working on.
> >
> > Here's a quick tutorial that may get you hooked on the power of
> behaviors:
> >
> > 1. Make a new stack titled "Behavior Playground"
> >
> > 2. Add a button named "MyClass"
> >
> > 3. Set the script of that button to:
> >
> >on mouseUp
> >   answer the name of me
> >end mouseUp
> >
> > There - you've just created a behavior, defining an action for what will
> be an entire class of custom button objects:
> >
> > 4. Make a new button named "A"
> >
> > 5. In the Message Box run:
> >
> >   set the behavior of btn "A" to the long id of btn "MyClass"
> >
> > 6. Make two copies of btn "A", naming them "B" and "C" respectively.
> >
> > 7. Click any of them.
> >
> > 

Re: Script Only Stack Architecture

[Mark Wieder]

Bill-


So, the “myBehaviorLib” substack could be simply a script only stack that 
contains some reasonable number of separate behavior type scripts, and once the 
“start using” is invoked, say on a preopenStack script, all common code for 
button behaviors becomes a single code element. Inheritance, like adding new 
behavior is just adding another script to the “on doABehavior” handler in the 
“myBehaviorLib” stack.


There's nothing wrong with what you're suggesting there.
But it's a different use case from behaviors.

Let's say you have a stack with 100 buttons on it.
You want four of those buttons to have common handlers, but not the 
other 96 buttons.


You could write the handlers for one button and copypasta them into the 
other three similar buttons.


Or... you could throw the common handlers into a behavior script and 
link all four buttons to that object, no matter whether it's a button or 
a script-only stack.


The idea is that you have the common handlers in one place for easy 
maintenance and limited inheritance instead of global handlers. There's 
a need for both, but they're different.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
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: Script Only Stack Architecture

[Richard Gaskin]

The difference between a library and a behavior is scope:  the library 
is global, while the behavior only affects the objects to which it's 
assigned.


The preloading thang with behaviors is somewhat specific, only coming 
into play when all three of the following are true:


- The behavior script must be outside of the stack file containing
  objects that depend on it;

- The objects that depend on it happen to be in a stack file loaded
  into memory before the external behavior stack is loaded;

- For some reason just setting the stackfiles property to include
  the external stack is prohibitive.

Most of my apps have a substack named "RSRC" where I keep 
images and such, and my behavior scripts are buttons there. I never 
think about behavior load order at all.



As for scope:

Your library option is a workable solution.  Indeed that's the only way 
we did things for many years.  And where it's a good fit we still do.


But what if you want to change the script so that rather than respond on 
mouseUp you want to respond to mouseDown?  Or add a handler for new 
mouse message?


With a library you'd either have to change the scripts of every object 
you want updated, or you could use the message name directly in the 
library with a condition in the library, e.g.:


   if the uClassName of the target is "MyClass" then...

But with a behavior you just edit one script.  Ever. For any change to 
all child objects it governs.


And being limited in scope to child objects assigned to it, a behavior 
is slightly more efficient than a library, since it's not in the message 
path for all of the objects it's unrelated to.


But that performance difference is tiny (very, almost immeasurable).

The biggest benefit is keeping all code in one place.  With a behavior 
you know that if any subscribed child has code in it, it's an exception 
and the code is there for a very distinct reason (overloading or 
overriding the behavior).


For all other objects of a class, chances are they'll have no code at 
all.  The only code they'll have is code that makes them unique; common 
code is stored in one common place.


A small stylistic benefit is not needing to keep track of the target, 
which may sometimes change during a multi-call sequence.


With behaviors, "me" refers to the child object subscribing to the 
behavior. So if you have complex routines that use "send" or "click at" 
or other things that can change the target, you still always know the 
child object using the behavior, "me".


In all respects the code acts as though it's attached to that child - it 
even maintains its own distinct set of local and script-local variables 
for each child.


This latter feature is very handy.  You could conceivably use custom 
properties similarly to keep info bound to the object, but unless you 
need that info to be persistent you'll want to clear it or reset it at 
some point.   But with variables within a behavior script being unique 
to each child using it, you never need to think about it - you just code 
as if you were coding on the object's own script.


For more sophisticated systems the ability to subclass can be very 
useful.  If you had a globally-available library that filters out class 
members with a condition, using subclasses or superclasses means adding 
more conditions.  But with behaviors it's just a single property setting 
on the affected behavior to chain another to it.


--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web

ambassa...@fourthworld.com http://www.FourthWorld.com


William Prothero wrote:

> Ok, for the sake of argument (and my learning), compare that to:
>
> 1. Make  new stack and call it “Alt Behavior Playground”
>
> 2. Make a new button and enter the script:
> on mouseDown
>put the long ID of the target into theTarg
>doABehavior theTarg
> end mouseDown
>
> 3. Make a substack and call it “myBehaviorLib”  —just for the heck of
> it.
> Put the following script in it:
>
> on doABehavior tCtl
> doTheGrab tCtl
> end doABehavior
>
>
> on doTheGrab tCtl
>grab tCtl
> end doTheGrab
>
> 4. Better do: start using stack “myBehaviorLib”
>
> Run it and drag the button you made. This will work in all stacks
> with the on mouseDown script in it.
>
> So, the “myBehaviorLib” substack could be simply a script only stack
> that contains some reasonable number of separate behavior type
> scripts, and once the “start using” is invoked, say on a preopenStack
> script, all common code for button behaviors becomes a single code
> element. Inheritance, like adding new behavior is just adding another
> script to the “on doABehavior” handler in the “myBehaviorLib” stack.
> What you don’t get is the ability to have the same name for a bunch
> of different behaviors, but …… perhaps it’s easier to keep track of
> handler names that are different anyway.
>
> Somehow, this seems more 

Re: Script Only Stack Architecture

[William Prothero]

Richard:
Ok, for the sake of argument (and my learning), compare that to:

1. Make  new stack and call it “Alt Behavior Playground”

2. Make a new button and enter the script:
on mouseDown

   put the long ID of the target into theTarg

   doABehavior theTarg

end mouseDown

3. Make a substack and call it “myBehaviorLib”  —just for the heck of it.
Put the following script in it:

on doABehavior tCtl

doTheGrab tCtl

end doABehavior


on doTheGrab tCtl

   grab tCtl

end doTheGrab

4. Better do: start using stack “myBehaviorLib”

Run it and drag the button you made. This will work in all stacks with the on 
mouseDown script in it.

So, the “myBehaviorLib” substack could be simply a script only stack that 
contains some reasonable number of separate behavior type scripts, and once the 
“start using” is invoked, say on a preopenStack script, all common code for 
button behaviors becomes a single code element. Inheritance, like adding new 
behavior is just adding another script to the “on doABehavior” handler in the 
“myBehaviorLib” stack. What you don’t get is the ability to have the same name 
for a bunch of different behaviors, but …… perhaps it’s easier to keep track of 
handler names that are different anyway.

Somehow, this seems more direct to me. It also avoids the need for a preloader 
stack the opens a bunch of small files that are behaviors.

What do you think?
Bill



> On Mar 31, 2016, at 9:52 AM, Richard Gaskin  
> wrote:
> 
> William Prothero wrote:
> 
> > Reading this kinda makes my head spin. Now I’m thinking it is going
> > to be a heck of a lot more robust for my situation, as a single
> > developer, to not use behaviors at all, but to have a single
> > (possibly script only) substack that holds all of the handlers that I
> > would normally use as behaviors, and just put a call to that handler
> > in each button. I can use “the target”  or “me” as a passed variable
> > to make the action specific to a particular control.
> >
> > This approach seems a lot less prone to idiosyncrasies and more
> > easily transportable to other apps, to me. It also means that all of
> > my “behavior type scripts” would sit in a single script-only stack,
> > which would make it a lot more convenient to access and edit than a
> > bunch of small script only stacks sitting in my project browser.
> >
> > Am I wrong. misguided, foolish, or brilliant?
> 
> Behaviors are very powerful for all sorts of things, whether you work alone 
> or in a team of twenty.
> 
> The biggest benefit for teamwork comes from the very separate question of 
> whether to use script-only stacks to define behaviors.  Script-only stacks 
> are an ideal solution for Github-based workflows, but have minimal value 
> (some, but not as much) for anyone not dependent on a version control system 
> designed for other languages.
> 
> Ditch script-only stacks for now and continue to explore behaviors. You'll 
> thank me.  You'll want to buy me lunch next time I'm in Santa Barbara.  I'll 
> accept.  Behaviors will change everything, very powerfully, the more you 
> explore and use them.
> 
> Once we step away from the very separate issue of script-only stacks, we have 
> really only two guidelines for using behaviors effectively:
> 
> - A behavior definition can be any button or stack.
> 
> - When using behaviors, the object containing the behavior script
>  must be in memory when anything relying on it is brought into
>  memory.
> 
> That's it.
> 
> When exploring a new feature I like to make a simple stack I can use as a 
> playground to poke around and experiment without mucking up anything 
> important I'm working on.
> 
> Here's a quick tutorial that may get you hooked on the power of behaviors:
> 
> 1. Make a new stack titled "Behavior Playground"
> 
> 2. Add a button named "MyClass"
> 
> 3. Set the script of that button to:
> 
>on mouseUp
>   answer the name of me
>end mouseUp
> 
> There - you've just created a behavior, defining an action for what will be 
> an entire class of custom button objects:
> 
> 4. Make a new button named "A"
> 
> 5. In the Message Box run:
> 
>   set the behavior of btn "A" to the long id of btn "MyClass"
> 
> 6. Make two copies of btn "A", naming them "B" and "C" respectively.
> 
> 7. Click any of them.
> 
> What you'll see is that each of them uses the script of button "MyClass" as 
> if it's their own, bringing up an answer dialog showing the unique name of 
> each.
> 
> At this point your mind is already thinking of a dozen times in recent 
> projects where you have several objects you wanted to work the same without 
> affecting any other scripts.  We could leave it here and you'd be off writing 
> behaviors very productively right now.
> 
> But we're going to take this one step further - we'll create a superclass:
> 
> 8. Make a new button named "MySuperClass"
> 
> 9. Set this script of that button to:
> 
>   on mouseDown
>  grab me
>   end mouseDown
> 
> 10. In 

Re: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> I think the idea that you have to open an external behavior stack
> *before* you open the main stack that has controls which point to
> it as their parent, is totally unintuitive and when a newbie reads
> "load, open, put into memory" etc... he/she will always assume this
> can happen in the preopenstack handler.

Perhaps.  Ideally we'd need to user-test that to affirm the assumption. 
It wouldn't have occurred to me, but I've spent too long using xTalks to 
be a reliable gauge of what it takes to learn them (which is why the 
older I get the more ardent I've become about listening carefully to 
people who know nothing about the software; that precious naivety leaves 
so quickly, and is invaluable during that brief moment it still exists).


The one thing everyone agrees on is that the current need to be so aware 
of load order for behavior resolution is undesirable and needs to be 
changed at first opportunity.  Mark Waddingham doesn't much care for it 
any more than you or I do.  I'd be surprised if it isn't resolved (all 
puns intended) by 8.2 if not sooner.


Fortunately we have the convenient stackFiles property to make this a 
bit simpler in the meantime.



> "Load "MyBehaviorStack" into memory without opening it. "
>
> It is or is not open after you query the property? do you really mean:
>
> "You can query a property to open the stack in the background and put
> its stack script into memory."

Whether a stack is "open" if loaded into memory without using an "open" 
or "go" command is perhaps a philosophical question.


Personally I try to use "open" to describe a stack's runtime state only 
in cases where I brought it into RAM with "open" or "go", and the rare 
case of anything else as simply "in memory".



> a) b) (with explanation above)  c) below + Jacque's explanation could
> go in the dictionary... I don't think that's over loading it. had
> that been what I read at Git Hub, we could have avoided several days
> for lost time.

Go for it, but please be brief in Dictionary entries.   This thread is 
as long as it is in part because of a misunderstanding of what "start 
using" does, which may merit mention there but on the other hand if we 
included caveats in every Dictionary entry to cover mistakes I've made 
trying to misapply commands it would be a tome too hefty to read. :)


Rather than enumerate all possible ways do not do something, just focus 
on what you want them to do.



> OTOH, we did get the gold out of it:  your nested behaviors/as-
>classes tutorial...
>
> So it was all worth it!

Glad that was helpful.   Nested behaviors are da bombdiggety!

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[J. Landman Gay]

On 3/31/2016 3:09 PM, Sannyasin Brahmanathaswami wrote:

I think the idea that you have to open an external behavior
stack*before*  you open the main stack that has controls which point
to it as their parent, is totally unintuitive and when a newbie reads
"load, open, put into memory" etc... he/she will always assume this
can happen in the preopenstack handler.  even your b) explanation
will  throw a newbie


Yeah, you're right. That's what the bug report is about -- make the 
process automatic and more intuitive. The current loading order worked 
fine when buttons were all we had to work with, but once stacks got 
involved it got real messy.



"Load "MyBehaviorStack" into memory without opening it."

It is or is not open after you query the property?


The engine needs to load it into RAM in order to get the property value. 
After that the stack is in the same state as a closed stack which has 
its deleteStack property set to false. The stack is retained in RAM but 
is not visible and is not in the message path. "There is a stack x" will 
return true, but engine messages won't reach it.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

I don't think I'm super smart... or over thinking it

I think the idea that you have to open an external behavior stack *before* you 
open the main stack that has controls which point to it as their parent, is 
totally unintuitive and when a newbie reads "load, open, put into memory" 
etc... he/she will always assume this can happen in the preopenstack handler.  
even your b) explanation will  throw a newbie

"Load "MyBehaviorStack" into memory without opening it. "

It is or is not open after you query the property? do you really mean:

"You can query a property to open the stack in the background and put its stack 
script into memory."

a) b) (with explanation above)  c) below + Jacque's explanation could go in the 
dictionary... I don't think that's over loading it. had that been what I read 
at Git Hub, we could have avoided several days for lost time.

OTOH, we did get the gold out of it:  your nested behaviors/as-classes 
tutorial...

So it was all worth it!


For my use case, stack files seems the simplest way to go and most rock solid.

On March 31, 2016 at 9:44:06 AM, Richard Gaskin 
(ambassa...@fourthworld.com) wrote:

Sannyasin Brahmanathaswami wrote:

> ergo: merely opening a script-only stack that is applied as a
> behavior to a control (not global in scope) does *not* place
> into the msg path.

Respectfully, your recipe would be easier to follow without the steps
unrelated to the actions we're exploring (making folders and such - the
folder locations are unrelated to the problem).

Remember guideline #2 in my earlier post:

2. When using behaviors, the object containing the behavior script
must be in memory when anything relying on it is brought into
memory.


If I'm following your recipe correctly, the field object that uses the
behavior is in a stack that opens and then loads the stack used to
define the behavior.

This means that at the moment the field object is unpacked for use it
contains a reference to a behavior object not yet in memory.

The engine (in its current form; we can expect this to be improved later
as time permits) will only attempt to resolve a behavior once, when the
object dependent on the behavior is brought into memory.

Even if you later open a stack containing the behavior script, by that
time it's too late. The object depending on it has already been
unpacked, the behavior reference already attempted, and having failed it
will not be retried as other stacks are later opened.

For the moment let's forget that in your case the stack file used as a
behavior object is a script-only stack. The storage format doesn't
affect anything at runtime, and may be distracting here. Let's just
focus on the load order:


SIMPLIFIED RECIPE
-
Stack "MyTestStack" has a field, which is assigned stack
"MyBehaviorStack" as its behavior property.

Stack "MyBehaviorStack" is a separate stack file.


POSSIBLE SOLUTIONS
--
Options for correct behavior esolution when "MyTestStack" is loaded include:


a) Open "MyBehaviorStack" first.
-
In an application this may mean introducing one more stack, which
we could call "MyBootStack", which first opens "MyBehaviorStack"
and then opens "MyTestStack".


b) Load "MyBehaviorStack" into memory without opening it.
--
This can be done by accessing a property of "MyBehaviorStack",
such as the stack's name. This still requires "MyBootStack"
to make sure that "MyBehaviorStack" is in memory before
"MyTestStack" is opened, but has the minor convenience of
not being visible to the user and triggers no opening messages.


c) Include "MyBehaviorStack" in the stackFiles prop of "MyTestStack".
-
Any stack files specified in the stackFiles property of a stack
are loaded into memory at the same time the stack containing that
list is loaded. In terms of boot sequence it's functionally
similar to having those separate stack files as substacks, but
with the advantage of keeping them separate.


a) and b) conform to Guideline #2 above in an obvious way, explicitly
putting "MyBehaviorStack" into memory before "MyTestStack" will be
opened to need it.

c) works because stack files listed in the stackFiles property are all
loaded with the stack listing them, before behavior resolution takes place.


This seems harder than it is in part because you're super smart and are
just thinking too hard. :)

Relax. Put script-only stuff out of your mind, and just think about the
load order.

Behaviors are among the most powerful things ever introduced in the
xTalk family of languages. I waited literally 20 years for them, since
Allegiant first accepted my proposal for parentScripts but then went
belly-up before they could implement it. Well worth even that wait:
they greatly simplify so many aspects of 

Re: Script Only Stack Architecture

[Richard Gaskin]

 J. Landman Gay wrote:

On 3/31/2016 1:42 PM, Sannyasin Brahmanathaswami wrote:

ergo: merely opening a script-only stack that is applied as a
behavior to a control (not global in scope) does*not*  place into the
msg path.


By the time a preOpenStack handler executes, the engine has already
loaded the stack into RAM and set up the behaviors. You need to load the
behaviors before your mainstack even launches. That's why Richard said
it may require a launcher app that opens the behaviors first and then
opens the mainstack.

To avoid that, the only method available would be the stackfiles lists.
The engine apparently checks those first before setting up the behavior
linkages.


As usual, Jacque manages to explain it better if far fewer words. :)

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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: Script Only Stack Architecture

[Richard Gaskin]

William Prothero wrote:

> Thanks, Richard:
> My previous exposure to the behaviors methodology was in Adobe
> Director. A behavior was assigned to a particular control, field,
> button, whatever, and in its script, it defined a set of properties
> that could be set custom for each instantiation. That way, a “set” of
> graphics for a button, for example, could be assembled as part of a
> behavior where the “up”, “down”,”over”, “disabled” etc, states linked
> to a particular graphic. Of course, you don’t have to do that in
> Livecode, but that was the idea.

Similar here, but more message-driven than property-driven.

> Thanks for the prescription. I’ll try it out.

I hope it helps.

> Let me know next time you’re in Santa Barbara. I’ll treat you to
> lunch.

I would enjoy that.  I try to take the train up a couple times a year 
(such a nice train ride and such an awful drive ).  I'll drop you a 
note next time I'm up that way.  Thanks.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> ergo: merely opening a script-only stack that is applied as a
> behavior to a control (not global in scope) does *not* place
> into the msg path.

Respectfully, your recipe would be easier to follow without the steps 
unrelated to the actions we're exploring (making folders and such - the 
folder locations are unrelated to the problem).


Remember guideline #2 in my earlier post:

  2. When using behaviors, the object containing the behavior script
 must be in memory when anything relying on it is brought into
 memory.


If I'm following your recipe correctly, the field object that uses the 
behavior is in a stack that opens and then loads the stack used to 
define the behavior.


This means that at the moment the field object is unpacked for use it 
contains a reference to a behavior object not yet in memory.


The engine (in its current form; we can expect this to be improved later 
as time permits) will only attempt to resolve a behavior once, when the 
object dependent on the behavior is brought into memory.


Even if you later open a stack containing the behavior script, by that 
time it's too late.  The object depending on it has already been 
unpacked, the behavior reference already attempted, and having failed it 
will not be retried as other stacks are later opened.


For the moment let's forget that in your case the stack file used as a 
behavior object is a script-only stack.  The storage format doesn't 
affect anything at runtime, and may be distracting here.  Let's just 
focus on the load order:



SIMPLIFIED RECIPE
-
Stack "MyTestStack" has a field, which is assigned stack 
"MyBehaviorStack" as its behavior property.


Stack "MyBehaviorStack" is a separate stack file.


POSSIBLE SOLUTIONS
--
Options for correct behavior esolution when "MyTestStack" is loaded include:


a) Open "MyBehaviorStack" first.
   -
   In an application this may mean introducing one more stack, which
   we could call "MyBootStack", which first opens "MyBehaviorStack"
   and then opens "MyTestStack".


b) Load "MyBehaviorStack" into memory without opening it.
   --
   This can be done by accessing a property of "MyBehaviorStack",
   such as the stack's name.  This still requires "MyBootStack"
   to make sure that "MyBehaviorStack" is in memory before
   "MyTestStack" is opened, but has the minor convenience of
   not being visible to the user and triggers no opening messages.


c) Include "MyBehaviorStack" in the stackFiles prop of "MyTestStack".
   -
   Any stack files specified in the stackFiles property of a stack
   are loaded into memory at the same time the stack containing that
   list is loaded.  In terms of boot sequence it's functionally
   similar to having those separate stack files as substacks, but
   with the advantage of keeping them separate.


a) and b) conform to Guideline #2 above in an obvious way, explicitly 
putting "MyBehaviorStack" into memory before "MyTestStack" will be 
opened to need it.


c) works because stack files listed in the stackFiles property are all 
loaded with the stack listing them, before behavior resolution takes place.



This seems harder than it is in part because you're super smart and are 
just thinking too hard. :)


Relax.  Put script-only stuff out of your mind, and just think about the 
load order.


Behaviors are among the most powerful things ever introduced in the 
xTalk family of languages.  I waited literally 20 years for them, since 
Allegiant first accepted my proposal for parentScripts but then went 
belly-up before they could implement it.  Well worth even that wait: 
they greatly simplify so many aspects of building complex systems, and 
simple systems become simpler.


The load order rule (Guideline #2 above) in LC is a bit funkier than 
we'd hope for, but even that's not hard to accommodate once we 
understand it.


Pick a, b, or c, to handle the load order, and the world is your oyster.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[William Prothero]

Thanks, Richard:
My previous exposure to the behaviors methodology was in Adobe Director. A 
behavior was assigned to a particular control, field, button, whatever, and in 
its script, it defined a set of properties that could be set custom for each 
instantiation. That way, a “set” of graphics for a button, for example, could 
be assembled as part of a behavior where the “up”, “down”,”over”, “disabled” 
etc, states linked to a particular graphic. Of course, you don’t have to do 
that in Livecode, but that was the idea.

Thanks for the prescription. I’ll try it out. 

Let me know next time you’re in Santa Barbara. I’ll treat you to lunch.
Best,
Bill

> On Mar 31, 2016, at 9:52 AM, Richard Gaskin  
> wrote:
> 
> William Prothero wrote:
> 
> > Reading this kinda makes my head spin. Now I’m thinking it is going
> > to be a heck of a lot more robust for my situation, as a single
> > developer, to not use behaviors at all, but to have a single
> > (possibly script only) substack that holds all of the handlers that I
> > would normally use as behaviors, and just put a call to that handler
> > in each button. I can use “the target”  or “me” as a passed variable
> > to make the action specific to a particular control.
> >
> > This approach seems a lot less prone to idiosyncrasies and more
> > easily transportable to other apps, to me. It also means that all of
> > my “behavior type scripts” would sit in a single script-only stack,
> > which would make it a lot more convenient to access and edit than a
> > bunch of small script only stacks sitting in my project browser.
> >
> > Am I wrong. misguided, foolish, or brilliant?
> 
> Behaviors are very powerful for all sorts of things, whether you work alone 
> or in a team of twenty.
> 
> The biggest benefit for teamwork comes from the very separate question of 
> whether to use script-only stacks to define behaviors.  Script-only stacks 
> are an ideal solution for Github-based workflows, but have minimal value 
> (some, but not as much) for anyone not dependent on a version control system 
> designed for other languages.
> 
> Ditch script-only stacks for now and continue to explore behaviors. You'll 
> thank me.  You'll want to buy me lunch next time I'm in Santa Barbara.  I'll 
> accept.  Behaviors will change everything, very powerfully, the more you 
> explore and use them.
> 
> Once we step away from the very separate issue of script-only stacks, we have 
> really only two guidelines for using behaviors effectively:
> 
> - A behavior definition can be any button or stack.
> 
> - When using behaviors, the object containing the behavior script
>  must be in memory when anything relying on it is brought into
>  memory.
> 
> That's it.
> 
> When exploring a new feature I like to make a simple stack I can use as a 
> playground to poke around and experiment without mucking up anything 
> important I'm working on.
> 
> Here's a quick tutorial that may get you hooked on the power of behaviors:
> 
> 1. Make a new stack titled "Behavior Playground"
> 
> 2. Add a button named "MyClass"
> 
> 3. Set the script of that button to:
> 
>on mouseUp
>   answer the name of me
>end mouseUp
> 
> There - you've just created a behavior, defining an action for what will be 
> an entire class of custom button objects:
> 
> 4. Make a new button named "A"
> 
> 5. In the Message Box run:
> 
>   set the behavior of btn "A" to the long id of btn "MyClass"
> 
> 6. Make two copies of btn "A", naming them "B" and "C" respectively.
> 
> 7. Click any of them.
> 
> What you'll see is that each of them uses the script of button "MyClass" as 
> if it's their own, bringing up an answer dialog showing the unique name of 
> each.
> 
> At this point your mind is already thinking of a dozen times in recent 
> projects where you have several objects you wanted to work the same without 
> affecting any other scripts.  We could leave it here and you'd be off writing 
> behaviors very productively right now.
> 
> But we're going to take this one step further - we'll create a superclass:
> 
> 8. Make a new button named "MySuperClass"
> 
> 9. Set this script of that button to:
> 
>   on mouseDown
>  grab me
>   end mouseDown
> 
> 10. In the Message Box run:
> 
>  set the behavior of btn "MyClass" to the long id of btn "MySuperClass"
> 
> 11. Drag any of the "A", "B", or "C" buttons.
> 
> In just 11 steps, each taking only a few seconds, you've just created a rich 
> hierarchy of custom messaging:
> 
>  "A" "B" "C"
>\  |  /
> \ | /
>MyClass
>   |
>   |
> MySuperClass
> 
> 
> If you wanted the drag behavior used for an entirely different set of objects 
> that do something else on mouseUp, you could make another button named 
> "MyOtherClass" and extend your scope of custom controls even further:
> 
> "A" "B" "C" "D" "E" "F"
>   \  |  / \  |  /
>\ | /   \ | /
>   MyClass   MyOtherClass
>   \ /
> 

Re: Script Only Stack Architecture

[J. Landman Gay]

On 3/31/2016 1:42 PM, Sannyasin Brahmanathaswami wrote:

ergo: merely opening a script-only stack that is applied as a
behavior to a control (not global in scope) does*not*  place into the
msg path.


By the time a preOpenStack handler executes, the engine has already 
loaded the stack into RAM and set up the behaviors. You need to load the 
behaviors before your mainstack even launches. That's why Richard said 
it may require a launcher app that opens the behaviors first and then 
opens the mainstack.


To avoid that, the only method available would be the stackfiles lists. 
The engine apparently checks those first before setting up the behavior 
linkages.


I know you want to implement as much as possible with script-only files, 
but for behaviors it may be easier to just use the original button 
method. You can share behavior button scripts as easily as text files in 
a team environment; they are pretty much self-contained.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

 
Jai Ganesha! I went to bed HST worried I was creating too much churn on this 
list and here you guys kept spinning a web of silk and gold ideas all night 
longAwesome... Now have to digest all this.

BR: "opening the stack did not work"  
RG: What happened?

Still failing today.. try this unit test  

1) create folder "app source  
2) create folder inside "main-stack-scripts"
3) create new stack --> name "Test External File Parent Script" (or whatever)
4) make field and lock it. name it "Hot Field"
5) go to file menu --> new stack --> script only --> create stack 
--"script-only-behavior"
6) put in this script

on mouseup  
answer (the short name of me) with "GoodOnYa from Script-Only Behavior!"
end mouseup

7) save to folder "main-stack-scripts"  
8) in the stacks script of "Test External File Parent Script"

put  

on preopenstack
put localpath() & "main-stack-scripts/testOpenBehavior.livecode" into tStackPath
open stack tStackPath
end preopenstack


function localPath
put specialFolderPath("Resources") into tPath
put "/" after tPath
return tPath
end localPath

9) go to the field and apply the script only stack as behavior to field "Hot 
Field"
10) save everything
11) Quit LC
12) reboot LC
13) open "main" stack --> Test External File Parent Script
14) Application browser confirms: the preopenstack handler triggered with no 
error and the script only  "testOpenBehavior.livecode" is there in the list as 
an open stack
15) click on the field --> nothing happens.
16) go back to main stack props --> Stack files -->browse to
main-stack-scripts/testOpenBehavior.livecode
17) save --> quit LC --> reboot,
18) open main stack "Test External File Parent Script"
19) click on field: result: dialog opens as expected:

Hot Field
  [with] GoodOnYa from Script-Only Behavior!
   

ergo: merely opening a script-only stack that is applied as a behavior to a 
control (not global in scope) does *not* place into the msg path.

BR



On March 31, 2016 at 7:32:22 AM, BNig 
(bernd.niggem...@uni-wh.de(mailto:bernd.niggem...@uni-wh.de)) wrote:

> Richard Gaskin wrote  
> > In just 11 steps, each taking only a few seconds, you've just created a  
> > rich hierarchy of custom messaging:  
> >
___
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: Script Only Stack Architecture

[Robert Brenstein]

Thanks, Richard, that is a very, very nice intro to behaviors!


On 31.03.2016 at 9:52 Uhr -0700 Richard Gaskin apparently wrote:


Behaviors are very powerful for all sorts of things, whether you 
work alone or in a team of twenty.


The biggest benefit for teamwork comes from the very separate 
question of whether to use script-only stacks to define behaviors. 
Script-only stacks are an ideal solution for Github-based workflows, 
but have minimal value (some, but not as much) for anyone not 
dependent on a version control system designed for other languages.


Ditch script-only stacks for now and continue to explore behaviors. 
You'll thank me.  You'll want to buy me lunch next time I'm in Santa 
Barbara.  I'll accept.  Behaviors will change everything, very 
powerfully, the more you explore and use them.




___
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: Script Only Stack Architecture

[BNig]

Richard Gaskin wrote
> In just 11 steps, each taking only a few seconds, you've just created a 
> rich hierarchy of custom messaging:
> 
>"A" "B" "C"
>  \  |  /
>   \ | /
>  MyClass
> |
> |
>   MySuperClass
> 
> 
> If you wanted the drag behavior used for an entirely different set of 
> objects that do something else on mouseUp, you could make another button 
> named "MyOtherClass" and extend your scope of custom controls even
> further:
> 
>   "A" "B" "C" "D" "E" "F"
> \  |  / \  |  /
>  \ | /   \ | /
> MyClass   MyOtherClass
> \ /
>  \   /
> MySuperClass
> 
> Behaviors can be chained as deeply as you like, allowing for very rich 
> class hierarchies.
> 
> This will get you started.  And it only takes a few minutes to explore.

I agree with Richard that behaviors are extremly powerful, especially the
nested behaviors.

But if you want to use this feature dynamically, i.e. to assign a superclass
on runtime and remove it on runtime, which is just the logical extension of
using nested behaviors then you currently have to consider
http://quality.livecode.com/show_bug.cgi?id=17220
(includes a sample stack showing setting a class and superclass)
removing a superclass behavior does not become immediately effective.
You would have to set the class behavior anew.

I hope I made a valuable contribution to confuse everybody and his cat :)

Kind regards
Bernd




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Script-Only-Stack-Architecture-tp4702715p4702873.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 subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Script Only Stack Architecture

[Richard Gaskin]

William Prothero wrote:

> Reading this kinda makes my head spin. Now I’m thinking it is going
> to be a heck of a lot more robust for my situation, as a single
> developer, to not use behaviors at all, but to have a single
> (possibly script only) substack that holds all of the handlers that I
> would normally use as behaviors, and just put a call to that handler
> in each button. I can use “the target”  or “me” as a passed variable
> to make the action specific to a particular control.
>
> This approach seems a lot less prone to idiosyncrasies and more
> easily transportable to other apps, to me. It also means that all of
> my “behavior type scripts” would sit in a single script-only stack,
> which would make it a lot more convenient to access and edit than a
> bunch of small script only stacks sitting in my project browser.
>
> Am I wrong. misguided, foolish, or brilliant?

Behaviors are very powerful for all sorts of things, whether you work 
alone or in a team of twenty.


The biggest benefit for teamwork comes from the very separate question 
of whether to use script-only stacks to define behaviors.  Script-only 
stacks are an ideal solution for Github-based workflows, but have 
minimal value (some, but not as much) for anyone not dependent on a 
version control system designed for other languages.


Ditch script-only stacks for now and continue to explore behaviors. 
You'll thank me.  You'll want to buy me lunch next time I'm in Santa 
Barbara.  I'll accept.  Behaviors will change everything, very 
powerfully, the more you explore and use them.


Once we step away from the very separate issue of script-only stacks, we 
have really only two guidelines for using behaviors effectively:


- A behavior definition can be any button or stack.

- When using behaviors, the object containing the behavior script
  must be in memory when anything relying on it is brought into
  memory.

That's it.

When exploring a new feature I like to make a simple stack I can use as 
a playground to poke around and experiment without mucking up anything 
important I'm working on.


Here's a quick tutorial that may get you hooked on the power of behaviors:

1. Make a new stack titled "Behavior Playground"

2. Add a button named "MyClass"

3. Set the script of that button to:

on mouseUp
   answer the name of me
end mouseUp

There - you've just created a behavior, defining an action for what will 
be an entire class of custom button objects:


4. Make a new button named "A"

5. In the Message Box run:

   set the behavior of btn "A" to the long id of btn "MyClass"

6. Make two copies of btn "A", naming them "B" and "C" respectively.

7. Click any of them.

What you'll see is that each of them uses the script of button "MyClass" 
as if it's their own, bringing up an answer dialog showing the unique 
name of each.


At this point your mind is already thinking of a dozen times in recent 
projects where you have several objects you wanted to work the same 
without affecting any other scripts.  We could leave it here and you'd 
be off writing behaviors very productively right now.


But we're going to take this one step further - we'll create a superclass:

8. Make a new button named "MySuperClass"

9. Set this script of that button to:

   on mouseDown
  grab me
   end mouseDown

10. In the Message Box run:

  set the behavior of btn "MyClass" to the long id of btn "MySuperClass"

11. Drag any of the "A", "B", or "C" buttons.

In just 11 steps, each taking only a few seconds, you've just created a 
rich hierarchy of custom messaging:


  "A" "B" "C"
\  |  /
 \ | /
MyClass
   |
   |
 MySuperClass


If you wanted the drag behavior used for an entirely different set of 
objects that do something else on mouseUp, you could make another button 
named "MyOtherClass" and extend your scope of custom controls even further:


 "A" "B" "C" "D" "E" "F"
   \  |  / \  |  /
\ | /   \ | /
   MyClass   MyOtherClass
   \ /
\   /
   MySuperClass

Behaviors can be chained as deeply as you like, allowing for very rich 
class hierarchies.


This will get you started.  And it only takes a few minutes to explore.


-- EXTRA CREDIT ---

After you feel comfortable with this, an extra credit exercise might be 
explore overriding and overloading.


Overriding is blocking an action defined in a parent by using a handler 
of the same name in a child.


For example, if you decided button "C" was different from the others and 
should reports its long ID rather than its name, you could write a 
script in it with:


  on mouseUp
answer the long id of me
  end mouseUp

...and it'll do that, without affecting any other behaviors provided by 
the parent script, or affecting any other objects that use the parent 
script.


Overloading is augmenting a behavior without replacing it.

So if you wanted your custom controls (buttons "A", "B", etc.) to be 

Re: Script Only Stack Architecture

[Richard Gaskin]

Mark Waddingham wrote:
> I still have a difficult time wrapping my head around the syntax for
> multiple custom property sets - especially since the introduction of
> nested arrays:
>
> http://quality.livecode.com/show_bug.cgi?id=6912
>
> ;)

This reminds me of a hypothesis I have that perhaps you can confirm:

When we use array syntax on custom property sets we have effectively a 
sort of two-dimensional array.  Would be nice to extend that deeper, but 
I'll take what I get.


But when we put an array into a custom property value such as:

put "foo" into bar[1]
set the uBar of btn 1 to bar

...it seems we can store that even though it hasn't been explicitly 
serialized.


So my hunch is that when we do that the engine is using the same 
serialization it uses for arrayEncode, and when retrieving the array it 
automatically runs it through the internal equivalent of arrayDecode.


Is that correct?

If not, by what sorcery are array values serialized when stored as 
persistent property values?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[William Prothero]

Thierry:
Thanks! As an afterthought, I should have added an “all of the above” choice 
because I visit each of those intellectual realms frequently.
Best,
Bill

> On Mar 31, 2016, at 8:46 AM, Thierry Douez  wrote:
> 
>> Am I wrong. misguided, foolish, or brilliant?
>> 
> 
> ​You are brilliant !!!
> 
> Mmm, as long as you don't need behaviors :)
> 
> Kind regards,
> 
> Thierry
> 
> ---​
> 
> Thierry Douez - http://sunny-tdz.com
> sunnYrex - sunnYtext2speech - sunnYperl - sunnYmidi - sunnYmage
> ___
> 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: Script Only Stack Architecture

[Thierry Douez]

> Am I wrong. misguided, foolish, or brilliant?
>

​You are brilliant !!!

Mmm, as long as you don't need behaviors :)

Kind regards,

Thierry

---​

Thierry Douez - http://sunny-tdz.com
sunnYrex - sunnYtext2speech - sunnYperl - sunnYmidi - sunnYmage
___
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: Script Only Stack Architecture

[William Prothero]

Folks:
Reading this kinda makes my head spin. Now I’m thinking it is going to be a 
heck of a lot more robust for my situation, as a single developer, to not use 
behaviors at all, but to have a single (possibly script only) substack that 
holds all of the handlers that I would normally use as behaviors, and just put 
a call to that handler in each button. I can use “the target”  or “me” as a 
passed variable to make the action specific to a particular control.

This approach seems a lot less prone to idiosyncrasies and more easily 
transportable to other apps, to me. It also means that all of my “behavior type 
scripts” would sit in a single script-only stack, which would make it a lot 
more convenient to access and edit than a bunch of small script only stacks 
sitting in my project browser.

Am I wrong. misguided, foolish, or brilliant?

Best,
Bill

> On Mar 31, 2016, at 8:04 AM, Richard Gaskin  
> wrote:
> 
> Sannyasin Brahmanathaswami wrote:
> 
> > On March 30, 2016 at 6:17:20 PM, Richard Gaskin wrote:
> >
> >> in brief:
> >> 1. Open them
> >
> > # this did not work for me earlier today
> 
> What exactly happened?
> 


___
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: Script Only Stack Architecture

[Mark Waddingham]

On 2016-03-31 17:04, Richard Gaskin wrote:

Happy to help.  Just paying it forward.  You should have seen some of
my posts on the MetaCard list circa '98.  I was moving from SuperCard,
where we only had a single custom property set, and was having a very
difficult time wrapping my head around the syntax for working with
multiple property sets.  Kevin Miller and Scott Raney were far more
patient with me back then than I've ever been. :)


I still have a difficult time wrapping my head around the syntax for 
multiple custom property sets - especially since the introduction of 
nested arrays:


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

;)

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> On March 30, 2016 at 6:17:20 PM, Richard Gaskin wrote:
>
>> in brief:
>> 1. Open them
>
> # this did not work for me earlier today

What exactly happened?

It may be helpful while demystifying this to work with ordinary stack 
files for your behavior scripts.  There's really no difference between 
ordinary stack files and script-only stack files beyond the storage 
format, but if nothing else sense you're already confident in your use 
of normal stacks it may help you focus on the things that may actually 
be the source of the problem.


In this case, with opening a stack used as a behavior script, I'd guess 
that the problem wasn't that the stack couldn't be opened, but that it 
failed to resolve as a behavior for another object.


If that hunch is correct then the problem isn't with the script-only 
stacks or even how you opened them.  The problem is with the strangely 
finicky way behaviors are resolved.  As I wrote yesterday:


   NOTE: a long-standing source of confusion and frustration with
   behaviors is that the object holding the behavior script must
   be in memory when any stack containing objects subscribed to it
   is loaded.

   When behaviors are in the same stack file the engine figures it
   out on its own.  But if the behaviors are in a separate stack
   file (regardless of whether it's script-only or normal) that
   separate stack file must be in memory first.

   In some cases this can mean introducing a new stack only for
   the purpose of loading your others so that they load in an
   order that will allow behaviors to be resolved correctly.

   Another option is to write a script that works on preOpenStack
   and walks through each object setting the object's behavior
   property to the object's behavior property, which forces
   resolution of the information already known to the engine but
   not loaded in the finicky order it requires.

   A request to simplify this has been submitted:
   

Given that this finicky quality has been around as long as parentScripts 
themselves (er, "behaviors" ), I don't expect to see it addressed 
soon.  Would be nice, but there are bigger fish to fry with v8 right now.


So we just need to make sure that anything containing a behavior script 
is in memory when anything that relies on that behavior script is put 
into memory.


Review the sequence of stack opening you'd tried earlier and see if 
that's not what had caused your earlier problem with opening the 
behavior definition stacks.



>> 2. Read any property from them
>
> # have yet to try that..

It's kinda handy sometimes because it needs to unpack the stack file to 
be able to obtain a property value, but since it's not truly opening the 
stack per se it never shows visibly and doesn't trigger the open- 
messages (preOpenStack, preOpenCard, openStack, etc.).




> 3. Adding stack files and restarting the stack works

The stackFiles is an old property predating behaviors, but useful for 
many things like image ID resolution and more - a good fit for any 
problem where you have multiple stack files used by a single stack that 
relies on them.


I rarely use it because my runtime setup is very different from my 
development setup (most external stack files are used on multiple 
projects and reside in a very different folder from the relative 
position they'll be to the app's mainstack when deployed).  But I miss 
it.  Very handy.



> Forgive me for seeming to be obtuse.  It's partly deliberate because
> the discourse is  opaque enough to make using script-only stacks for
> behaviors challenging --  gaps in the picture of "exactly what should
> I do?"  so I thought we might get some "ghee" out of the churn  --
> clear instructions, for everyone -- and also because I really want to
> go this modular direction so I tend to dig, dig, dig until all the
> worms are out of the can and crawling on the table. Gold may appear.

It can seem daunting when you're making so many changes at once, since 
that makes it hard to pin down the root cause of an issue.


But I think we can boil down text-optimized development in a few simple 
guidelines:


1. Use libraries for as much global availability as practical,
   and use behaviors for as much object-specific availability
   as practical.

2. When using behaviors, the object containing the behavior script
   must be in memory when anything relying on it is brought into
   memory.

3. A library can be any stack, regardless whether it's a mainstack
   or substack.

4. A behavior definition can be any button or stack.

5. The format of the stack on disk (whether saved as an ordinary
   binary stack or as a script-only stack) only affects what gets
   saved in the file, but has no affect on how we work with them
   in memory.


Far harder than any of this is learning to use GitHub. :)



> I did read your post and I did try to put my script-only stack  into
> memory by using 

Re: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

On March 30, 2016 at 6:17:20 PM, Richard Gaskin 
(ambassa...@fourthworld.com) wrote:

Here's my post noting the other two ways (in addition to using the
stackFiles property) of loading stacks into memory:


in brief:
1. Open them

# this did not work for me earlier today

2. Read any property from them

# have yet to try that..

3. Adding stack files and restarting the stack works

Forgive me for seeming to be obtuse.  It's partly deliberate because the 
discourse is  opaque enough to make using script-only stacks for behaviors 
challenging --  gaps in the picture of "exactly what should I do?"  so I 
thought we might get some "ghee" out of the churn  -- clear instructions, for 
everyone -- and also because I really want to go this modular direction so I 
tend to dig, dig, dig until all the worms are out of the can and crawling on 
the table. Gold may appear.

I did read your post and I did try to put my script-only stack  into memory by 
using "open" in the preopenstack of the main stack.

But it did not work. The child called out, (mouse up on field) but the parent 
didn't hear it even though he was in the room (in memory via "open)

 I will test again tomorrow after letting LC8 rest over night. The LC8 IDE has 
a  referencing issues... and is "losing the target" in a number of scenarios. 
Like the case of deleting an object on your card and watching while a button in 
the inspector palette disappears instead. Msg path gone awry until you restart. 
The failure of mouseup to not trigger the behavior when the parent stack is in 
memory already... smells like a similar fish...

I agree BTW -- "parent" is a  much more helpful term.. we use that in CSS and 
XML... so why not here? I've even start replacing "behavior" with "parent" in 
my head, as it helps keep things straight.

POINT:  though you may not want to overload the dictionary, something more is 
needed.  Who has contributing rights?I could give is a shot (much more 
concise.)

Mahalo for your near-infinite patience!


___
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: Script Only Stack Architecture

[J. Landman Gay]

On 3/31/2016 12:44 AM, J. Landman Gay wrote:

If a field is editable, a right-click generates editing messages


Typo. Should say "left click". Oops.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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: Script Only Stack Architecture

[J. Landman Gay]

On 3/30/2016 9:57 PM, Matt Maier wrote:

I just tried reproducing your actions and now I'm confused. All I did was
make a new stack, drag a field onto it, then put:

on mouseUp
put "hello" & cr after me
end mouseUp

When I left-click, nothing happens, even though I can double click to
select words and I can left-click-drag to highlight words.

When I right-click, the field's script runs and "hello" appears in the
field.

The field doesn't even get "mouseUp" (or mouseDown for that matter) when I
left-click, but it does when I right-click.

I'm using 8dp13. Is that supposed to happen?


Yes, that's normal behavior. If a field is editable, a right-click 
generates editing messages like openField, enterField, etc. If the field 
is not editable (it's locked) then it will get mouseUp messages. An 
editable field will also get mouseUp on a right-click (useful for 
generating a contextual menu.)


But in the context of this thread, placing the handler directly into the 
field script isn't the same thing as assigning a behavior to the field.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

For script-only stack.. what are the other two methods besides adding them as 
stack files?


AFAIK there's nothing about loading stacks that's specific to 
script-only stacks.  Stacks are stacks, binary or script-only we work 
with them the same.  The difference is the storage format on disk.


Here's my post noting the other two ways (in addition to using the 
stackFiles property) of loading stacks into memory:



in brief:
1. Open them
2. Read any property from them

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

For script-only stack.. what are the other two methods besides adding them as 
stack files?



On March 30, 2016 at 4:59:45 PM, Richard Gaskin 
(ambassa...@fourthworld.com) wrote:

Any of the three methods I mentioned earlier will work.
___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Also note that it if you use "open" to open your script only stack
> file... it is still not in the message path

It doesn't need to be in the message path.  It just needs to be in 
memory.  My earlier posts offered three different ways to load a stack 
into memory.



> and your behaviors will fail, furthermore, if you put "start using
> stack" (in an open stack, preopenstack  handler) to load your script
> only stack, it will receive all messages from the stack and not just
> from the child control to which it is assigned.

That's true, but it's also true that if you decide to insert a script 
into the frontScripts or backscripts it will also be global in scope.


I'm not sure we need to overload that Dictionary entry with every 
possible thing people might do.


Most folks use "start using" and "insert script" when they want a 
specific global availability.  I think it's fine that those Dict entries 
handle those.


For the behaviors Dict entry, rather than list all the things we might 
not want to do it seems better to just provide at least a couple ways to 
do what we actually want to do.


Any of the three methods I mentioned earlier will work.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Matt Maier]

I just tried reproducing your actions and now I'm confused. All I did was
make a new stack, drag a field onto it, then put:

on mouseUp
put "hello" & cr after me
end mouseUp

When I left-click, nothing happens, even though I can double click to
select words and I can left-click-drag to highlight words.

When I right-click, the field's script runs and "hello" appears in the
field.

The field doesn't even get "mouseUp" (or mouseDown for that matter) when I
left-click, but it does when I right-click.

I'm using 8dp13. Is that supposed to happen?

On Wed, Mar 30, 2016 at 7:14 PM, Sannyasin Brahmanathaswami <
bra...@hindu.org> wrote:

> @ Richard:
>
> I looked at the bug 8993 . The problem is... what does "loaded" actually
> mean?
>
> After two days of research, study and testing and responses here...
>  I *still* could not  figure it out (until now thanks to your tip on stack
> files)
>
> Indeed a serious confusion/conundrum for a new comer.
>
> Create script-only.livecode stack
>
> script "script-only"
> on mouseup
>Put "Hello" into me
> end mouseup
>
> Save, open and apply as behavior to field. lock field, click on it..
> nothing happens. msg is not sent to the behavior script.
>
> put  this into preopenstack
>
> start using stack  "[path-to]/script-only.livecode"
>
> Now the madness begins: the stack accepts mousedown from *anywhere* on the
> UI and triggers an error, because "me" is not the field to which the
> behavior was applied.
>
>  changing the preopenstack handler to
>
> open stack  "[path-to]/script-only.livecode"
>
> does not "load" it as such.. it is open, You can see it if you were to set
> behaviors it is there in the dropdown menu under the inspector but the
> field that has it set as a behavior does not trigger the mouseup in the
> behavior stack script. Baffling for a newbie.
>
> IN the bug Mark Waddington writes: "I'm going to cease thinking of this as
> an enhancement request, and instead as a bug - the method used currently is
> too opaque."
>
> opaque is an understatement. Virtually Impenetrable may be better.
>
> Stack files Wow... that works!
>
> So why not just declared this asap  and very, very explicitly in the new
> documentation, ugly and as verbose as this appears, this is what we need:
>
> -
>
> "In order to use script only stacks  as behaviors in specific controls,
> these must be loaded as stack files so that they are placed into the
> message path along with the scripts of your main stack. In your main stack
> (or substacks that may use them)   Use the inspector, choose stack files
> and browse to choose your script on disk.
>
> Unlike button behaviors which are embedded in your stack, you must be sure
> to include these stacks later when you move, package or distribute your
> main stack. Also be aware that the main stack cannot track changes to the
> location of these stack files. If you move them on disk the reference to
> the stack will fail and you will need to update the stack files and point
> to the stack in it's new locations.
>
> Also note that it if you use "open" to open your script only stack file...
> it is still not in the message path and your behaviors will fail,
> furthermore, if you put "start using stack" (in an open stack,
> preopenstack  handler) to load your script only stack, it will receive all
> messages from the stack and not just from the child control to which it is
> assigned. e.g. if your intent is for the child control(s) to respond to "on
> mouseup"  this will not work if you do "start using" for your script-only
> stack."
>
> ---
>
> ___
> 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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

@ Richard:

I looked at the bug 8993 . The problem is... what does "loaded" actually mean?

After two days of research, study and testing and responses here...
 I *still* could not  figure it out (until now thanks to your tip on stack 
files)

Indeed a serious confusion/conundrum for a new comer.

Create script-only.livecode stack

script "script-only"
on mouseup
   Put "Hello" into me
end mouseup

Save, open and apply as behavior to field. lock field, click on it.. nothing 
happens. msg is not sent to the behavior script.

put  this into preopenstack

start using stack  "[path-to]/script-only.livecode"

Now the madness begins: the stack accepts mousedown from *anywhere* on the UI 
and triggers an error, because "me" is not the field to which the behavior was 
applied.

 changing the preopenstack handler to

open stack  "[path-to]/script-only.livecode"

does not "load" it as such.. it is open, You can see it if you were to set 
behaviors it is there in the dropdown menu under the inspector but the field 
that has it set as a behavior does not trigger the mouseup in the behavior 
stack script. Baffling for a newbie.

IN the bug Mark Waddington writes: "I'm going to cease thinking of this as an 
enhancement request, and instead as a bug - the method used currently is too 
opaque."

opaque is an understatement. Virtually Impenetrable may be better.

Stack files Wow... that works!

So why not just declared this asap  and very, very explicitly in the new 
documentation, ugly and as verbose as this appears, this is what we need:

-

"In order to use script only stacks  as behaviors in specific controls, these 
must be loaded as stack files so that they are placed into the message path 
along with the scripts of your main stack. In your main stack (or substacks 
that may use them)   Use the inspector, choose stack files and browse to choose 
your script on disk.

Unlike button behaviors which are embedded in your stack, you must be sure to 
include these stacks later when you move, package or distribute your main 
stack. Also be aware that the main stack cannot track changes to the location 
of these stack files. If you move them on disk the reference to the stack will 
fail and you will need to update the stack files and point to the stack in it's 
new locations.

Also note that it if you use "open" to open your script only stack file... it 
is still not in the message path and your behaviors will fail, furthermore, if 
you put "start using stack" (in an open stack, preopenstack  handler) to load 
your script only stack, it will receive all messages from the stack and not 
just from the child control to which it is assigned. e.g. if your intent is for 
the child control(s) to respond to "on mouseup"  this will not work if you do 
"start using" for your script-only stack."

---

___
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: Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Richard if you are updating the dict entry on this: we need to be
> even more clear:
>
> e.g. if your intent is for the child control(s) to respond to "on
> mouseup"  this will not work if you do "start using" for your
> script-only stack." When you use "start using" the entire main stack
> file becomes, in effect a "child" of the behavior stack because you
> have set it as a global library and not a parent of specific controls

I wasn't doing that update, but did it recommend using "start using" for 
behavior scripts?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

Richard if you are updating the dict entry on this: we need to be even more 
clear:

e.g. if your intent is for the child control(s) to respond to "on mouseup"  
this will not work if you do "start using" for your script-only stack." When 
you use "start using" the entire main stack file becomes, in effect a "child" 
of the behavior stack because you have set it as a global library and not a 
parent of specific controls

Svasti Astu! Be Well

Brahmanathaswami
http://www.himalayanacademy.com/apps/gurudeva


On March 30, 2016 at 3:09:31 PM, Sannyasin Brahmanathaswami 
(bra...@hindu.org) wrote:

e.g. if your intent is for the child control(s) to respond to "on mouseup"  
this will not work if you do "start using" for your script-only stack."
___
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: Script Only Stack Architecture

[Richard Gaskin]

I recently wrote:

NOTE: a long-standing source of confusion and frustration with behaviors
is that the object holding the behavior script must be in memory when
any stack containing objects subscribed to it is loaded.

When behaviors are in the same stack file the engine figures it out on
its own.  But if the behaviors are in a separate stack file (regardless
of whether it's script-only or normal) that separate stack file must be
in memory first.

In some cases this can mean introducing a new stack only for the purpose
of loading your others so that they load in an order that will allow
behaviors to be resolved correctly.

Another option is to write a script that works on preOpenStack and walks
through each object setting the object's behavior property to the
object's behavior property, which forces resolution of the information
already known to the engine but not loaded in the finicky order it requires.

A request to simplify this has been submitted:



I forgot to mention an even simpler way to make external stack files 
available, provided the first stack being loaded is a normal stack file 
(as opposed to script-only, which has no properties other than a script):


Just use the stackFiles property, adding any external stacks you like.

Apparently the stackfiles entries are loaded at the same time the stack 
containing those entries is loaded, and since they use relative paths 
they're fairly simple to work with.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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: Script Only Stack Architecture

[Richard Gaskin]

On 03/30/2016 03:53 PM, Sannyasin Brahmanathaswami wrote:


1) create a script only stack. Save to disk and leave open call it
"behavior-field-text.livecodescript)
2) create field; set behavior, aha! my new script only stack is available.
3) assign the stack to the field

...

4) lock field, click on field... nothing happens  hhh (blink)

5) go to the message box... on a hunch type

"start using behavior-field-text.livecodesript"


"start using" is the command to start using a stack as a library, 
putting it globally into the back of the message path.  Since you're 
using these stack as a behavior script that's probably not what you want.


You can simply open the stacks (invisibly if you prefer), or you can 
load a stack file into memory by just querying any property within it, 
such as:


  get the name of stack "SomeStack"

Might be nice to have a "load stack" command, but for now even though 
the syntax may seem less intuitive the result is equally achievable.



NOTE: a long-standing source of confusion and frustration with behaviors 
is that the object holding the behavior script must be in memory when 
any stack containing objects subscribed to it is loaded.


When behaviors are in the same stack file the engine figures it out on 
its own.  But if the behaviors are in a separate stack file (regardless 
of whether it's script-only or normal) that separate stack file must be 
in memory first.


In some cases this can mean introducing a new stack only for the purpose 
of loading your others so that they load in an order that will allow 
behaviors to be resolved correctly.


Another option is to write a script that works on preOpenStack and walks 
through each object setting the object's behavior property to the 
object's behavior property, which forces resolution of the information 
already known to the engine but not loaded in the finicky order it requires.


A request to simplify this has been submitted:




PS: Thanks for the CC, but if this was sent to the list I'm also a 
subscriber and will get a copy there.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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: Script Only Stack Architecture

[Peter Haworth]

"start using" puts all handlers in the stack into the message path as front
scripts which is why all your mouseUp messages are being caught.

If your script-only stack is a separate main stack from your application's
main stack, just open the script-only stack in the preOpenxxx handler of
your app's main stack.  I haven't used script-only stacks yet but I think
they could be included in your app as substacks rather than separate main
stacks, then you wouldn;t need to do anything special after opening your
app's main stack.

On Wed, Mar 30, 2016 at 4:03 PM Sannyasin Brahmanathaswami 
wrote:

> Monte:
>
> Thanks for the thoughtful response.
>
> For now, even the basics would help... in the dictionary... I had to test
> this morning to learn things that could all be placed on a single page of
> documentation
>
> 1) create a script only stack. Save to disk and leave open call it
> "behavior-field-text.livecodescript)
> 2) create field; set behavior, aha! my new script only stack is available.
> 3) assign the stack to the field  -- should accept on mousup, field is
> locked and the behavior refers to "me") for testing the behavior stack has
> a simple:
>
>
> on mouseup
>
> answer "from stack behavior"
>
> put the formattedheight of me into tTotalTextHeight
>
> put ( the height of me - tTotalTextHeight ) / 2 into tTopBottomMargins
>
> set topmargin of me to tTopBottomMargins
>
> end mouseUp
>
> 4) lock field, click on field... nothing happens  hhh (blink)
>
> 5) go to the message box... on a hunch type
>
> "start using behavior-field-text.livecodesript"
>
> 6) click on field ... Oh, it works now!
>
> 7) save stack quit LC
>
> 8) boot LC again... open main stack with field that has the behavior
>
> 9) click on field that has behavior assign, Oh gosh... now it doesn't work.
>
> 10) But wait... inspect field  the behavior is assigned to
> "behavior-field-text.livecodesript"
> -- Why doesnt' it work... duh
>
> 11) to go main stack, preopenstack handler  add this:
>
> put specialFolderPath("Resources") into tAppRoot
> start using stack (tAppRoot
> &"/"&"/main-stack-scripts/behaviors/sv_field-behaviors.livecode"
>
> 12) from msg box run "preopenstack" -- my behavior stack is now in use,
> theoretically.
>
> 13) Note that only one  field has this stack behavior assigned
>
> but now: any mouseup anywhere on the UI triggers the script.. mouseup msg
> from anywhere is intercepted by the script-only-stack that is assigned to
> just a single field.
>
> Also: reference to "me" obviously lost and the behavior script thinks "me"
> refers to itself and not the child field.
>
>
> [X] executing at 12:42:02 PM<
> http://airmail.calendar/2016-03-30%2012:42:02%20HST>
>
> Type Object: does not have this property
>
> Object sv_field-behaviors
>
> Line put the formattedheight of me into tTotalTextHeight
>
> Hint mouseup
>
>
> 14) move that script to a button... change the field behavior to that
> button.
>
>
> on mouseup
>
> answer "from btn behavior"
>
> put the formattedheight of me into tTotalTextHeight
>
> put ( the height of me - tTotalTextHeight ) / 2 into tTopBottomMargins
>
> set topmargin of me to tTopBottomMargins
>
> end mouseUp
>
>
> and it works out of the box...
>
>
> --- pretty much a complete nightmare...lost all day yesterday<
> http://airmail.calendar/2016-03-29%2012:00:00%20HST> and all morning
> today...
>
> Sure what I hope for is a full scope architecture thing...
>
> but for now: We are  not asking for a lot, just enough to understand how
> to make it work?
>
> Since this model has been in use since 6.5 or something like that...
> clearly it works.  Can we just document how?
>
> unable to assign behavior to script-only-stack.
>
>
>  What am I Missing?
>
> BR
>
>
> ___
> 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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

Monte:

Thanks for the thoughtful response.

For now, even the basics would help... in the dictionary... I had to test this 
morning to learn things that could all be placed on a single page of 
documentation

1) create a script only stack. Save to disk and leave open call it 
"behavior-field-text.livecodescript)
2) create field; set behavior, aha! my new script only stack is available.
3) assign the stack to the field  -- should accept on mousup, field is locked 
and the behavior refers to "me") for testing the behavior stack has a simple:


on mouseup

answer "from stack behavior"

put the formattedheight of me into tTotalTextHeight

put ( the height of me - tTotalTextHeight ) / 2 into tTopBottomMargins

set topmargin of me to tTopBottomMargins

end mouseUp

4) lock field, click on field... nothing happens  hhh (blink)

5) go to the message box... on a hunch type

"start using behavior-field-text.livecodesript"

6) click on field ... Oh, it works now!

7) save stack quit LC

8) boot LC again... open main stack with field that has the behavior

9) click on field that has behavior assign, Oh gosh... now it doesn't work.

10) But wait... inspect field  the behavior is assigned to 
"behavior-field-text.livecodesript"
-- Why doesnt' it work... duh

11) to go main stack, preopenstack handler  add this:

put specialFolderPath("Resources") into tAppRoot
start using stack (tAppRoot 
&"/"&"/main-stack-scripts/behaviors/sv_field-behaviors.livecode"

12) from msg box run "preopenstack" -- my behavior stack is now in use, 
theoretically.

13) Note that only one  field has this stack behavior assigned

but now: any mouseup anywhere on the UI triggers the script.. mouseup msg from 
anywhere is intercepted by the script-only-stack that is assigned to just a 
single field.

Also: reference to "me" obviously lost and the behavior script thinks "me" 
refers to itself and not the child field.


[X] executing at 12:42:02 
PM

Type Object: does not have this property

Object sv_field-behaviors

Line put the formattedheight of me into tTotalTextHeight

Hint mouseup


14) move that script to a button... change the field behavior to that button.


on mouseup

answer "from btn behavior"

put the formattedheight of me into tTotalTextHeight

put ( the height of me - tTotalTextHeight ) / 2 into tTopBottomMargins

set topmargin of me to tTopBottomMargins

end mouseUp


and it works out of the box...


--- pretty much a complete nightmare...lost all day 
yesterday and all morning 
today...

Sure what I hope for is a full scope architecture thing...

but for now: We are  not asking for a lot, just enough to understand how to 
make it work?

Since this model has been in use since 6.5 or something like that... clearly it 
works.  Can we just document how?

unable to assign behavior to script-only-stack.


 What am I Missing?

BR


___
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: Script Only Stack Architecture

[James Hale]

> what is the equivalent of
> 
> set the behavior of tNewGroup to the long id of button "Widget" of card 
> "Behaviors"
> 
> where "the long id of button" points instead to a script only stack?

I think it is simply...
 set the behavior of tNewGroup to stack "myScriptOnlyStack"

If you check some of the IDE scripts in GitHub you should find some examples.




___
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: Script Only Stack Architecture

[Monte Goulding]

> On 30 Mar 2016, at 6:26 AM, Sannyasin Brahmanathaswami  > wrote:
> 
> @ Mark, Monte, Peter (brett)  if you are inspired   -- a tutorial on 
> "building an app from scratch, using the script-only modular approach to the 
> max."  as a video tutorial or something would be fantastic…


I’m not officially on the team yet so please take anything I say about what I 
think the team should be doing with a pinch of salt. Having said that I think 
it would be reasonably beneficial for the team to develop and maintain a number 
of apps that could be the basis of tutorials, blog posts and maybe even 
diversify revenue if done right (probably shouldn’t be a major goal). The 
reason being is engine & IDE development <> app development. The concept needs 
a thorough cost benefit analysis done on it though to work out if it should be 
prioritised over the many thousands of other things that need doing. It would 
really need to be a long term strategy uniting marketing, documentation and 
testing of the IDE and engine if it were to be worthwhile.

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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

Chipp's MagicCarpet was useful in its day... then came the lock down: no FTP  
in clear text.

That may change soon as I believe we are getting close to solutions for SFTP. 
There is still a strong use case for passing the baton/binary-stack (ck in, ck 
out)  style collaboration. I really can't see myself (or anyone?) using script 
to set colors, gradients, font style etc. to objects run time on preOpenStack 
to render the GUI.  Eye-candy design team can passing the GUI (binary stack) 
back and forth, while the code nerd build up the text only platform 
underneath... how those to production processes would play together is another 
thing to think about.

Can someone give me the syntax for assigning someScriptOnlyStack.livecode to a 
childObject as a behavior?

I'll looking at the dictionary in LC 8 dp 16... but nada

what is the equivalent of

set the behavior of tNewGroup to the long id of button "Widget" of card 
"Behaviors"

where "the long id of button" points instead to a script only stack?

Oh and.. .this has possibilities as well (from the dict), I didn't know till 
now that we have this cascading option too:


For example, let's say you have the following setup: field "Action" - behaviour 
set to button "Derived" button "Derived" - behaviour set to button "Root" 
button "Root"

Then the message path will be: field "Action" button "Derived" button "Root"


BR


On March 29, 2016 at 1:53:24 PM, Richard Gaskin 
(ambassa...@fourthworld.com) wrote:
Chipp Walters, Ken Ray, and others have made check-in/check-out style
tools for many years to handle multi-person team development rather
well. In Gain Momentum (an xTalk I once used made by Sybase) they had a
system like that built in.
___
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: Script Only Stack Architecture

[Richard Gaskin]

William Prothero wrote:

> I put almost all of my code in substacks, but haven’t tried text only
> stacks yet. I can’t see having a jillion small text files to keep
> track of. But then, a lot of folks seem to love them, so I wonder at
> the advantages. Of course, there’s the github thing.

That's pretty much it.  Xtalks give us the option of sharing code 
between projects in stack files, or keeping lots of stacks tidily tucked 
away in substacks if they're only used in one project.  And with the 
flexibility of LC's Standalone Builder, we can even have shared library 
stacks included with out mainstack at build time, to deliver a 
convenient single-file standalone that truly stands alone.


Chipp Walters, Ken Ray, and others have made check-in/check-out style 
tools for many years to handle multi-person team development rather 
well.  In Gain Momentum (an xTalk I once used made by Sybase) they had a 
system like that built in.


But that's just us, here in our relatively small corner of the world.

Then there's the rest of the world: a landscape filled with text files. 
 Lots of them. An app made in C++ or Python or most other languages is 
a rather sizable collection of text files.  The LC code base, for 
example, has hundreds.  The Linux kernel, one of the largest software 
projects on earth, uses more than 38,000 source files.


Given how those languages work, it made sense for version control 
systems to be created which are based around managing lots of tiny text 
files.


Our world and theirs happily coexisted much as Native Americans and 
Europeans did for so many centuries:  life was easy for centuries, until 
they met.


LiveCode's audience is growing, and the use of traditional version 
control systems has also grown.


Today, so many dev shops are so attached to the work flows afforded by 
modern VCSes like Github that it would be a severe impairment for them 
to do without.  And unless LiveCode could adapt to those VCSes, that 
would mean no LiveCode for them.


So script-only stacks are part of an evolutionary process for LiveCode, 
a way to play nice with others.


Now that behavior scripts (which I still believe would be less ambiguous 
and more descriptive if called by their original name, "parentScripts") 
can use script-only stacks as well, and now that Widgets are externally 
written script files, most of the code in even the most complex LiveCode 
app can be put into text files for those that need it, leaving only 
relatively small UI stacks as binary files, no worse than XCode's NIB files.


I still feel there's a role for other versioning systems, including the 
sorts of stack-file-based check-in/check-out systems we've seen.  But I 
believe it's a limited one, best suited for certain type of development 
shops.


As much as those may seem like with-the-grain solutions for LiveCode, 
they also arguably contribute to LiveCode being a sort of island, 
marginalized outside of the infrastructure through which the rest of the 
world shares code.


And best IMO is that this is not merely a theoretical exercise:  the 
team is eating their own haggis by putting these features to work in the 
IDE, one of the most complex LiveCode apps around.


And if you follow the team's progress on Github you can see the benefits 
for large projects immediately:

https://github.com/livecode/livecode/pulse

It would take significant effort to make a VCS ourselves that was as 
complete, but that and more is available for free there.




> Code that’s portable between apps is important. Perhaps that would
> be something to discuss. And I really haven’t messed with
> implementing personal code “Libraries”. The requirement for strict
> ID’s for behaviors makes them less portable. Do text only stacks help
> in this regard?

Not necessarily, but if you're working in teams they can be tremendously 
beneficial by allowing you to use common diff tools to quickly identify 
changes.


And for those working on open source projects I would consider 
script-only libraries almost essential, since folks likely to contribute 
to such projects are already on Github and know the flow.



> So, I think what I’m “seconding” is that a higher lever than “newby”
> tutorials on code organization through Libraries, Text only stacks,
> substacks, etc, would be useful and I would give it a hard look-see.
> Currently, I’m pretty satisfied with my current approach, but over
> the last year, I’ve changed it so much as I learned more about
> LiveCode, that I wonder what I’m missing.

You and me both.  Just like the LC IDE now undergoing its fourth major 
revision, every few years I look at my code and the mix of new language 
features plus what I've learned since I wrote it and I dive in for a 
rewrite.


In other language the scope of materials Bramanathaswami described is 
handled in a book, of which several compete in the pursuit of a "best".


All I know is I can't write one of them:  given how long it takes to 
write a good book by 

Re: Script Only Stack Architecture

[William Prothero]

Richard:
Some of the items were mentioned in Bramanathaswami’s post. Some, of course, is 
just taste. I put almost all of my code in substacks, but haven’t tried text 
only stacks yet. I can’t see having a jillion small text files to keep track 
of. But then, a lot of folks seem to love them, so I wonder at the advantages. 
Of course, there’s the github thing. I work by myself, so that isn’t a factor, 
but I can see it would be major for teams.

Code that’s portable between apps is important. Perhaps that would be something 
to discuss. And I really haven’t messed with implementing personal code 
“Libraries”. The requirement for strict ID’s for behaviors makes them less 
portable. Do text only stacks help in this regard?

So, I think what I’m “seconding” is that a higher lever than “newby” tutorials 
on code organization through Libraries, Text only stacks, substacks, etc, would 
be useful and I would give it a hard look-see. Currently, I’m pretty satisfied 
with my current approach, but over the last year, I’ve changed it so much as I 
learned more about LiveCode, that I wonder what I’m missing.

Thanks, Richard, for all your comments and help on this list.
Best,
Bill

> On Mar 29, 2016, at 1:58 PM, Richard Gaskin  
> wrote:
> 
> William Prothero wrote:
> 
>> Organizing the code in a project is really important and there are lots of 
>> ways to go wrong.
> 
> Can you describe some?
> 
> While documenting good patterns can be useful, sometimes documenting 
> anti-patterns is just as useful.
> 
> Several years ago at one of the LC conferences in Monterey Ken Ray and I did 
> a talk called "LiveCode Patterns and Anti-Patterns".  So much has changed 
> since then (behaviors, before and after messages, script-only stacks, etc.) 
> that it would be very helpful to hear your concerns as I prepare to dive into 
> my archives for the old notes
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> 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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

 
I'm going blind here, eyes burning with the app contents open to the LC 8 
application folder and looking at the 100's of .rev, .livecodescript and 
.livecode files.

So here's a thought experiment and me thinking outloud for this actual project 
in front of me.

Starting at square 1  

The script only stacks have zero "auto presence" path wise... relative to any 
.livecode stack  

Later you will need to explicitly find it (OK.. I know.. too obvious but let's 
declare it anyway)

on mouseUp
put specialFolderPath("Resources") into tMyHomePath
start using stack ( tMyHomePath & "/" 
&"libraries/CoreTextfieldFunctions.livecode") 
#all things readable in fields
checkPath ("Yes, i Got It.")
End mouseUp

I tried to find where the revIDE stacks were setting up their root default 
folder but could not find it.

Looking for patterns we see e.g. 

/contents/Tools/Toolset/Libraries
/contents/Tools/Toolset/palettes
      /behaviors
      /dictionary
      /inspector
          /behaviors
          /editors

with .rev and .livecode stacks here and there.

I need a nap to absorb and create a picture of the incredible number of 
separate files in the IDE!

Though ""Everything is true, Everything is Permitted" one way is obvious -- use 
 the MVC model for the thought experiment -- this assumes one has had the 
discipline to draft a relatively complete functional specification for your app 
ahead of time... of course in AGILE mode this could change but you need to 
start somewhere. 

You have two classes of code: 

1) Code that serves as underlying end point of messages from coming from the 
views (mouse down/up swipes, taps typing, clicking)... pertains to the "back 
end" ...    then we organize by folders that relate to function.  Let;s use the 
RevIgniter core as an example.. and quite possibly this is adaptable to any 
given app.

config
controllers 
    # presumably you segregate the traffic cops here
    # but don't mix in more complex functions
cronjobs
db
errors
helpers
hooks
index.html # could be "MyApp.livecode"
language
libraries
models
plugins
stacks
views

2) Code that pertains directly to the presentation layer itself, main stack, 
substacks that are binary.livecode stacks, cards and controls. and they that 
the user actually sees and interacts with. Code that actually dynamically 
builds or manipulates the GUI... 

So these you can organize along the lines of your functional specification 
"Views" seems a reasonable uber way to think about it.
though perhaps "stacks" is enough and better term, since from HC days a stack 
is what we see (though now we have that line blurred with script-only stacks)

/stacks/
   home screen
   portals (navigation screens)
   user-account
   user Settings
   favorites
   readers # text displays, reading books, quotes
   web-browers # for cards with the browser widget
   my-exercises # exercise tracker or whatever
   image-puzzles # some game
   etc.
   assets
     /fonts
     /img
        stack-wide
        portals
        my-exercises
        image-puzzles.

Inside those folders, following on the LC teams patterns, you segregate 
behaviors from libraries, by criteria I have yet to fully grok.  I'll be 
looking into the msg path after that nap and possibly that will clarify things. 

That's a small beginning, I hope. perhaps we can find broad classes that work 
everywhere for #1 set of code above.. that would be ideal. Though I expect 
because of the "anything is permitted" law... it may also be somewhat subject 
depending on your style?

Comments?

BR
        
   
 

On March 29, 2016 at 10:58:48 AM, Richard Gaskin 
(ambassa...@fourthworld.com(mailto:ambassa...@fourthworld.com)) wrote:

> William Prothero wrote:  
>  
> > Organizing the code in a project is really important and there are lots of 
> > ways to go wrong.  
>  
> Can you describe some?  
>  
> While documenting good patterns can be useful, sometimes documenting  
> anti-patterns is just as useful.  
>  
> Several years ago at one of the LC conferences in Monterey Ken Ray and I  
> did a talk called "LiveCode Patterns and Anti-Patterns". So much has  
> changed since then (behaviors, before and after messages, script-only  
> stacks, etc.) that it would be very helpful to hear your concerns as I  
> prepare to dive into my archives for the old notes  
>  
> --  
> Richard Gaskin  
> Fourth World Systems  
> Software Design and Development for the Desktop, Mobile, and the Web 
___
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: Script Only Stack Architecture

[Richard Gaskin]

William Prothero wrote:


Organizing the code in a project is really important and there are lots of ways 
to go wrong.


Can you describe some?

While documenting good patterns can be useful, sometimes documenting 
anti-patterns is just as useful.


Several years ago at one of the LC conferences in Monterey Ken Ray and I 
did a talk called "LiveCode Patterns and Anti-Patterns".  So much has 
changed since then (behaviors, before and after messages, script-only 
stacks, etc.) that it would be very helpful to hear your concerns as I 
prepare to dive into my archives for the old notes


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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: Script Only Stack Architecture

[Earthednet-wp]

I second this. Organizing the code in a project is really important and there 
are lots of ways to go wrong.
Bill

William Prothero
http://es.earthednet.org

> On Mar 29, 2016, at 12:26 PM, Sannyasin Brahmanathaswami  
> wrote:
> 
> Ahh... so code that has object level scope should be e.g.
> 
> "tiny-little-nav-buttons.livecodescript"
> 
> That is set as the behavior for  those buttons?
> 
> and code that has things like  "getLocalAppPath()"
> 
> should be in " start using stack "coreAppFunctions.livecodescript"
> 
> Is that what you mean?
> 
> @ Mark, Monte, Peter (brett)  if you are inspired   -- a tutorial on 
> "building an app from scratch, using the script-only modular approach to the 
> max."  as a video tutorial or something would be fantastic...
> 
> ala the old "sheep herder" video that Ben did. It doesn't have to be 
> complicated or too long... just point us in the right direction.
> 
> I'll start testing, hacking today, but for newbies who are coming from Ruby, 
> Python, PHP, JS CSS etc... such a tutorial would make a lot of sense... -- 
> how all the pieces fit together... @Mark, you blog post was great... take it 
> one step further!
> 
> Like if you create a substack it is saved automatically in the binary, but if 
> I am in an app in the IDE and create a script only stack.. will it be 
> automatically loaded later when I reboot my app in the IDE? OR do we need to 
> manually script the "start using" those stacks, even though we created them 
> in the app just like a substack?  and what is the engine's scope for finding 
> them? Pathwise: does it automatically look for the script only stack in the 
> default folder and is that for the LC engine? or the folder that contains the 
> stack that from which the script only stack was created?  Or should we set up 
> some folders in that ala the JS apps or PHP ... functions, core, 
> object-behaviors  etc. where script are stored and then in the app we 
> explicity have a function to find those libraries/behaviors script-only stacks
> 
> Of course I'm going to figure all this out in the next few hours, but it 
> would be great if it were "tutorialized."
> 
> And, since LC team has been doing this already for some time... best 
> practices guide would be ideal. I've been studying Google Material Design 
> docs and impressed by the level of "instruction" they give for best 
> practices.  it's pretty awesome...   Someday, something like that for LC, 
> created by all you LC wizards would be
> 
> a) really give a leg up for a generation of "code only programmers" who might 
> like to adopt LC
> b) help us do it right from the beginning.
> 
> yeah, I know "coding is easy, documention is hard (smile)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On March 28, 2016 at 5:55:42 PM, Monte Goulding 
> (mo...@appisle.net) wrote:
> 
> Yes, it was the mix of code that should have an object scope and code that 
> was fine to have a application wide scope that I was commenting on Matt.
> 
> Sent from my iPhone
> 
>> On 29 Mar 2016, at 2:46 PM, Richard Gaskin  
>> wrote:
>> 
>> Matt Maier wrote:
>> 
>>> Monte got annoyed that I did something like that instead of setting
>>> behaviors. So it might be better to write behaviors in script-only
>>> stacks and then set them onto the various controls, rather than
>>> managing the controls all the way from the library stack(s).
>> 
>> Behaviors are good. And so are libraries. They're not mutually exclusive.
>> 
>> "Nothing is true. Everything is permitted."
>> 
>> --
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for Desktop, Mobile, and Web
>> 
>> ambassa...@fourthworld.com http://www.FourthWorld.com
>> 
>> 
>> ___
>> 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

___
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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

Ahh... so code that has object level scope should be e.g.

 "tiny-little-nav-buttons.livecodescript"

 That is set as the behavior for  those buttons?

and code that has things like  "getLocalAppPath()"

should be in " start using stack "coreAppFunctions.livecodescript"

Is that what you mean?

@ Mark, Monte, Peter (brett)  if you are inspired   -- a tutorial on "building 
an app from scratch, using the script-only modular approach to the max."  as a 
video tutorial or something would be fantastic...

ala the old "sheep herder" video that Ben did. It doesn't have to be 
complicated or too long... just point us in the right direction.

I'll start testing, hacking today, but for newbies who are coming from Ruby, 
Python, PHP, JS CSS etc... such a tutorial would make a lot of sense... -- how 
all the pieces fit together... @Mark, you blog post was great... take it one 
step further!

Like if you create a substack it is saved automatically in the binary, but if I 
am in an app in the IDE and create a script only stack.. will it be 
automatically loaded later when I reboot my app in the IDE? OR do we need to 
manually script the "start using" those stacks, even though we created them in 
the app just like a substack?  and what is the engine's scope for finding them? 
Pathwise: does it automatically look for the script only stack in the default 
folder and is that for the LC engine? or the folder that contains the stack 
that from which the script only stack was created?  Or should we set up some 
folders in that ala the JS apps or PHP ... functions, core, object-behaviors  
etc. where script are stored and then in the app we explicity have a function 
to find those libraries/behaviors script-only stacks

Of course I'm going to figure all this out in the next few hours, but it would 
be great if it were "tutorialized."

And, since LC team has been doing this already for some time... best practices 
guide would be ideal. I've been studying Google Material Design docs and 
impressed by the level of "instruction" they give for best practices.  it's 
pretty awesome...   Someday, something like that for LC, created by all you LC 
wizards would be

a) really give a leg up for a generation of "code only programmers" who might 
like to adopt LC
b) help us do it right from the beginning.

yeah, I know "coding is easy, documention is hard (smile)









On March 28, 2016 at 5:55:42 PM, Monte Goulding 
(mo...@appisle.net) wrote:

Yes, it was the mix of code that should have an object scope and code that was 
fine to have a application wide scope that I was commenting on Matt.

Sent from my iPhone

> On 29 Mar 2016, at 2:46 PM, Richard Gaskin  wrote:
>
> Matt Maier wrote:
>
> > Monte got annoyed that I did something like that instead of setting
> > behaviors. So it might be better to write behaviors in script-only
> > stacks and then set them onto the various controls, rather than
> > managing the controls all the way from the library stack(s).
>
> Behaviors are good. And so are libraries. They're not mutually exclusive.
>
> "Nothing is true. Everything is permitted."
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for Desktop, Mobile, and Web
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
>
> ___
> 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: Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

 
On March 28, 2016 at 4:01:47 PM, Matt Maier 
(bluebac...@gmail.com(mailto:bluebac...@gmail.com)) wrote:
> Monte got annoyed that I did something like that instead of setting  
> behaviors. So it might be better to write behaviors in script-only stacks  
> and then set them onto the various controls, rather than managing the  
> controls all the way from the library stack(s).  


I'm clearly out of my depth.
.. and not even sure I "grok" the difference

GUI --> Button "Start"-->  

on mouse
initiateGameSequence 
#being a command in a script only stack/library
end mouse

What is the "behavior" way of doing it? and why is it better?

BR

___
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: Script Only Stack Architecture

[Monte Goulding]

Yes, it was the mix of code that should have an object scope and code that was 
fine to have a application wide scope that I was commenting on Matt.

Sent from my iPhone

> On 29 Mar 2016, at 2:46 PM, Richard Gaskin  wrote:
> 
> Matt Maier wrote:
> 
> > Monte got annoyed that I did something like that instead of setting
> > behaviors. So it might be better to write behaviors in script-only
> > stacks and then set them onto the various controls, rather than
> > managing the controls all the way from the library stack(s).
> 
> Behaviors are good.  And so are libraries.  They're not mutually exclusive.
> 
> "Nothing is true. Everything is permitted."
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for Desktop, Mobile, and Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> 
> ___
> 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: Script Only Stack Architecture

[Richard Gaskin]

Matt Maier wrote:

> Monte got annoyed that I did something like that instead of setting
> behaviors. So it might be better to write behaviors in script-only
> stacks and then set them onto the various controls, rather than
> managing the controls all the way from the library stack(s).

Behaviors are good.  And so are libraries.  They're not mutually exclusive.

"Nothing is true. Everything is permitted."

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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: Script Only Stack Architecture

[Matt Maier]

Monte got annoyed that I did something like that instead of setting
behaviors. So it might be better to write behaviors in script-only stacks
and then set them onto the various controls, rather than managing the
controls all the way from the library stack(s).
On Mar 28, 2016 18:54, "Sannyasin Brahmanathaswami" 
wrote:

> Yay! my GUI designs are in from the eye candy team so we can start cooking.
>
> I'm looking closely at script only stacks.
>
> Mark's blog was simple enough "They are just text files."
>
> I've installed Atom here.
>
>  Can you check/amend my assumptions here? Of course I can test this
> myself, but if others are already doing this kind of architecture you may
> have caveats to share?
>
> Atom:
> -  Create a project pointing to a folder  with your current app assets
> - place this under GIT control
>
> -- A "main" stack with a preopenstack handler like this
>
> on preopenstack
>  start using "animationEngine" # assume binary substack imported
>  Start using # any other binary helper stacks
>  start using "myAppCoreFunctions.livecodescript" # script only stack
>  start using "mAppPuzzleGames.livecodescript" # script only stack
> # etc.
> end preopenstack
>
> -- with almost no code in the stack stack script at all.
> -- in the project browser we will see the script only stacks
> -- we can edit the script only stacks in the script editor set break
> points use the "console"  (put to msg box)
> -- when we hit "apply" in the script editor the scripts are saved back out
> to the text files
> -- OR the modified scripts of the script only stacks are in RAM until you
> save the main stack?
> -- Buttons and top level messages go through and hit the
> functions/commands loaded in the script
>
> In Atom or from command line, you then make your commits to the repository.
>
> Seems simple enough...Anything I am missing? additions or amendments.
>
> Meanwhile I'm going to "go for it" and see how it goes.
>
>
> ___
> 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

Script Only Stack Architecture

[Sannyasin Brahmanathaswami]

Yay! my GUI designs are in from the eye candy team so we can start cooking.

I'm looking closely at script only stacks.

Mark's blog was simple enough "They are just text files."

I've installed Atom here.

 Can you check/amend my assumptions here? Of course I can test this myself, but 
if others are already doing this kind of architecture you may have caveats to 
share?

Atom:
-  Create a project pointing to a folder  with your current app assets
- place this under GIT control

-- A "main" stack with a preopenstack handler like this

on preopenstack
 start using "animationEngine" # assume binary substack imported
 Start using # any other binary helper stacks
 start using "myAppCoreFunctions.livecodescript" # script only stack
 start using "mAppPuzzleGames.livecodescript" # script only stack
# etc.
end preopenstack

-- with almost no code in the stack stack script at all.
-- in the project browser we will see the script only stacks
-- we can edit the script only stacks in the script editor set break points use 
the "console"  (put to msg box)
-- when we hit "apply" in the script editor the scripts are saved back out to 
the text files
-- OR the modified scripts of the script only stacks are in RAM until you save 
the main stack?
-- Buttons and top level messages go through and hit the functions/commands 
loaded in the script

In Atom or from command line, you then make your commits to the repository.

Seems simple enough...Anything I am missing? additions or amendments.

Meanwhile I'm going to "go for it" and see how it goes.


___
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