Re: Difficulty using Livecode.com

[Tore Nilsen]

If you want to access the app building course you should click on your name in 
the upper right corner of the web page (when you are logged in). You will then 
find a link to the app building course in the menu to the left of the new page 
which contains various information about your lisences.

Tore

> 1. apr. 2016 kl. 03.24 skrev Jim Byrnes :
> 
> As a new user I sometimes find Livecode.com difficult to use.  Generally 
> speaking I find some parts of it not very intuitive. Specifically I had this 
> problem:
> 
> [1] I go to Livecode.com and click on the Get Started button.
> 
> [2] That takes me here: https://livecode.com/download/. Since I have already 
> downloaded Livecode, I fill out my firstname and email and click the Get 
> Started button.
> 
> [3] I am informed (correctly) that this email is already associated with a 
> Livecode account, log in (here) instead. So I click (here) and go here: 
> https://livecode.com/download/ and log in.
> 
> [4] Then I am taken to here: http://livecode.com/account/products/livecode. 
> At this point I am wondering why I was not taken back to the getting started 
> page to move on in the app building tutorial.
> 
> [5] Not sure what I should do at this point. I go back to livecode.com.
> I fill out the form again and click the get started button and receive the 
> same message about logging in, but I just logged in and the site seems to 
> know I am logged in because my name is displayed in the upper right hand 
> corner.
> 
> Maybe the page is only for people that do not have an account, but sending a 
> person that has an account on an endless loop leads to a frustrating 
> experience.
> 
> Of course maybe I am misunderstanding something about the site, if so I would 
> appreciate someone showing me where I went wrong.
> 
> Regards,  Jim
> 
> 
> ___
> 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: Difficulty using Livecode.com

[Richard Gaskin]

Jim, you're my new hero.  Everyone has all sorts of opinions about the 
web site, but you took the time to document your journey through the 
taxonomy, noting each specific step.  Well done.


It may seem like basic stuff and it is.  But of course the site at 
passed review when it was posted, so it seems link rot set in along the 
way with other changes.  Your detailed steps will be very helpful in 
getting that resolved.


I've forwarded your notes to the web designer, who will no doubt review 
them with great interest as they continue their site refinements in 
anticipation of the v8 launch.


If just want to get started with a download, use the Download links to 
take you here:

http://downloads.livecode.com/livecode/

Thanks again for your notes.

--
 Richard Gaskin
 Fourth World Systems


Jim Byrnes wrote:

As a new user I sometimes find Livecode.com difficult to use.  Generally
speaking I find some parts of it not very intuitive. Specifically I had
this problem:

[1] I go to Livecode.com and click on the Get Started button.

[2] That takes me here: https://livecode.com/download/. Since I have
already downloaded Livecode, I fill out my firstname and email and click
the Get Started button.

[3] I am informed (correctly) that this email is already associated with
a Livecode account, log in (here) instead. So I click (here) and go
here: https://livecode.com/download/ and log in.

[4] Then I am taken to here:
http://livecode.com/account/products/livecode. At this point I am
wondering why I was not taken back to the getting started page to move
on in the app building tutorial.

[5] Not sure what I should do at this point. I go back to livecode.com.
I fill out the form again and click the get started button and receive
the same message about logging in, but I just logged in and the site
seems to know I am logged in because my name is displayed in the upper
right hand corner.

Maybe the page is only for people that do not have an account, but
sending a person that has an account on an endless loop leads to a
frustrating experience.

Of course maybe I am misunderstanding something about the site, if so I
would appreciate someone showing me where I went wrong.

Regards,  Jim



___
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: PDF text extraction?

[Alejandro Tejada]

Hi Richard,

Could you use command line tools like pdftk or qpdf?

Check this:
http://stackoverflow.com/questions/15058207/pdftk-will-not-decompress-data-streams

and this:

https://books.google.com.do/books?id=ozWeSBkPQW4C=PA205=PA205=uncompress+and+save+pdf+streams=bl=9LyTX9eHMe=nmvt8iXLCF5NTNpBEQQJadGbR34=en=X=0ahUKEwjQpPuFpezLAhUHlh4KHffsBSUQ6AEITzAI#v=onepage=uncompress%20and%20save%20pdf%20streams=false



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/PDF-text-extraction-tp4702906p4702911.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: Difficulty using Livecode.com

[Jim Kanter]

Depending on what you want to do, I'd suggest clicking on the
Resources menu item at the top of the home page. Or you can use this
link:

https://livecode.com/resources/

Hope this helps.

Jim

On Thu, Mar 31, 2016 at 9:24 PM, Jim Byrnes  wrote:
> As a new user I sometimes find Livecode.com difficult to use.  Generally
> speaking I find some parts of it not very intuitive. Specifically I had this
> problem:
>
> [1] I go to Livecode.com and click on the Get Started button.
>
> [2] That takes me here: https://livecode.com/download/. Since I have already
> downloaded Livecode, I fill out my firstname and email and click the Get
> Started button.
>
> [3] I am informed (correctly) that this email is already associated with a
> Livecode account, log in (here) instead. So I click (here) and go here:
> https://livecode.com/download/ and log in.
>
> [4] Then I am taken to here: http://livecode.com/account/products/livecode.
> At this point I am wondering why I was not taken back to the getting started
> page to move on in the app building tutorial.
>
> [5] Not sure what I should do at this point. I go back to livecode.com.
> I fill out the form again and click the get started button and receive the
> same message about logging in, but I just logged in and the site seems to
> know I am logged in because my name is displayed in the upper right hand
> corner.
>
> Maybe the page is only for people that do not have an account, but sending a
> person that has an account on an endless loop leads to a frustrating
> experience.
>
> Of course maybe I am misunderstanding something about the site, if so I
> would appreciate someone showing me where I went wrong.
>
> Regards,  Jim
>
>
> ___
> 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

Difficulty using Livecode.com

[Jim Byrnes]

As a new user I sometimes find Livecode.com difficult to use.  Generally 
speaking I find some parts of it not very intuitive. Specifically I had 
this problem:


[1] I go to Livecode.com and click on the Get Started button.

[2] That takes me here: https://livecode.com/download/. Since I have 
already downloaded Livecode, I fill out my firstname and email and click 
the Get Started button.


[3] I am informed (correctly) that this email is already associated with 
a Livecode account, log in (here) instead. So I click (here) and go 
here: https://livecode.com/download/ and log in.


[4] Then I am taken to here: 
http://livecode.com/account/products/livecode. At this point I am 
wondering why I was not taken back to the getting started page to move 
on in the app building tutorial.


[5] Not sure what I should do at this point. I go back to livecode.com.
I fill out the form again and click the get started button and receive 
the same message about logging in, but I just logged in and the site 
seems to know I am logged in because my name is displayed in the upper 
right hand corner.


Maybe the page is only for people that do not have an account, but 
sending a person that has an account on an endless loop leads to a 
frustrating experience.


Of course maybe I am misunderstanding something about the site, if so I 
would appreciate someone showing me where I went wrong.


Regards,  Jim


___
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: [OT] World Backup Day

[Alejandro Tejada]

Good question...

I have only backups of Documents,
not System Images.



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/OT-World-Backup-Day-tp4702892p4702908.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

[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

PDF text extraction?

[Richard Gaskin]

I may need to extract text from a fair number of PDFs (hundreds).  I can 
find all sorts of third-party tools to do that, many of them free and 
easy to use, but I'd prefer to integrate this step into some other 
things I need to do with the files.


The format isn't as simple as Word or docx, though.  I'm not even sure 
if we have support in LC for the compression used in the text streams. 
Lots of parts there.


Anyone here have a library or external for extracting text from PDFs? 
Ideally a good solution would be available for Win, Mac, and Linux.


TIA -

--
 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 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: Design Challenge -- Round Corner mask on images

[Alejandro Tejada]

Great! :D

Now the big question :D

Who volunteer to build (and maintain) a plug-in 
(palette or modeless stack) that explains and 
create the many ways of masking an image:

1) Group with an image and graphic
(using inks effects)

2) Image and graphic or
Image and Transparent Image
(using snapshot)

3) Image and grahic
(using backpattern and script)

Just one more thing: 
In the "About" card of this
plug-in, post links to each
one of these threads from
the mail list and forum.

Thanks in advance!

Alejandro





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Design-Challenge-Round-Corner-mask-on-images-tp4702659p4702904.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

need your ios app approved in a hurry?

[Mark Wieder]

Here's the generator:

http://www.elasticode.com/dear-apple.php

--
 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: Using LC for Interactive Tutorial

[Alejandro Tejada]

This is Amazing! :D

Just a few questions:

Does this new feature offers a method to display custom stacks
that execute messages and display animations?

Could we use this new feature in our own stacks and applications?

When are we going to see an interactive tutorial that
explains how to create interactive tutorials? :-)

Alejandro




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Using-LC-for-Interactive-Tutorial-tp4702865p4702902.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

[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: Multiple Versions of LC on Mac

[Sannyasin Brahmanathaswami]

Thanks Jacque:

I'm not using 6... but might want to send someone  a stack done in 8  but they 
are only using 7

or not:

the new jsonLib on board is a valuable addition and if we use it, then anyone 
touching the stack will need 8/16 (still very unstable, but fortunately doesn't 
break anything)


On March 31, 2016 at 11:00:54 AM, J. Landman Gay 
(jac...@hyperactivesw.com) wrote:

I almost always have at least 3 versions of LC running at once, and
sometimes more. You don't need to quit them to alternate.
___
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: Design Challenge -- Round Corner mask on images

[BNig]

Alejandro Tejada wrote
> By the way, just to complete in this same thread all masking options
> available, here is a recipe for using Scott Rossi's Hidden Point technique
> to mask an image:
> http://runtime-revolution.278305.n4.nabble.com/Hidden-point-technique-to-mask-an-image-td2270248.html
> 
> A graphic with discontiguous points is just another way to create a vector
> mask.
> 
> 1) Create a new stack
> 2) Create a polygon graphic
> and set the points of it to:
> 
> 0,0
> 
> 34,268
> 224,268
> 127,365
> 34,268
> 
> 3) import an image into this stack,
> put the image in a corner, where it does not
> hide the graphic and:
> 
> set the backpattern of grc 1 to the id of img 1
> 
> (now, the imported image is cropped within
> the graphic)
> 
> 4) set the script of the graphic to this variation
> of Scott Rossi script to move the first point of
> the graphic and (at the same time) move the
> image within the graphic:
> Alejandro


Hi Alejandro,

thanks for the script. Again Scott found a neat trick!

here is a slight adaption of your version that avoids that you wander off
into the wrong direction and the image becomes unresponsive.

--
local lpoints,tClick,tFirstPoint 
-- based on Scott Rossi script for masking images 
local sMinX, sMinY

on mouseDown 
   put mouseH(),mouseV() into tClick 
   put the points of me into lpoints 
   put line 1 of lpoints into tFirstPoint
   put line 2 to - 1 of lpoints into tPointLIst
   filter tPointList without ""
   sort tPointList numeric ascending by item 1 of each
   put item 1 of line 1 of tPointList into sMinX
   sort tPointList numeric ascending by item 2 of each
   put item 2 of line 1 of tPointLIst into sMinY
   put "mouseDown" & cr & lpoints & cr & cr into fld 1 
end mouseDown 

on mouseMove X,Y 
   if tClick = "" then exit mouseMove 
   put  (X - item 1 of tClick,Y - item 2 of tClick) 
   put  (X - item 1 of tClick) + item 1 of tFirstPoint,(Y - item 2 of
tClick) + item 2 of tFirstPoint into line 1 of lpoints
   if item 1 of line 1 of lpoints > sMinX then put sMinX into item 1 of line
1 of lpoints
   if item 2 of line 1 of lpoints > sMinY then put sMinY into item 2 of line
1 of lpoints
   set the points of me to lpoints 
end mouseMove 

on mouseUp 
   put "" into tClick 
end mouseUp 

on mouseRelease 
   put "" into tClick 
end mouseRelease 
--

as usual watch for linebreaks.

Kind regards
Bernd



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Design-Challenge-Round-Corner-mask-on-images-tp4702659p4702898.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: Multiple Versions of LC on Mac

[Scott Rossi]

You can run multiple versions simultaneously -- I often run multiple
versions side by side, and copy scripts/objects between versions.
Settings can be an issue if you're going to have different locations for
extensions, etc -- not sure if the LiveCode people made accommodations for
that.

But an efficient way to work that has suggested on the mail list many
times is, if you use Dropbox or some other cloud sharing service, to place
your LC Extensions folder there. Set all versions of LC on the machine to
reference that folder, but also set up LC on other systems to reference
that same folder.  You will then have your plugins and utility stacks
available consistently across all systems.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 3/31/16, 1:44 PM, "use-livecode on behalf of Sannyasin
Brahmanathaswami"  wrote:

>The read me notes on LC 8 say
>
>"Each version of LiveCode installs to its own, separate folder, to allow
>multiple versions of LiveCode to be installed side-by-side."
>
>Just to confirm:
>
>If we maintain all these in the applications folder (on mac)
>
>LiveCode Indy 7.5.app
>LiveCode Indy 8.0.0 (dp 16).app
>LiveCode Indy 8.0 (dp 15).app
>
>etc.
>
>and be sure to close anyone of them before using another...
>are we getting ourselves into trouble at all, does this affect the
>preferences?
>
>Of course we  would need to "save stack with format version" to run in
>7... and features not available 8 disappear e.g. use of new json lib.
>
>Any other caveats?
>
>
>___
>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

[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: Multiple Versions of LC on Mac

[J. Landman Gay]

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


If we maintain all these in the applications folder (on mac)

LiveCode Indy 7.5.app
LiveCode Indy 8.0.0 (dp 16).app
LiveCode Indy 8.0 (dp 15).app

etc.

and be sure to close anyone of them before using another...
are we getting ourselves into trouble at all, does this affect the preferences?

Of course we  would need to "save stack with format version" to run in 7... and 
features not available 8 disappear e.g. use of new json lib.

Any other caveats?


I almost always have at least 3 versions of LC running at once, and 
sometimes more. You don't need to quit them to alternate. The main 
caveat is that if you have the same stack open in more than one version, 
you have to remember which version you saved it in. If you forget, 
you're apt to overwrite the changes you made in one copy of LC with 
changes you made in a different copy. The best thing is not to open the 
same stack in more than one version at a time.


Right now I have a client project open in 7.1.3, a partially-finished 
test stack open in 7.1.1, and a "learning/tinkering" stack open in 
8.0dp16. For a long time I also kept 6.6.5 open for a project that 
needed it. I sort of use copies of LC the way some people use 
desktops/spaces.


LC loads preferences on startup. You can change preferences in any 
version at any time, but whichever one you quit first will be the prefs 
you get when you launch any other copy of LC. While they are all 
running, they're just using the prefs they loaded when they launched.


LC 6 has a different prefs file than LC 7 and up, so if you're still 
running 6 then changing its prefs won't affect higher versions of LC.


--
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

[OT] World Backup Day

[Richard Gaskin]

Today is World Backup Day - do you have multiple redundant backups with 
a tested recovery plan?


http://www.worldbackupday.com/en/

--
 Richard Gaskin
 Fourth World Systems

___
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

Multiple Versions of LC on Mac

[Sannyasin Brahmanathaswami]

The read me notes on LC 8 say

"Each version of LiveCode installs to its own, separate folder, to allow 
multiple versions of LiveCode to be installed side-by-side."

Just to confirm:

If we maintain all these in the applications folder (on mac)

LiveCode Indy 7.5.app
LiveCode Indy 8.0.0 (dp 16).app
LiveCode Indy 8.0 (dp 15).app

etc.

and be sure to close anyone of them before using another...
are we getting ourselves into trouble at all, does this affect the preferences?

Of course we  would need to "save stack with format version" to run in 7... and 
features not available 8 disappear e.g. use of new json lib.

Any other caveats?


___
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:

> 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

LiveCode Video Display with QuickTime on a PC ?

[stgoldb...@aol.com]

The stack should run on PC. Be sure the movie filename is correctly prepared as 
a relative path, not an absolute path. E.g.:

set the filename of player 1 to “Images/MyMovie.mov”

Also, be sure the movie is correctly placed hierarchically. If for instance the 
movie MyMovie is in a folder titled "Images" and the stack is in a folder 
titled MyStack, the Images folder should be in the MyStack folder.

Stephen Goldberg, Pres
Medmaster Inc
www.medmaster.net

>Is there anything else I shold know ? LiveCode information concerning
>video display with QT on a PC is very vague. I?m running V 5.5.
___
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: Android Internet Library OpenSSL version problem

[panagiotis merakos]

Hi Todd,

We have updated the OpenSSL version to 1.0.1s, and the patch will be
included in the next LiveCode release (6.7.11-rc-1 / 7.1.4-rc-1 .
8.0.0-dp-17).

Best regards,
Panos
--

On Thu, Mar 31, 2016 at 10:03 PM, Todd Fabacher  wrote:

> Here is the email
>
>
> Hello Google Play Developer,
>
> Your app(s) listed at the end of this email utilize a version of OpenSSL
> that contains one or more security vulnerabilities. If you have more than
> 20 affected apps in your account, please check the Developer Console
> <
> https://www.google.com/appserve/mkt/p/fjei2Ep_bOBlYuDc6w9bmNJq7yf2tJoxDhZCISvC3oPBU402G0KdpugkDbaYNCNfFe5Krmc=
> >
> for
> a full list.
>
> *Please migrate your app(s) to OpenSSL 1.02f/1.01r or higher as soon as
> possible and increment the version number of the upgraded APK.* Beginning
> July 11, 2016, Google Play will block publishing of any new apps or updates
> that use older versions of OpenSSL. If you’re using a 3rd party library
> that bundles OpenSSL, you’ll need to upgrade it to a version that bundles
> OpenSSL 1.02f/1.01r or higher.
>
> The vulnerabilities were addressed in OpenSSL 1.02f/1.01r. The latest
> versions of OpenSSL can be downloaded here
> <
> https://www.google.com/appserve/mkt/p/cYEKsNY1EXxMUibx1g5wXFqEUJug2qxAljz5dcjw0FdtOCzzVgES3UnVMg3NZzg=
> >.
> To confirm your OpenSSL version, you can do a grep search for ($ unzip -p
> YourApp.apk | strings | grep "OpenSSL").
>
> To confirm you’ve upgraded correctly, submit the updated version to the
> Developer Console and check back after five hours. If the app hasn’t been
> correctly upgraded, we will display a warning.
>
> The vulnerabilities include "logjam
> <
> https://www.google.com/appserve/mkt/p/wwzjM8dOQQABsjZHsmizCbtZBSy8QLOCS_zC_JwDzZFu8t3E
> >"
> and CVE-2015-3194
> <
> http://www.google.com/appserve/mkt/p/5Fet4eNQpubmLcdcsDLDxQVC3cpQIobX-ZpnUbOEzQ-ef8eBEX8b3UwbW-2vkf0uOl4MxDC_ybcHvx-9tuf2bvBKMB1VVG-jISB4iU8SW3IZDl956lVV1NcKOGImM_eDDfVPYU7DHSCeP6NAKczWI21Zwhb26nmp1L7at28gjcE=
> >.
> The Logjam attack allows a man-in-the-middle attacker to downgrade
> vulnerable TLS connections to 512-bit export-grade cryptography. This
> allows the attacker to read and modify any data passed over the connection.
> Details about other vulnerabilities are available here
> <
> https://www.google.com/appserve/mkt/p/SaM0ZeGJS3KDm1_UVkqSocD06axb2Pnx2R11VGhz5ztJQm6xXXC69LkUGxikh7zJ2dtHtGx5iOgP9RIJjcHKsfY=
> >.
> For other technical questions, you can post to Stack Overflow
> <
> https://www.google.com/appserve/mkt/p/eMKFo3KVNtsXJIz_0hnZoToX-cCMUIa3k-i9378x7adhWusHjYDL83SZltgBexcJz0z-o_wtJh0=
> >
> and
> use the tags “android-security” and “OpenSSL.”
>
> While these specific issues may not affect every app that uses OpenSSL,
> it’s best to stay up to date on all security patches. Apps with
> vulnerabilities that expose users to risk of compromise may be considered
> in violation of our Malicious Behavior policy
> <
> https://www.google.com/appserve/mkt/p/8Ke0G-Rjrwg2kyNAeVDUbN-PtGFFtm0XwcheZ2wPcRjpI-4yIcgkVmqu_o7W8H3w320ruNzsFnZ5FixHl7DH5uUdtapHi5ZFg_iDtWKQrzqSmvgWhgQEjBeOQQ==
> >
> and
> section 4.4
> <
> https://www.google.com/appserve/mkt/p/J66OFIBf3DgWBKNfQlTjy5x6M2_SVA1zJopao2l5WkqBG5pKvFHNIi1_lvTYpP-Fk6QzgzQ4loBrQyIR6D6zfqLPoFqA4KPgLNnhOoCZz1DZ9c9vfHwvA3JYPTs6DRE=
> >
> of
> the Developer Distribution Agreement.
> ___
> 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]

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: Android Internet Library OpenSSL version problem

[Todd Fabacher]

Here is the email


Hello Google Play Developer,

Your app(s) listed at the end of this email utilize a version of OpenSSL
that contains one or more security vulnerabilities. If you have more than
20 affected apps in your account, please check the Developer Console

for
a full list.

*Please migrate your app(s) to OpenSSL 1.02f/1.01r or higher as soon as
possible and increment the version number of the upgraded APK.* Beginning
July 11, 2016, Google Play will block publishing of any new apps or updates
that use older versions of OpenSSL. If you’re using a 3rd party library
that bundles OpenSSL, you’ll need to upgrade it to a version that bundles
OpenSSL 1.02f/1.01r or higher.

The vulnerabilities were addressed in OpenSSL 1.02f/1.01r. The latest
versions of OpenSSL can be downloaded here
.
To confirm your OpenSSL version, you can do a grep search for ($ unzip -p
YourApp.apk | strings | grep "OpenSSL").

To confirm you’ve upgraded correctly, submit the updated version to the
Developer Console and check back after five hours. If the app hasn’t been
correctly upgraded, we will display a warning.

The vulnerabilities include "logjam
"
and CVE-2015-3194
.
The Logjam attack allows a man-in-the-middle attacker to downgrade
vulnerable TLS connections to 512-bit export-grade cryptography. This
allows the attacker to read and modify any data passed over the connection.
Details about other vulnerabilities are available here
.
For other technical questions, you can post to Stack Overflow

and
use the tags “android-security” and “OpenSSL.”

While these specific issues may not affect every app that uses OpenSSL,
it’s best to stay up to date on all security patches. Apps with
vulnerabilities that expose users to risk of compromise may be considered
in violation of our Malicious Behavior policy

and
section 4.4

of
the Developer Distribution Agreement.
___
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: Design Challenge -- Round Corner mask on images

[Alejandro Tejada]

Hi Richmond,


RM wrote
> Am I being stupid?

No, this same topic (masking images) have been discussed many times before. 
An this same topic will arise again in a near future. Do you know why?

Because LC IDE does not have an integrated menu or an external palette or a
stack plug-in to create mask for images.

2011 in the forums:
http://forums.livecode.com/viewtopic.php?f=10=6525
2013 in the mail list:
http://lists.runrev.com/pipermail/use-livecode/2013-October/subject.html#193880

By the way, just to complete in this same thread all masking options
available, here is a recipe for using Scott Rossi's Hidden Point technique
to mask an image:
http://runtime-revolution.278305.n4.nabble.com/Hidden-point-technique-to-mask-an-image-td2270248.html

A graphic with discontiguous points is just another way to create a vector
mask.

1) Create a new stack
2) Create a polygon graphic
and set the points of it to:

0,0

34,268
224,268
127,365
34,268

3) import an image into this stack,
put the image in a corner, where it does not
hide the graphic and:

set the backpattern of grc 1 to the id of img 1

(now, the imported image is cropped within
the graphic)

4) set the script of the graphic to this variation
of Scott Rossi script to move the first point of
the graphic and (at the same time) move the
image within the graphic:

local lpoints,tClick,tFirstPoint
-- based on Scott Rossi script for masking images

on mouseDown
   put mouseH(),mouseV() into tClick
   put the points of me into lpoints
   put line 1 of lpoints into tFirstPoint
   put "mouseDown" & cr & lpoints & cr & cr into fld 1 
end mouseDown

on mouseMove X,Y
   if tClick = "" then exit mouseMove
   put  (X - item 1 of tClick,Y - item 2 of tClick)
   put  (X - item 1 of tClick) + item 1 of tFirstPoint,(Y - item 2 of
tClick) + item 2 of tFirstPoint into line 1 of lpoints
   set the points of me to lpoints
end mouseMove

on mouseUp
   put "" into tClick
end mouseUp

on mouseRelease
   put "" into tClick
end mouseRelease

When you click inside the graphic and move the mouse
the image will move within the graphic.

Alejandro




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Design-Challenge-Round-Corner-mask-on-images-tp4702659p4702879.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

Android Internet Library OpenSSL version problem

[Todd Fabacher]

I LiveCode going to upgrade the Internet Lib? Google sent out messages to
everyone in the app store:

*Please migrate your app(s) to OpenSSL 1.02f/1.01r or higher as soon as
possible and increment the version number of the upgraded APK.*

Our build manager say they will start rejecting Apps. Can we do anything
now? We have Apps that need to go into the store.

--Todd
___
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: LiveCode Video Display with QuickTime on a PC ?

[panagiotis merakos]

*If* I remember, correctly, the default value of the global dontuseQT is
false on Windows (and true on OSX>=10.8).

However, note that QT is not officially supported on Windows 8.1 and 10. It
is quite possible that it will "just work", but not guaranteed.

From Apple's website (https://support.apple.com/kb/DL837?locale=en_US):

***Please note: QuickTime 7 is for use with Windows Vista or Windows 7. If
installed on other versions of Windows, it may not offer full functionality
and is unsupported. ***

If you convert all the video files to .AVI then they should display as
expected (of course make sure that dontUseQT is set to true), but you will
not be able to use the controller for video playback, since this feature is
specific to QuickTime.

I suggest converting one video to .AVI and see if it works, and if not,
please file a bug report.

Best regards,

Panos

--



On Thu, Mar 31, 2016 at 8:43 PM, J. Landman Gay 
wrote:

> Also remember to set the dontUseQT to false. The default has changed, and
> QT won't load now unless you tell it to do so.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
>
>
> On March 31, 2016 12:28:11 PM Mark Talluto 
> wrote:
>
>
>> On Mar 31, 2016, at 9:40 AM, Francis Nugent Dixon 
>>> wrote:
>>>
>>> If I install Quicktime (Version 7) on the PC, what do I have to do to
>>> allow it to run the videos , or is it transparent, as with Mac OS ?
>>> If (as I have read) QT doesn’t run well on a PC, if I convert all the
>>> video files to .AVI (using Windows Live Movie Maker ?), will video
>>> display then work properly ? Obviously, I prefer QuickTime …..
>>>
>>
>> If you install QT on a PC, the player control will work the same on the
>> PC as it does on the Mac.
>>
>> Best regards,
>>
>> Mark Talluto
>> livecloud.io 
>> canelasoftware.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: LiveCode Video Display with QuickTime on a PC ?

[J. Landman Gay]

Also remember to set the dontUseQT to false. The default has changed, and 
QT won't load now unless you tell it to do so.


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



On March 31, 2016 12:28:11 PM Mark Talluto  wrote:




On Mar 31, 2016, at 9:40 AM, Francis Nugent Dixon  wrote:

If I install Quicktime (Version 7) on the PC, what do I have to do to
allow it to run the videos , or is it transparent, as with Mac OS ?
If (as I have read) QT doesn’t run well on a PC, if I convert all the
video files to .AVI (using Windows Live Movie Maker ?), will video
display then work properly ? Obviously, I prefer QuickTime …..


If you install QT on a PC, the player control will work the same on the PC 
as it does on the Mac.


Best regards,

Mark Talluto
livecloud.io 
canelasoftware.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

[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: LiveCode Video Display with QuickTime on a PC ?

[Mark Talluto]

> On Mar 31, 2016, at 9:40 AM, Francis Nugent Dixon  wrote:
> 
> If I install Quicktime (Version 7) on the PC, what do I have to do to
> allow it to run the videos , or is it transparent, as with Mac OS ?
> If (as I have read) QT doesn’t run well on a PC, if I convert all the
> video files to .AVI (using Windows Live Movie Maker ?), will video
> display then work properly ? Obviously, I prefer QuickTime …..

If you install QT on a PC, the player control will work the same on the PC as 
it does on the Mac.

Best regards,

Mark Talluto
livecloud.io 
canelasoftware.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 

!

[Mark Waddingham]

On 2016-03-31 18:06, Richard Gaskin wrote:

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.


Well, that 'anomaly' is basically about the fact that custom property 
set syntax is 'the wrong way round' (in some sense) to allow arbitrarily 
nested [] on custom properties to work. If custom property sets had 
never existed, and you just had custom properties, then we could have 
had:


  the foo of tObject - the foo custom property
  the foo["bar"] of tObject - the bar key of the (array valued) foo 
custom property
  the foo["bar"]["baz"] of tObject - the baz key of the bar key of the 
(array valued) foo custom property


However, what we have is:

  the foo of tObject - the foo custom property
  the foo["bar"] of tObject - the bar custom property in the foo custom 
property set


The second form here is very different from the second form above. This 
is a bit of a shame really, as it would have been much easier to think 
about if we could have made the equivalence:


  the foo[a]...[z] of tObject === (the foo of tObject)[a]...[z]


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?


Well, implementation-wise, the 'default custom property set' is the 
custom property set with name 'empty'; and internally each object has a 
linked list of named custom property sets. Each custom property set does 
and always had the same representational power as a LiveCode variable. 
So when nested arrays were added, custom properties gained the ability 
to hold arrays too. Since 7, all a custom property set is is a (name, 
array) pair, where the array part maps custom property names in that set 
to their values.



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


Well, there was a fair bit of sorcery involved way back when nested 
arrays were added as we wanted to try and squeeze them into the file 
format without breaking backwards compatibility.


However, the principal motivation (if I remember correctly, at least - 
we are going back many many years here) for arrayEncoding was to enable 
custom property sets to serialize array values.


Anyway, to summarise, when in memory a custom property set is just an 
array (which is looked up in a linked list by name) - this array maps 
custom property names to values. When written out to disk (in 7+ format 
- pre-6.7 format had to do horrendous things which I never want to have 
to look at again) each custom property set is serialized as the name 
followed by the arrayEncoding of the array.


Hopefully that all makes sense...

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

LiveCode Video Display with QuickTime on a PC ?

[Francis Nugent Dixon]

Hi from Beautiful Brittany,

I’m confused - I want to create a PC version of a stack which plays
videos (external) on demand. The files are either .mov or .mp4.
The stack works perfectly on my Mac, but when I run it on a PC
the video display will not work (no QT).  So I have questions :

If I install Quicktime (Version 7) on the PC, what do I have to do to
allow it to run the videos , or is it transparent, as with Mac OS ?
If (as I have read) QT doesn’t run well on a PC, if I convert all the
video files to .AVI (using Windows Live Movie Maker ?), will video
display then work properly ? Obviously, I prefer QuickTime …..

Is there anything else I shold know ? LiveCode information concerning
video display with QT on a PC is very vague. I’m running V 5.5.

Thanks

-Francis
___
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]

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

Screen Resolution Dialog problem with Windows 10

[Charles Szasz]

An user reported seeing a screen resolution dialog in one of my programs that 
requests a screen resolution of 1024x768 be used. The problem is that  the user 
reportedly is using a screen resolution of 1920x1080.   She is using Windows 
10. 

I am using LC 6.1.2 and use the following code in my app stack:

on checkForScreenSize
   
   IF the platform is "win32" 
   then
  if item 3 of the screenRect < 1024 or item 4 of the screenRect < 768 then
 answer error "The Assistant software requires a minimum 1024x768 
screen resolution. Please check your Control Panel." with "OK"
 quit 
  end if
   end if
   
   if the platform = "MacOS"
   then
  if item 3 of the screenRect < 1024 or item 4 of the screenRect < 768 then
 answer error "The Assistant software requires a minimum 1024x768 
screen resolution. Please check your Display Preferences." with "OK"
 quit
  end if
   end if
  
end checkForScreenSize

Has anybody encountered this problem with Windows 10?

Charles Szasz
csz...@mac.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

Using LC for Interactive Tutorial

[Heather Laine]

Dear List folk,

Really cool blog post from Ali today:

https://livecode.com/livecode-interactive-tutorials/ 


Find out how to write your own interactive tutorial using the building blocks 
Ali has provided.

Warm Regards,

Heather

Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.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

[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: IMG resize advice wanted

[tbodine]

Thanks for elaborating on that, James. 



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/IMG-resize-advice-wanted-tp4702682p4702862.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

[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 

AW: Are there any cumulative release notes?

[Tiemo Hollmann TB]

Hi Richard,
thanks for your helpful explanations and the links
Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Richard Gaskin
Gesendet: Mittwoch, 30. März 2016 17:05
An: use-livecode@lists.runrev.com
Betreff: Re: Are there any cumulative release notes?

Tiemo Hollmann wrote:

 > I have this "failed to load external" failure and am searching, what  >
might have changed between LC 6 and 7/8, because all settings are the  >
same between my versions, but with LC 7/8 I can't load my externals  >
anymore.
 >
 > I am sure there must have been changed something very obvious, what I  >
don't see. I started to read the release notes, but that is pretty  >
cumbersome to read every single DP release note from 6.7. upward to  > look
for a relevant change on handling externals and I don't even  > have all
intermediate version installed.
 >
 > Are there any kind of "cumulative release notes" or a better approach  >
to look for the source of my problem.

In general the Release Notes for a given feature version (X.X, as opposed to
what is usually a bug-fix-only version X.X.X) will include all aggregate
notes from earlier builds in that series.

For example, the Release Notes for the latest Stable release, 7.1.3, include
changes going back to 7.1.0 (see the "Specific bug fixes" 
section at the bottom of each Release Notes PDF).

I believe this aggregation by feature version strikes a practical balance
between requiring too many Release Notes and having Release Notes too
cumbersomely long to be read.  After all, if they were aggregated with
previous feature releases where would the relevant cutoff be?  The document
could become as large as the install itself.

In your case, since the issue is evident in both v7 and v8 you may not need
to review v8 Release Notes at all.  And since there have been only two
significant releases of v7 (7.0 and 7.1) you should only need to review the
Release Notes for the latest build of each:




--
  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: Using Behaviors for Triggering UI Design - Run Time

[Peter M. Brigham]

On Mar 30, 2016, at 9:53 AM, Richard Gaskin wrote:

> In all cases, once set a behavior is resolved to a "rugged long ID", a long 
> ID where the stack portion is changed from the full file path as we normally 
> find it to just the stack name, allowing portability.
> 
> For example:
> 
>   button id 1004 of cd id 1003 of stack "/home/rg/something/rsrc.livecode"
> 
> ...becomes:
> 
>   button id of cd id 1003 of stack "rsrc"
> 
> 
> So when using a stack as a behavior you can write:
> 
>   set the behavior of btn "Something" to the long id of stack "rsrc"
> 
> ...or even more simply, since stack names are already unique:
> 
>   set the behavior of btn "Something" to the name of stack "rsrc"

FWIW, here are some handlers that return these "rugged" object references.

-- Peter

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



getProp robustID
     a virtual property  
   -- getting the long id of a control can result in different values depending 
on
   --(a) where the stack is stored on the user's disk and
   --(b) which card is the currentcard when the property is fetched
   -- the robustID is consistent no matter what card is current
   --and no matter which folder the user has stored the stack in;
   -- format: button id 1039 of bkgnd id 1003 of stack "subStack1"
   --of stack "tMainStack"
   -- the robustID can be used as a complete object reference,
   --just like the long ID
   -- requires q()
   
   put the long id of the target into tLongID
   if not (there is a tLongID) then
  -- in case the group is not placed on the currentcard
  replace "group " with "bkgnd " in tLongID
  if not (there is a tLongID) then
 return "robustID: no such object." -- error
  end if
   end if
   replace " stack " with cr in tLongID
   put line -1 of tLongID into mainStackFileName
   replace quote with empty in mainStackFileName
   put the short name of stack mainStackFileName into mainStackName
   put q(mainStackName) into line -1 of tLongID
   replace cr with "stack " in tLongID
   replace " of " with cr in tLongID
   put lineoffset(cr & "card ",cr & tLongID) into cdLineNbr
   if cdLineNbr > 1 then delete line cdLineNbr of tLongID
   replace cr with " of " in tLongID
   return tLongID
end robustID

getProp robustName
     a virtual property  
   -- getting the long name of a control can result in different values 
depending on
   --(a) where the stack is stored on the user's disk and
   --(b) which card is the currentcard when the property is fetched
   -- the robustName is consistent no matter what card is current
   --and no matter which folder the user has stored the stack in;
   -- format: button "copyText" of bkgnd "fieldGp" of stack "substack1"
   --of stack "myMainStack"
   -- the robustName can be used as a complete object reference,
   --just like the long name
   -- requires q()
   
   put the long name of the target into tLongName
   if not (there is a tLongName) then
  -- in case the group is not placed on the currentcard
  replace "group " with "bkgnd " in tLongName
  if not (there is a tLongName) then
 return "robustName: no such object." -- error
  end if
   end if
   replace " stack " with cr in tLongName
   put line -1 of tLongName into mainStackFileName
   if the number of lines of tLongName = 1 then
  return the name of mainStackFileName
   end if
   replace quote with empty in mainStackFileName
   put the short name of stack mainStackFileName into mainStackName
   put q(mainStackName) into line -1 of tLongName
   replace cr with " stack " in tLongName
   replace " of " with cr in tLongName
   put lineoffset(cr & "card ", cr & tLongName) into cdLineNbr
   if cdLineNbr > 1 then delete line cdLineNbr of tLongName
   repeat with c = 1 to the number of lines of tLongName
  put line c to -1 of tLongName into ctrlName
  replace cr with " of " in ctrlName
  put the name of ctrlName into thisName
  put thisName into line c of tLongName
   end repeat
   replace cr with " of " in tLongName
   return tLongName
end robustName

function q pStr
   -- quote
   return quote & pStr & quote
end q


___
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: Design Challenge -- Round Corner mask on images

[RM]

Am I being stupid?

https://www.dropbox.com/s/ce57yiy7xj4k9j0/Round%20Corners.livecode.zip?dl=0

http://forums.livecode.com/viewtopic.php?f=10=26933

Richmond.

___
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: Design Challenge -- Round Corner mask on images

[BNig]

This works

set the backgroundpattern of grc 1 to 1004

as for "imageSource" -> from the dictionary:

"Specifies an image to be displayed in place of the specified character in a
field."

Kind regards
Bernd



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Design-Challenge-Round-Corner-mask-on-images-tp4702659p4702856.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: Design Challenge -- Round Corner mask on images

[RM]

Why does THIS not work:

 set the imageSource of graphic "ggg" to 1003

?

Richmond.

___
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: Design Challenge -- Round Corner mask on images

[BNig]

Alejandro Tejada wrote
> By the way, while looking for a script to convert a color in a mask,
> (for example: convert bright green color of an image to alphadata)
> I just found that Bernd already answer this Design Challenge, 
> back in 2011:
> 
> http://forums.livecode.com/viewtopic.php?f=10=6525
> 
> From this 5 years old thread, download his stack:
> alphaData.livecode.zip
> 
> Thankfully, working in these scripts unveiled
> a recent bug that was just confirmed:
> http://quality.livecode.com/show_bug.cgi?id=17257
> 
> Alejandro

And it unveiled another bug
http://quality.livecode.com/show_bug.cgi?id=17277
setting maskData changes imageData irreversibly. 

Setting AlphaData is reversible and OK.

Kind regards
Bernd



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Design-Challenge-Round-Corner-mask-on-images-tp4702659p4702854.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

Which stack hosts the externals in runtime?

[Tiemo Hollmann TB]

Hello,

with: put the externalPackages of stack "home" you can check in the IDE,
which externals are loaded.

 

I thought in runtime the externals would be loaded into the mainstack, so
that you could ask for: put the externalPackages of stack ""

But in my case this shows me just 1 out of 4 externals. How can I check, if
and which externals are loaded in runtime?

 

Thanks

Tiemo

 

 

___
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

AW: LC 8.0 DP16 Failed to load external

[Tiemo Hollmann TB]

SOLVED

Though I can't reproduce the error anymore, I am almost sure it was an
incompatible version of the revxml.dll or revzip.dll. I copied the latest
version of these dlls from the LC 8 program dir into my test environment and
now my LC 8.0 runtime starts without error.

Thanks
Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Tiemo Hollmann TB
Gesendet: Mittwoch, 30. März 2016 12:03
An: LiveCode User Liste senden 
Betreff: LC 8.0 DP16 Failed to load external

Hello,

after a long break I am testing LC 8.0 DP16, because I wanted to answer the
latest LC survey, if I still need LC 6

I am using two externals, which work in the IDE. For building the
standalone, these externals are selected in the standalone settings under
"script libraries" and the externals are in a folder "Externals", which
resides in the standalone directory.

When starting the standalone I get an "Initialization Error - failed to load
external". After OK the startup quits. No information, which external
couldn't be loaded.

With LC 6.7.8 and 7.1.1 the standalone is loaded without error and works.

Has there something been changed with loading externals in 8.0? Any idea
what is going wrong here, or what I could check for?

Thanks for any ideas

Tiemo

 

 

 

 

___
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