Re: how to refer to a custom prop that is a multidimensional array

[hh via use-livecode]

> N.C. wrote:
> What should I be doing?

There is a good tutorial
Step-By-Step Guides To Tasks In LiveCode - Custom Properties

http://lessons.livecode.com/m/4071/c/16763

___
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 - What linux do you recommend for older PCs?

[Richard Gaskin via use-livecode]

Matthias Rebbe wrote:

> I have here an old Asus EeePC 1000H which currently runs with Windows
> XP and which is not used very often.
> It has an Intel Atom N270 CPU, 1GB ram and a 160GB harddisk.
>
> What Linux OS do you recommend for this machine? Best would be, if it
> could be used also with Livecode.

I like Ubuntu, and as the leading desktop Linux it's a good choice for 
the wide range of support materials available.


But the Atom N270 isn't exactly new, and it wasn't a serious workhorse 
when it premiered in '08.  I like the chip, and have a nettop in my 
office still running with it even now; it collates and processes the 
feeds shown in LiveNet (among many other things, including being one of 
my Nextcloud servers, remote backup manager, occasional UI stress 
tester, and more).


Old machines can be very useful, esp. with a power-miser chip like the 
Atom line.  But you'll want to consider relative performance when 
choosing a distro, looking for one with minimal graphics requirements 
and not very taxing on the CPU.


I did a lot of reading about low-resource Linux distros a while back 
when I first converted my N270 box from Windows to Linux, and again a 
couple years ago.


Bottom line: Lubuntu.

It's a lightweight flavor of Ubuntu designed specifically for modest 
hardware.  It uses a very lean window manager and desktop environment 
that's more Windows-like than Ubuntu's Unity UI may be consider 
Mac-like, but it's quite usable and very stable.


There's also Xubuntu, and outside of Ubuntu derivatives many others. 
But few can match Lubuntu's lean system requirements.


And it comes with an extra bonus for LiveCode folks: Both Alejandro and 
myself are experienced using LiveCode in Lubuntu, so if you run into any 
snags you have at least two more sources of support. :)


Have fun.

--
 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: how to refer to a custom prop that is a multidimensional array

[Brian Milby via use-livecode]

put the cKweto["landscape"] of this stack into sLandscape
put sLandscape["height"] into ...

I don't think you can retrieve array elements like you were trying to do.
If I'm wrong, someone more versed will surely correct me soon enough though
:)

Thanks,
Brian

On Mon, Jan 22, 2018 at 11:36 PM Nicolas Cueto via use-livecode <
use-livecode@lists.runrev.com> wrote:

> My stack has a custom prop "cKweto" which has various elements. For now,
> elements (arrays?) are single. But next I want to add multidimensional
> elements (arrays?). The proble is I do not how to refer to those
> multidimendional elements, say within a button script.
>
> For single elements, no problem. E.g., a value (360) is returned when my
> script has:
>
> put the cKweto["height_landscape_default"] of this stack
>
> But when I try ...
> put the cKweto["landscape","height"] of this stack
> ... or
> put the cKweto["landscape"]["height"] of this stack
> .. no values are retrieved, even though I can see them in the Property
> Inspector.
>
> What should I be doing?
>
> Thank you.
>
> --
> Nicolas Cueto
> ___
> 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: resizing and rescaling an object: Is this math/logic ok?

[Brian Milby via use-livecode]

That stack was a demo/proof of concept that GM and PM could work on
Mobile.  Before LC9DP11, those script libraries were not available by
default when creating an app for iOS/Android.  The demo stack actually
includes the library code to make them work.  All of the movements/changes
to the controls is done via either GM or PM.  GM controlls the changes
based on the size of the device.  PM controlls the layout for the
orientation changes.

The default profile is "Master".  Even if you do rename it, the actual
property names will still refer to themselves as "Master" in the
background.  As long as the 2 globals are set properly, creating a new
profile is as simple as changing to it.  I will agree that working with
profiles in 8/9 are going to be much more difficult than in 7 since
everything has to be done via typed commands.

My demo has 3 profiles, but going forward I would not do it that way.  If
starting a new project, I would have the main aspect ratio that I wanted to
support retain the "Master" designation and only add one additional profile
for the other.  I would experiment with renaming the master profile.

Here was my general though process when setting up the demo.

First, I decided that I wanted it to work on a small iPhone.  I set my
stack up using those dimensions.  I placed all of the controls and used the
GM to make them resize/move as needed for other device sizes.  I always
(and only) saved the stack in the smallest configuration.  I was also sure
to save before doing any testing with resizing or switching/creating
profiles.

Make sure gRevAutoCreateProfiles is true and gRevProfileReadOnly is false
(these are global variables that control profile).

Issue "revSetCardProfile profileName" command to create/switch to a new
profile (assuming the stack you are working on is the top stack).  When you
first create the new card profile, all of the objects on the card will also
get the new profile.  If you add an object later, you may need to manually
add the profile to that object (for me it actually took several switches to
get it to "take")

At this point, any changes that you make to objects will be in the new
profile.  Switching back to master should take everything back to the way
it was before and will actually save the changes into the profile that you
left (assuming gRevProfileReadOnly is false).

I would also suggest reading the dictionary entries for everything in the
"profile library" association in LC9DP11.  Even if not using that version
to develop, some of those docs were tweaked for the DP11 release.

On Mon, Jan 22, 2018 at 7:06 PM Nicolas Cueto via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Brian Milby wrote:
>
> The GM avoids the cumulative error problem by storing positioning as fixed
> numbers in the GM custom properties.  It will either store absolute pixel
> positions or relative % of card dimension positions.  Positions are based
> on either a card edge or another control edge.  So for your situation, you
> would want to calculate the offset % for each side and then just use the
> new card dimensions to calculate the new control rect.
>
> Took days to figures out and test but that worked! Thank you, Brian.
>
> Thank you Brian too for your stack "MobileProfile", which I found on a
> forum thread
> <
> http://forums.livecode.com/viewtopic.php?f=7&t=30018&p=159472&hilit=full+screen+mobile#p159472
> >
> when
> searching for anything having to do with rescaling/resizing. That stack
> (which is way over my head), besides a source of ideas for resizing, was
> also my first introduction to "profiles".
>
> BTW and OTT, Brian, about your use of "profiles" in that stack, I was
> especially and idiotically mesmerized by how those three graphic objects
> become not only repositioned but colored in when in landscape profile, as
> oposed to transparent when in portrait profile. Not knowing diddly-squat
> about "profiles", I thought I might use LC's "Find & replace" to find
> somehow a refence (by object name or background color) to those three
> graphic objects, and thereby hit upon the contents of your stack's
> "profiles". But, like I say, diddly-squat. Perhaps a few pointers about
> "profiles", especially how they're used in "MobileProfile", when you have a
> few spare moments? Sorry to ask directly, but, as I say, how your stack
> works seems magical to these eyes.
>
> Anyway, thank you all for the help. Now, onto the other recaling problems,
> such as text size.
>
> --
> Nicolas Cueto
>
> On 20 January 2018 at 01:26, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > To demonstrate, the following formula:
> >
> > 5 * 3 * .5 * .66 = 4.95 (not 5)
> >
> > hence the need to store a base size and always work your math from that.
> >
> > Bob S
> >
> >
> > > On Jan 19, 2018, at 07:53 , Brian Milby via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >
> > > The calculations that you are making are sound, but as Ralph said,
> after
> > > repe

how to refer to a custom prop that is a multidimensional array

[Nicolas Cueto via use-livecode]

My stack has a custom prop "cKweto" which has various elements. For now,
elements (arrays?) are single. But next I want to add multidimensional
elements (arrays?). The proble is I do not how to refer to those
multidimendional elements, say within a button script.

For single elements, no problem. E.g., a value (360) is returned when my
script has:

put the cKweto["height_landscape_default"] of this stack

But when I try ...
put the cKweto["landscape","height"] of this stack
... or
put the cKweto["landscape"]["height"] of this stack
.. no values are retrieved, even though I can see them in the Property
Inspector.

What should I be doing?

Thank you.

--
Nicolas Cueto
___
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: The "Property Profile Pane" -- where's it gone to? -- or, should profiles be avoided completely?

[Brian Milby via use-livecode]

I'll tackle a couple of your questions:
- The profile pane that Jacque was referring to is located in the LiveCode
preferences (currently labeled "Property Profiles")
- The profile pane displayed in the Wiki is part of the Property Inspector
and is not available in LC8/9.
- Currently, profiles have to be created via commands in code (I used the
message box)
- I would not suggest the use of profiles to change languages (much better
to use custom properties or some other method to take care of that).  This
is the point Klaus was making.
- If you think that the Geometry Manager will work for your stack, Profiles
seem to be a good option to take care of handling a different layout based
on mobile device orientation.  The "Mobile Profile" demo that I put
together shows how this can work.
- When working with anything that has the ability to reposition controls
automatically, I strongly suggest that backups are made often (and multiple
copies kept).  This is both for custom resize handlers and GM/PM.

Thanks,
Brian

On Mon, Jan 22, 2018 at 9:22 PM Nicolas Cueto via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Did not know until a week ago anything about the concept of LC profiles, as
> in revSetCardProfile, revSetStackProfile, or revSetStackFileProfile.
>
> So, looked at the LC doc and found this: "You create a profile for an
> object, and give it a name, using the PROPERTY PROFILES PANE in the
> object's PROPERTY INSPECTOR."
>
> However, even with the example on the LC wiki of an image showing this pane
>  ,
> neither on Mac or Windows 8.1.8, and neither in the Property Inspector or
> any other LC menu couId see anything called PROPERTY PROFILES PANE or
> resembling what that image shows.
>
> Then, searching the LC forum, in the thread Creating property profiles
> <
> http://forums.livecode.com/viewtopic.php?f=7&t=18904&p=95314&hilit=property+profiles+pane#p95314
> >
> (2014.01.25),
> Jacque wrote "The "create profiles automatically" option is in LIVECODE
> PREFERENCE in the PROFILES PANE."
>
> However, not only does Jacque's profile pane look nothing like the Wiki
> image's, but the former only allows naming the "master profile" and has a
> checkbox for "Create profiles automatically".
>
> Is this a LC version problem? Or is it it simply that I don't know how to
> work with profiles?
>
> If the latter, I'd sure appreciate detailed examples of how to create a
> couple of profiles, and then implement them.
>
> On the other hand, in the LC forum thread Property Profiles and
> revSetStackFileProfile
> <
> http://forums.livecode.com/viewtopic.php?f=9&t=5234&p=23573&hilit=property+profile#p23573
> >
> (2010.04.23),
> Klaus warns against using profiles and instead use CustomProperties and
> CustomPropertySets. He even offers a sample stack
>  "CP-Sets1" (scroll down the
> page) showing how that works.
>
> So, my other question is, avoid profiles completely?
>
> --
> Nicolas Cueto
> ___
> 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

The "Property Profile Pane" -- where's it gone to? -- or, should profiles be avoided completely?

[Nicolas Cueto via use-livecode]

Did not know until a week ago anything about the concept of LC profiles, as
in revSetCardProfile, revSetStackProfile, or revSetStackFileProfile.

So, looked at the LC doc and found this: "You create a profile for an
object, and give it a name, using the PROPERTY PROFILES PANE in the
object's PROPERTY INSPECTOR."

However, even with the example on the LC wiki of an image showing this pane
 ,
neither on Mac or Windows 8.1.8, and neither in the Property Inspector or
any other LC menu couId see anything called PROPERTY PROFILES PANE or
resembling what that image shows.

Then, searching the LC forum, in the thread Creating property profiles

(2014.01.25),
Jacque wrote "The "create profiles automatically" option is in LIVECODE
PREFERENCE in the PROFILES PANE."

However, not only does Jacque's profile pane look nothing like the Wiki
image's, but the former only allows naming the "master profile" and has a
checkbox for "Create profiles automatically".

Is this a LC version problem? Or is it it simply that I don't know how to
work with profiles?

If the latter, I'd sure appreciate detailed examples of how to create a
couple of profiles, and then implement them.

On the other hand, in the LC forum thread Property Profiles and
revSetStackFileProfile

(2010.04.23),
Klaus warns against using profiles and instead use CustomProperties and
CustomPropertySets. He even offers a sample stack
 "CP-Sets1" (scroll down the
page) showing how that works.

So, my other question is, avoid profiles completely?

--
Nicolas Cueto
___
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: Crazy script-only stack question

[Mike Kerner via use-livecode]

I don't think age of the QR means anything except someone was ahead of
their time.  If the mothership suddenly says "aha" then we get "aha"

On Mon, Jan 22, 2018 at 6:30 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yeah, the five-liner is intended only as a way of implementing script-only
> stacks with behavior chaining in code rather than the engine (since that
> doesn't seem forthcoming. It seem many people are doing something very like
> this, at a basic level I'm just proposing that standardizing would be
> useful. But the next step would be to support something more robust than
> just "line 2 through -1 is the script of the stack". It wouldn't take much
> to be able to put much more of a project into source control. But I agree
> that there is far more need for the already-available source control of
> scripts.
>
> On Mon, Jan 22, 2018 at 12:56 PM, Sannyasin Brahmanathaswami via
> use-livecode  wrote:
>
> > Not barking up the wrong tree at all, with multi-stack apps very much in
> > the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> > not having and a RCS for the binary stacks themselves is a nuisance. But
> > your 5 liner doesn't solve that either.
> >
> > But how does creating a stack and setting it's script to a text file
> > different from adding a stack to your framework and then setting the
> > behavior of that stack to the text only script?
> >
> > Or put another way, what advantage would it have over the behavior of the
> > stack?  And since your newly created stack has no controls, those would
> all
> > need to be created by script and this is exactly what LiveCode provides:
> > WSIWG layout environment (albeit needs a lot of work to get to 2018
> > standards )
> >
> > A case can be made for treating the binary stacks as a "view" Typically
> > there is a split in the team between design and code. This is also
> > happening universally where designers are doing UI/UX prototypes in
> > InVision Or Zeplin.. (no code)  and push these over to the code team.
> >
> > We have such stacks in the SivaSivaApp. where there is almost no code in
> > the stack at all. We use "the target" …in the text only behavior stacks…
> > this is working pretty well as once the eye candy and UX is locked in, we
> > are not touching that too much, if anyone is, it's usually just one
> person,
> > so pulling and pushing the binary from GIT is not that big a deal…
> conflict
> > wise… of course if some others on the team *do* want to touch the UI,
> then
> > it gets messy
> >
> > BR
> >
> > On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> > use-livecode"  > use-livecode@lists.runrev.com> wrote:
> >
> > Is there any reason script-only stacks had to be implemented in the
> > engine?
> >
> > Is there any reason *not* to implement their equivalent in about five
> > lines
> > of code in the mainstack of a project? i.e.,
> >
> > on loadTextStack tFilePath
> > put url ("file:/" & tFilePath) into tStackData
> > put line 1 of tStackData into tStackName
> > create invisible stack tStackName
> > set the script of stack tStackName to line 2 to -1 of tStackData
> > send "openStack" to stack tStackName
> > end loadTextStack
> >
> > This would immediately fix the issue of chained behaviors, and allow
> > for
> > the incremental implementation of a far richer format for text-based
> > stack
> > storage, leading to gains in project-definition source control.
> >
> > Given that Bug 10275  > show_bug.cgi?id=10275> is
> > over five years and several versions old, am I barking up a tree with
> > this,
> > or making sense?
> >
> > with no clue,
> >
> > Geoff
> >
> > ___
> > 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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 - What linux do you recommend for older PCs?

[Mark Wieder via use-livecode]

On 01/22/2018 04:31 PM, Matthias Rebbe via use-livecode wrote:

Hi,

so this goes to the Linux experts on this list.

I have here an old Asus EeePC 1000H which currently runs with Windows XP and 
which is not used very often.
It has an Intel Atom N270 CPU, 1GB ram and a 160GB harddisk.

What Linux OS do you recommend for this machine? Best would be, if it could be 
used also with Livecode.
I am planning to give it away to someone here in the neighbourhood who just 
want to use it for some writing and “Livecoding”.

What do you think?


This is one of those religious questions.
Far be it from me to consider myself an 'expert', but...

The liner notes list four flavors of linux that are 'officially' 
supported. If you want to stay the most compatible with LiveCode I'd 
recommend going with Ubuntu 16 LTS. I supported Fedora at work until 
Gnome3 came along and messed up the desktop. I had some hiccups with 
LiveCode and Debian, which finally got resolved to a glibc version 
issue. But ask any three linux users and you'll get half a dozen 
different answers.


Be prepared to do some handholding. LiveCode and linux have a platonic 
relationship.


--
 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: resizing and rescaling an object: Is this math/logic ok?

[Nicolas Cueto via use-livecode]

Brian Milby wrote:

The GM avoids the cumulative error problem by storing positioning as fixed
numbers in the GM custom properties.  It will either store absolute pixel
positions or relative % of card dimension positions.  Positions are based
on either a card edge or another control edge.  So for your situation, you
would want to calculate the offset % for each side and then just use the
new card dimensions to calculate the new control rect.

Took days to figures out and test but that worked! Thank you, Brian.

Thank you Brian too for your stack "MobileProfile", which I found on a
forum thread

when
searching for anything having to do with rescaling/resizing. That stack
(which is way over my head), besides a source of ideas for resizing, was
also my first introduction to "profiles".

BTW and OTT, Brian, about your use of "profiles" in that stack, I was
especially and idiotically mesmerized by how those three graphic objects
become not only repositioned but colored in when in landscape profile, as
oposed to transparent when in portrait profile. Not knowing diddly-squat
about "profiles", I thought I might use LC's "Find & replace" to find
somehow a refence (by object name or background color) to those three
graphic objects, and thereby hit upon the contents of your stack's
"profiles". But, like I say, diddly-squat. Perhaps a few pointers about
"profiles", especially how they're used in "MobileProfile", when you have a
few spare moments? Sorry to ask directly, but, as I say, how your stack
works seems magical to these eyes.

Anyway, thank you all for the help. Now, onto the other recaling problems,
such as text size.

--
Nicolas Cueto

On 20 January 2018 at 01:26, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> To demonstrate, the following formula:
>
> 5 * 3 * .5 * .66 = 4.95 (not 5)
>
> hence the need to store a base size and always work your math from that.
>
> Bob S
>
>
> > On Jan 19, 2018, at 07:53 , Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > The calculations that you are making are sound, but as Ralph said, after
> > repeated changes it may end up "off".
> >
> > The type of positioning that you are doing is one of the things that the
> > current Geometry Manager (GM) Property Inspector (PI) will not allow
> (when
> > you resize a control, the left/top can only be fixed to the card edge and
> > not proportional).  But, the method that the GM uses is helpful to know.
> >
> > The GM avoids the cumulative error problem by storing positioning as
> fixed
> > numbers in the GM custom properties.  It will either store absolute pixel
> > positions or relative % of card dimension positions.  Positions are based
> > on either a card edge or another control edge.  So for your situation,
> you
> > would want to calculate the offset % for each side and then just use the
> > new card dimensions to calculate the new control rect.
>
>
> ___
> 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

OT - What linux do you recommend for older PCs?

[Matthias Rebbe via use-livecode]

Hi,

so this goes to the Linux experts on this list.

I have here an old Asus EeePC 1000H which currently runs with Windows XP and 
which is not used very often.
It has an Intel Atom N270 CPU, 1GB ram and a 160GB harddisk.

What Linux OS do you recommend for this machine? Best would be, if it could be 
used also with Livecode.
I am planning to give it away to someone here in the neighbourhood who just 
want to use it for some writing and “Livecoding”.

What do you think?

Regards,
Matthias
___
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: Crazy script-only stack question

[Geoff Canyon via use-livecode]

Yeah, the five-liner is intended only as a way of implementing script-only
stacks with behavior chaining in code rather than the engine (since that
doesn't seem forthcoming. It seem many people are doing something very like
this, at a basic level I'm just proposing that standardizing would be
useful. But the next step would be to support something more robust than
just "line 2 through -1 is the script of the stack". It wouldn't take much
to be able to put much more of a project into source control. But I agree
that there is far more need for the already-available source control of
scripts.

On Mon, Jan 22, 2018 at 12:56 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> Not barking up the wrong tree at all, with multi-stack apps very much in
> the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> not having and a RCS for the binary stacks themselves is a nuisance. But
> your 5 liner doesn't solve that either.
>
> But how does creating a stack and setting it's script to a text file
> different from adding a stack to your framework and then setting the
> behavior of that stack to the text only script?
>
> Or put another way, what advantage would it have over the behavior of the
> stack?  And since your newly created stack has no controls, those would all
> need to be created by script and this is exactly what LiveCode provides:
> WSIWG layout environment (albeit needs a lot of work to get to 2018
> standards )
>
> A case can be made for treating the binary stacks as a "view" Typically
> there is a split in the team between design and code. This is also
> happening universally where designers are doing UI/UX prototypes in
> InVision Or Zeplin.. (no code)  and push these over to the code team.
>
> We have such stacks in the SivaSivaApp. where there is almost no code in
> the stack at all. We use "the target" …in the text only behavior stacks…
> this is working pretty well as once the eye candy and UX is locked in, we
> are not touching that too much, if anyone is, it's usually just one person,
> so pulling and pushing the binary from GIT is not that big a deal… conflict
> wise… of course if some others on the team *do* want to touch the UI, then
> it gets messy
>
> BR
>
> On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> use-livecode"  use-livecode@lists.runrev.com> wrote:
>
> Is there any reason script-only stacks had to be implemented in the
> engine?
>
> Is there any reason *not* to implement their equivalent in about five
> lines
> of code in the mainstack of a project? i.e.,
>
> on loadTextStack tFilePath
> put url ("file:/" & tFilePath) into tStackData
> put line 1 of tStackData into tStackName
> create invisible stack tStackName
> set the script of stack tStackName to line 2 to -1 of tStackData
> send "openStack" to stack tStackName
> end loadTextStack
>
> This would immediately fix the issue of chained behaviors, and allow
> for
> the incremental implementation of a far richer format for text-based
> stack
> storage, leading to gains in project-definition source control.
>
> Given that Bug 10275  show_bug.cgi?id=10275> is
> over five years and several versions old, am I barking up a tree with
> this,
> or making sense?
>
> with no clue,
>
> Geoff
>
> ___
> 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: Crazy script-only stack question

[Geoff Canyon via use-livecode]

I agree that having the ability to use stacks (script-only in particular)
for behaviors is nice -- it lets developers easily put all their code under
source control. But the implementation is flawed, as we've discussed,
because it doesn't support (native, transparent) chaining of behaviors, and
so is a feature-deficient replacement for button behaviors.

In looking at the bug for this -- which is a year and a half old -- I
thought of the idea that app layout could also be under version control if
it, too, had text-based alternative. There's a bug for (roughly) that --
and it is over five years old. So what I'm suggesting is that it seems
unlikely that either of these issues will be fixed in the engine anytime
soon, and further that it doesn't necessarily have to be an engine change
that addresses it.

The code library to make this happen would be almost trivial to write an
MVP for. A simple format (I'd suggest JSON, but newline support seems to be
an issue) would allow starting with a really basic definition, just enough
to support stacks with scripts and properties, which would get us the
equivalent of script-only stacks with chained behaviors. Beyond that it
would quickly be possible to include cards, groups, and controls, with many
(most?) properties, in external files, and voila, source control over the
interface for many projects.

I'm probably under-thinking the complexity, and overthinking the
possibility/need, but I definitely want a standardized way of handling
chained behaviors in source control, and I'd hate to wait another year and
a half to get that one thing.

And: yeah, openstack is a bad idea for the initialization message. It would
be much better to use a custom message -- behaviorStack?

gc

On Mon, Jan 22, 2018 at 12:47 PM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Mon, Jan 22, 2018 at 2:20 PM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Is there any reason script-only stacks had to be implemented in the
> engine?
> >
>
> It is nice that you can store the scripts for controls in a UI stack
> alongside of the ui stack file. You just set the stackfiles property of the
> UI stack and then opening the UI stack opens up all of the behavior stacks
> that the UI stack requires without any extra effort on the part of the
> developer.
>
>
> > Is there any reason *not* to implement their equivalent in about five
> lines
> > of code in the mainstack of a project? i.e.,
>
>
> For some cases dispatching a message can be useful. I don't think I would
> use `openStack`, however, as that doesn't describe the event that is
> occurring. You are just loading the stack into memory. A script only stack
> can create a UI and may expect the `openStack` message to be dispatched at
> the proper time and in the proper sequence relative to other messages that
> are sent when actually opening a stack.
>
> I wouldn't load all of my script only stacks that way, however. I use
> script only stacks in a variety of ways. For libraryStacks they already get
> a `libraryStack` message. If I'm using them as behaviors for controls in a
> UI stack then they are automatically loaded by the engine for me as
> described above. In the majority of cases that doesn't require any extra
> work. In the Levure framework you can specify that a stack file will be use
> specifically as a behavior. In the case Levure will dispatch a
> `LoadBehavior` message to the stack and it can assign itself a behavior.
>
> My preference is for the ability to set a script only stack behavior in the
> script only stack itself.
>
> --
> Trevor DeVore
> ScreenSteps
> www.screensteps.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: Crazy script-only stack question

[Mike Kerner via use-livecode]

We are starting to get a bit afield, but as long as we are, the issues with
the layout editor bring us to the same place as the issues with the script
editor:  Why exert so much effort on the editor instead of writing plugins
for third-party OSS editors, that have a much larger user base and
developers who are actively working on them (and designers developing
interface elements and themes)?

On Mon, Jan 22, 2018 at 3:56 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> Not barking up the wrong tree at all, with multi-stack apps very much in
> the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> not having and a RCS for the binary stacks themselves is a nuisance. But
> your 5 liner doesn't solve that either.
>
> But how does creating a stack and setting it's script to a text file
> different from adding a stack to your framework and then setting the
> behavior of that stack to the text only script?
>
> Or put another way, what advantage would it have over the behavior of the
> stack?  And since your newly created stack has no controls, those would all
> need to be created by script and this is exactly what LiveCode provides:
> WSIWG layout environment (albeit needs a lot of work to get to 2018
> standards )
>
> A case can be made for treating the binary stacks as a "view" Typically
> there is a split in the team between design and code. This is also
> happening universally where designers are doing UI/UX prototypes in
> InVision Or Zeplin.. (no code)  and push these over to the code team.
>
> We have such stacks in the SivaSivaApp. where there is almost no code in
> the stack at all. We use "the target" …in the text only behavior stacks…
> this is working pretty well as once the eye candy and UX is locked in, we
> are not touching that too much, if anyone is, it's usually just one person,
> so pulling and pushing the binary from GIT is not that big a deal… conflict
> wise… of course if some others on the team *do* want to touch the UI, then
> it gets messy
>
> BR
>
> On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> use-livecode"  use-livecode@lists.runrev.com> wrote:
>
> Is there any reason script-only stacks had to be implemented in the
> engine?
>
> Is there any reason *not* to implement their equivalent in about five
> lines
> of code in the mainstack of a project? i.e.,
>
> on loadTextStack tFilePath
> put url ("file:/" & tFilePath) into tStackData
> put line 1 of tStackData into tStackName
> create invisible stack tStackName
> set the script of stack tStackName to line 2 to -1 of tStackData
> send "openStack" to stack tStackName
> end loadTextStack
>
> This would immediately fix the issue of chained behaviors, and allow
> for
> the incremental implementation of a far richer format for text-based
> stack
> storage, leading to gains in project-definition source control.
>
> Given that Bug 10275  show_bug.cgi?id=10275> is
> over five years and several versions old, am I barking up a tree with
> this,
> or making sense?
>
> with no clue,
>
> Geoff
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

Brian,
That can of worms is why I was thinking that a handler similar to
"libraryStack" might be appropriate - like "behaviorStack"


On Mon, Jan 22, 2018 at 5:02 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> A script only stack has no place to hold properties which is what setting
> behaviors uses to "remember". (correct me if I am wrong)
>
> Bob S
>
>
> > On Jan 20, 2018, at 16:43 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Well that's too bad for anyone who's currently using chained behaviors
> and
> > wants to use source control (i.e. convert to script-only stacks).
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Do script-only stacks support "chained" behaviors?

[Bob Sneidar via use-livecode]

A script only stack has no place to hold properties which is what setting 
behaviors uses to "remember". (correct me if I am wrong)

Bob S


> On Jan 20, 2018, at 16:43 , Geoff Canyon via use-livecode 
>  wrote:
> 
> Well that's too bad for anyone who's currently using chained behaviors and
> wants to use source control (i.e. convert to script-only stacks).


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

more unicode than you want

[Mark Wieder via use-livecode]

https://unicode-table.com/en/#control-character

I had no idea, for instance, there was a CJK character for sodomy.
Or a technical character for 'right angle with downwards zigzag arrow'

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

[Bob Sneidar via use-livecode]

Not a biggie but I like to simply add 1 to tCounter at the top of the loop

-- put 1 into tCounter (don't need this here)
repeat for each line tLine in field "mm
add 1 to tCounter -- put it here instead. It creates the variable on the fly
switch (tLine is empty)
...

Bob S


> On Jan 21, 2018, at 08:35 , Mike Bonner via use-livecode 
>  wrote:
> 
> put 1 into tCounter
> repeat for each line tLine in field "mm
> switch (tLine is empty)


___
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: Do script-only stacks support "chained" behaviors?

[Brian Milby via use-livecode]

 To be more clear, after the BOM, the first word must be “script” followed
by a space and the stack name. The code to skip comment lines is not in the
source for .livecodescript files. This was adjusted when opening files with
a BOM over the internet was fixed.
On Mon, Jan 22, 2018 at 3:14 PM Brian Milby  wrote:

> First line comment is not legal for script only stacks.
> On Mon, Jan 22, 2018 at 1:29 PM Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> @Geoff, well, then my work here is done!
>> @Dr Hawk, do you mean in general?  That would require a change in LC, too,
>> and if we were going to do that, then I'd want it to be more LC-like,
>> perhaps with a handler.
>>
>> On Mon, Jan 22, 2018 at 1:28 PM, Dr. Hawkins via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> > On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
>> > use-livecode@lists.runrev.com> wrote:
>> >
>> > >
>> > > The way he suggested structuring the projects was putting the ui
>> elements
>> > > and their behaviors into /ui/stackName (and then the behaviors for
>> that
>> > > stack into /ui/stackName/behaviors/).
>> >
>> >
>> > How about something similar to the unix convention of  indicating the
>> shell
>> > to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
>> > comment?
>> >
>> > so the first line starting with, perhaps, "--#" would indicate that
>> what
>> > follows is an expression which evaluates to a button or other stack
>> that is
>> > to be the behavior of the stack?
>> >
>> > --
>> > Dr. Richard E. Hawkins, Esq.
>> > (702) 508-8462
>> > ___
>> > 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
>> >
>>
>>
>>
>> --
>> On the first day, God created the heavens and the Earth
>> On the second day, God created the oceans.
>> On the third day, God put the animals on hold for a few hours,
>>and did a little diving.
>> And God said, "This is good."
>> ___
>> 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: Do script-only stacks support "chained" behaviors?

[Brian Milby via use-livecode]

First line comment is not legal for script only stacks.
On Mon, Jan 22, 2018 at 1:29 PM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> @Geoff, well, then my work here is done!
> @Dr Hawk, do you mean in general?  That would require a change in LC, too,
> and if we were going to do that, then I'd want it to be more LC-like,
> perhaps with a handler.
>
> On Mon, Jan 22, 2018 at 1:28 PM, Dr. Hawkins via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > >
> > > The way he suggested structuring the projects was putting the ui
> elements
> > > and their behaviors into /ui/stackName (and then the behaviors for that
> > > stack into /ui/stackName/behaviors/).
> >
> >
> > How about something similar to the unix convention of  indicating the
> shell
> > to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
> > comment?
> >
> > so the first line starting with, perhaps, "--#" would indicate that  what
> > follows is an expression which evaluates to a button or other stack that
> is
> > to be the behavior of the stack?
> >
> > --
> > Dr. Richard E. Hawkins, Esq.
> > (702) 508-8462
> > ___
> > 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
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> 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: Crazy script-only stack question

[Sannyasin Brahmanathaswami via use-livecode]

Not barking up the wrong tree at all, with multi-stack apps very much in the 
wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_) not 
having and a RCS for the binary stacks themselves is a nuisance. But your 5 
liner doesn't solve that either.

But how does creating a stack and setting it's script to a text file different 
from adding a stack to your framework and then setting the behavior of that 
stack to the text only script?  

Or put another way, what advantage would it have over the behavior of the 
stack?  And since your newly created stack has no controls, those would all 
need to be created by script and this is exactly what LiveCode provides: WSIWG 
layout environment (albeit needs a lot of work to get to 2018 standards ) 

A case can be made for treating the binary stacks as a "view" Typically there 
is a split in the team between design and code. This is also happening 
universally where designers are doing UI/UX prototypes in InVision Or Zeplin.. 
(no code)  and push these over to the code team. 

We have such stacks in the SivaSivaApp. where there is almost no code in the 
stack at all. We use "the target" …in the text only behavior stacks… this is 
working pretty well as once the eye candy and UX is locked in, we are not 
touching that too much, if anyone is, it's usually just one person, so pulling 
and pushing the binary from GIT is not that big a deal… conflict wise… of 
course if some others on the team *do* want to touch the UI, then it gets messy

BR

On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via use-livecode" 
 wrote:

Is there any reason script-only stacks had to be implemented in the engine?

Is there any reason *not* to implement their equivalent in about five lines
of code in the mainstack of a project? i.e.,

on loadTextStack tFilePath
put url ("file:/" & tFilePath) into tStackData
put line 1 of tStackData into tStackName
create invisible stack tStackName
set the script of stack tStackName to line 2 to -1 of tStackData
send "openStack" to stack tStackName
end loadTextStack

This would immediately fix the issue of chained behaviors, and allow for
the incremental implementation of a far richer format for text-based stack
storage, leading to gains in project-definition source control.

Given that Bug 10275  is
over five years and several versions old, am I barking up a tree with this,
or making sense?

with no clue,

Geoff

___
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: Crazy script-only stack question

[Trevor DeVore via use-livecode]

On Mon, Jan 22, 2018 at 2:20 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Is there any reason script-only stacks had to be implemented in the engine?
>

It is nice that you can store the scripts for controls in a UI stack
alongside of the ui stack file. You just set the stackfiles property of the
UI stack and then opening the UI stack opens up all of the behavior stacks
that the UI stack requires without any extra effort on the part of the
developer.


> Is there any reason *not* to implement their equivalent in about five lines
> of code in the mainstack of a project? i.e.,


For some cases dispatching a message can be useful. I don't think I would
use `openStack`, however, as that doesn't describe the event that is
occurring. You are just loading the stack into memory. A script only stack
can create a UI and may expect the `openStack` message to be dispatched at
the proper time and in the proper sequence relative to other messages that
are sent when actually opening a stack.

I wouldn't load all of my script only stacks that way, however. I use
script only stacks in a variety of ways. For libraryStacks they already get
a `libraryStack` message. If I'm using them as behaviors for controls in a
UI stack then they are automatically loaded by the engine for me as
described above. In the majority of cases that doesn't require any extra
work. In the Levure framework you can specify that a stack file will be use
specifically as a behavior. In the case Levure will dispatch a
`LoadBehavior` message to the stack and it can assign itself a behavior.

My preference is for the ability to set a script only stack behavior in the
script only stack itself.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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

Crazy script-only stack question

[Geoff Canyon via use-livecode]

Is there any reason script-only stacks had to be implemented in the engine?

Is there any reason *not* to implement their equivalent in about five lines
of code in the mainstack of a project? i.e.,

on loadTextStack tFilePath
put url ("file:/" & tFilePath) into tStackData
put line 1 of tStackData into tStackName
create invisible stack tStackName
set the script of stack tStackName to line 2 to -1 of tStackData
send "openStack" to stack tStackName
end loadTextStack

This would immediately fix the issue of chained behaviors, and allow for
the incremental implementation of a far richer format for text-based stack
storage, leading to gains in project-definition source control.

Given that Bug 10275  is
over five years and several versions old, am I barking up a tree with this,
or making sense?

with no clue,

Geoff
___
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: Anyone using a third-party update tool for LC-originated desktop apps?

[Trevor DeVore via use-livecode]

On Mon, Jan 22, 2018 at 11:32 AM, Graham Samuel via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Trevor, this is great stuff! I will now study it very carefully. I
> absolutely agree that there should be some kind of standard solution
> offered to LC developers. I’ve been saying for a long time that deployment
> is really the big issue for developers who have signed up to, and wish to
> depend on, LiveCode.


Yes, deployment can be quite time consuming if you don't have an automated
process. For my uses cases Levure makes the process rather straight forward.


> Other topics under this heading include:
>
> - code signing;
>

Levure will take care of this on macOS (assuming you have your signing
certificate installed).


> - installer production
>

Levure has Helpers for DropDMG and Inno Setup. It can package up for the
Apple Store out of the box. When building on macOS a DMG can be created
using DropDMG. A file that can be loaded into Inno Setup can be created as
well. Inno Setup will sign your application when building the installer
(assuming you have your signing certificate installed on your Windows
machine).

https://github.com/trevordevore/levure/wiki/Building-Installers


> - uninstallers to get rid of hidden files (neither the Mac nor the Windows
> built-in uninstall processes do a good job, not sure about mobile)
>

Personally I don't worry about this on macOS. On Windows the uninstaller
create by Inno Setup can remove any files you specify in the Inno Setup
configuration file.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

@Geoff, well, then my work here is done!
@Dr Hawk, do you mean in general?  That would require a change in LC, too,
and if we were going to do that, then I'd want it to be more LC-like,
perhaps with a handler.

On Mon, Jan 22, 2018 at 1:28 PM, Dr. Hawkins via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > The way he suggested structuring the projects was putting the ui elements
> > and their behaviors into /ui/stackName (and then the behaviors for that
> > stack into /ui/stackName/behaviors/).
>
>
> How about something similar to the unix convention of  indicating the shell
> to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
> comment?
>
> so the first line starting with, perhaps, "--#" would indicate that  what
> follows is an expression which evaluates to a button or other stack that is
> to be the behavior of the stack?
>
> --
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Do script-only stacks support "chained" behaviors?

[Dr. Hawkins via use-livecode]

On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> The way he suggested structuring the projects was putting the ui elements
> and their behaviors into /ui/stackName (and then the behaviors for that
> stack into /ui/stackName/behaviors/).


How about something similar to the unix convention of  indicating the shell
to use in the first line of a text executable (e.g., #!/bin/tcsh ) as a
comment?

so the first line starting with, perhaps, "--#" would indicate that  what
follows is an expression which evaluates to a button or other stack that is
to be the behavior of the stack?

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: Anyone using a third-party update tool for LC-originated desktop apps?

[Graham Samuel via use-livecode]

Trevor, this is great stuff! I will now study it very carefully. I absolutely 
agree that there should be some kind of standard solution offered to LC 
developers. I’ve been saying for a long time that deployment is really the big 
issue for developers who have signed up to, and wish to depend on, LiveCode. 
Other topics under this heading include:

- code signing;
- installer production
- uninstallers to get rid of hidden files (neither the Mac nor the Windows 
built-in uninstall processes do a good job, not sure about mobile)
- workaround advice for users faced with aggressive anti-malware software that 
threatens to reject anything new
- uploading to servers using FTP clients

I’ve had to tackle all these, and I know there’s more, for example submission 
to the various app stores out there..

Anyway I’m about to start another chapter of my education!

Thanks again

Graham



> On 22 Jan 2018, at 16:06, Trevor DeVore via use-livecode 
>  wrote:
> 
> On Mon, Jan 22, 2018 at 5:04 AM, Graham Samuel via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Nowadays it’s customary for quite modest apps after launching to notify
>> the user of an update being available, with the possibility of carrying out
>> the update there and then, or refusing. A succession of dialog boxes guides
>> the user through the updating process and shows progress. The update
>> somehow bypasses the normal installation process, accepts existing license
>> data, and simply replaces the app. If the app has a document open, then the
>> new copy of the app re-opens it.
> 
> 
> Graham,
> 
> There are a lot of different approaches to this in the community. Here is
> my take on it. Currently I'm using the code in the following repository for
> automated updates. It is a Helper that I use with the Levure framework and
> I haven't documented it at all.
> 
> https://github.com/trevordevore/levurehelper-app_updater
> 
> It is a combination of Sparkle for macOS (Monte wrapped this up in an
> external for me) and LCS for Windows that I've been using over the years.
> Both macOS and Windows download an entirely new application. On macOS the
> app is zipped up and Sparkle downloads the zip archive, unzips it, and
> installs it. If the update requires authentication that is handled. On
> Windows the updater just downloads the Windows installer executable that is
> used for installing the app for the first time. This is an installer built
> using Inno Setup which will prompt the user for administrative permissions
> if need be.
> 
> I prefer to replace the entire application when I do updates. My apps are
> installed in a number of different environments. I would often get reports
> of problems when trying to update the app in pieces inside of corporations.
> Plus if you don't update the exe on Windows then the version number of your
> app won't be reported properly in the File Properties dialog. When I
> switched to downloading and running a full installer on Windows the reports
> of issues after running the updater dropped to 0.
> 
> In my ideal world the Windows side would use WinSparkle as it would be nice
> to leverage the work of a 3rd party. I like using code that is being tested
> by a lot of other people and which is entirely focused on automatic
> updates. I didn't want to create an external around it, however, so I've
> been waiting for the LCB to DLL interface in the engine to mature. I
> imagine WinSparkle could probably be wrapped using LCB now.
> 
> https://winsparkle.org
> 
> I would like to see the LC community have a standard automatic update
> solution available that is easy to use and is very reliable in all
> environments. To me it makes the most sense to leverage the work done by
> others who are focused on automatic update.
> 
> -- 
> Trevor DeVore
> ScreenSteps
> www.screensteps.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: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

I definitely considered that, but I put it off for 2.0.

On Mon, Jan 22, 2018 at 7:41 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> One of the things I was going to add to Scriptifier that it would be cool
> to have in Navigator is giving the user the option to change the naming
> convention/template, so for instance if I want spaces instead of
> underscores or I want to change the order of the components of the name I
> can.
>
> On Mon, Jan 22, 2018 at 10:28 AM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I'm leaving the "make a copy" step to the user (with a stern warning to
> do
> > so).
> >
> > I'm using the stack name, the control type, the control name, the control
> > id, and "Behavior" as the SoS name, something like:
> >
> > SoS_Test_Thing_2_button_Behavior_Source_1011_Behavior
> >
> > I think that alone guarantees uniqueness, but I'm also tracking:
> >
> > 1. The file names already in the folder
> > 2. All open stack names
> > 3. All created stacks as I do the conversion
> >
> > And if there is ever a collision, I use an indexing function to avoid it,
> > adding a 2, 3, 4, etc. if necessary. So I'm pretty confident there will
> be
> > no collisions.
> >
> > The user gets to select which controls to convert, so apart from the fact
> > that it's not trivial to select only controls with a behavior, I'm
> calling
> > it done for now on that front. There used to be a setting in Navigator to
> > show only objects with scripts, but (in the UI at least) that seems to
> have
> > gone away at some point. There is the filter command, and this works just
> > fine to show only objects with scripts or behaviors in the list:
> >
> > the behavior of tID is not empty or the script of tID is not empty
> >
> > On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > Geoff,
> > > Since Trevor didn't answer the Levure question,
> > > The way he suggested structuring the projects was putting the ui
> elements
> > > and their behaviors into /ui/stackName (and then the behaviors for that
> > > stack into /ui/stackName/behaviors/).  As for naming the stacks,
> > > Scriptifier does it one (long) way in an attempt to make all the names
> > > unique.  Trevor had suggested objectTypeobjectName"behavior",
> > but
> > > of course there is no reason why you would would have to be held to
> that.
> > >
> > > It's not that you can't have scripts all over the Levure project,
> because
> > > you will with libraries, components, etc. but those aren't the major
> > PITA,
> > > and that isn't what you're trying to address with Navigator.
> > >
> > > SO, if I was going to convert a stack automagically, I would want to
> > > 1) make a copy of the stackfile, placing it in the /ui/stackname folder
> > and
> > > work on the copy
> > > 2) pull the various behaviors and put them in the
> /ui/stackfile/behaviors
> > > folder
> > > From there, we can argue a lot about the structure of the behaviors
> > > folder.  On the one hand, if you keep everything in there together,
> then
> > > you can kind-of use the names to keep everything straight, because as
> > long
> > > as you don't change the names of the SOS's, it doesn't matter if you
> move
> > > the objects they are tied to from one card to another.  It's just that
> > the
> > > /behaviors folder can become the storage for hundreds of SOS's.  On the
> > > other, it might be good to give the developer an option to have
> > subfolders
> > > for each card, but as soon as they move an object from one card to
> > another
> > > you have a gigantic mess of the developer wanting the SOS's to move,
> but
> > > that will break the references, etc.
> > >
> > > I'm glad you're working on this!  Now I can stop thinking about working
> > on
> > > it and go do something else.
> > >
> > > On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > > > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> > > > use-livecode@lists.runrev.com> wrote:
> > > >
> > > > > It occurs to me that this isn't as much of a problem as I thought
> --
> > > any
> > > > > button being converted to a stack is highly unlikely to have an
> > > openstack
> > > > > handler already in it, and therefore it would be safe to add one
> and
> > > > > include setting the behavior of the script-only stack to the
> > > appropriate
> > > > > stack up the chain. If there were already an openstack handler in
> the
> > > > > chain, then the conversion process could stop at that point, or
> > perhaps
> > > > log
> > > > > the error to the user. Unless I'm missing something?
> > > >
> > > >
> > > > Geoff,
> > > >
> > > > Keep in mind that script only stacks that are loaded into memory by
> the
> > > > engine because they are referenced in the stackfiles of another stack
> > > won’t
> > > > be sent any messages.
> > > >
> > > > http://quality.livecode.c

Re: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

One of the things I was going to add to Scriptifier that it would be cool
to have in Navigator is giving the user the option to change the naming
convention/template, so for instance if I want spaces instead of
underscores or I want to change the order of the components of the name I
can.

On Mon, Jan 22, 2018 at 10:28 AM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'm leaving the "make a copy" step to the user (with a stern warning to do
> so).
>
> I'm using the stack name, the control type, the control name, the control
> id, and "Behavior" as the SoS name, something like:
>
> SoS_Test_Thing_2_button_Behavior_Source_1011_Behavior
>
> I think that alone guarantees uniqueness, but I'm also tracking:
>
> 1. The file names already in the folder
> 2. All open stack names
> 3. All created stacks as I do the conversion
>
> And if there is ever a collision, I use an indexing function to avoid it,
> adding a 2, 3, 4, etc. if necessary. So I'm pretty confident there will be
> no collisions.
>
> The user gets to select which controls to convert, so apart from the fact
> that it's not trivial to select only controls with a behavior, I'm calling
> it done for now on that front. There used to be a setting in Navigator to
> show only objects with scripts, but (in the UI at least) that seems to have
> gone away at some point. There is the filter command, and this works just
> fine to show only objects with scripts or behaviors in the list:
>
> the behavior of tID is not empty or the script of tID is not empty
>
> On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Geoff,
> > Since Trevor didn't answer the Levure question,
> > The way he suggested structuring the projects was putting the ui elements
> > and their behaviors into /ui/stackName (and then the behaviors for that
> > stack into /ui/stackName/behaviors/).  As for naming the stacks,
> > Scriptifier does it one (long) way in an attempt to make all the names
> > unique.  Trevor had suggested objectTypeobjectName"behavior",
> but
> > of course there is no reason why you would would have to be held to that.
> >
> > It's not that you can't have scripts all over the Levure project, because
> > you will with libraries, components, etc. but those aren't the major
> PITA,
> > and that isn't what you're trying to address with Navigator.
> >
> > SO, if I was going to convert a stack automagically, I would want to
> > 1) make a copy of the stackfile, placing it in the /ui/stackname folder
> and
> > work on the copy
> > 2) pull the various behaviors and put them in the /ui/stackfile/behaviors
> > folder
> > From there, we can argue a lot about the structure of the behaviors
> > folder.  On the one hand, if you keep everything in there together, then
> > you can kind-of use the names to keep everything straight, because as
> long
> > as you don't change the names of the SOS's, it doesn't matter if you move
> > the objects they are tied to from one card to another.  It's just that
> the
> > /behaviors folder can become the storage for hundreds of SOS's.  On the
> > other, it might be good to give the developer an option to have
> subfolders
> > for each card, but as soon as they move an object from one card to
> another
> > you have a gigantic mess of the developer wanting the SOS's to move, but
> > that will break the references, etc.
> >
> > I'm glad you're working on this!  Now I can stop thinking about working
> on
> > it and go do something else.
> >
> > On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > > > It occurs to me that this isn't as much of a problem as I thought --
> > any
> > > > button being converted to a stack is highly unlikely to have an
> > openstack
> > > > handler already in it, and therefore it would be safe to add one and
> > > > include setting the behavior of the script-only stack to the
> > appropriate
> > > > stack up the chain. If there were already an openstack handler in the
> > > > chain, then the conversion process could stop at that point, or
> perhaps
> > > log
> > > > the error to the user. Unless I'm missing something?
> > >
> > >
> > > Geoff,
> > >
> > > Keep in mind that script only stacks that are loaded into memory by the
> > > engine because they are referenced in the stackfiles of another stack
> > won’t
> > > be sent any messages.
> > >
> > > http://quality.livecode.com/show_bug.cgi?id=18223
> > >
> > > You have to complete the behavior chain in the openStack handler of the
> > > stack that is being opened. I think in your case you would process the
> > > openStack message in the stack you are setting the stackFiles on.
> > >
> > > Trevor DeVore
> > > ScreenSteps
> > >
> > > >
> > > ___
> > > use-livecode mailing list

Re: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

I'm leaving the "make a copy" step to the user (with a stern warning to do
so).

I'm using the stack name, the control type, the control name, the control
id, and "Behavior" as the SoS name, something like:

SoS_Test_Thing_2_button_Behavior_Source_1011_Behavior

I think that alone guarantees uniqueness, but I'm also tracking:

1. The file names already in the folder
2. All open stack names
3. All created stacks as I do the conversion

And if there is ever a collision, I use an indexing function to avoid it,
adding a 2, 3, 4, etc. if necessary. So I'm pretty confident there will be
no collisions.

The user gets to select which controls to convert, so apart from the fact
that it's not trivial to select only controls with a behavior, I'm calling
it done for now on that front. There used to be a setting in Navigator to
show only objects with scripts, but (in the UI at least) that seems to have
gone away at some point. There is the filter command, and this works just
fine to show only objects with scripts or behaviors in the list:

the behavior of tID is not empty or the script of tID is not empty

On Mon, Jan 22, 2018 at 6:10 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Geoff,
> Since Trevor didn't answer the Levure question,
> The way he suggested structuring the projects was putting the ui elements
> and their behaviors into /ui/stackName (and then the behaviors for that
> stack into /ui/stackName/behaviors/).  As for naming the stacks,
> Scriptifier does it one (long) way in an attempt to make all the names
> unique.  Trevor had suggested objectTypeobjectName"behavior", but
> of course there is no reason why you would would have to be held to that.
>
> It's not that you can't have scripts all over the Levure project, because
> you will with libraries, components, etc. but those aren't the major PITA,
> and that isn't what you're trying to address with Navigator.
>
> SO, if I was going to convert a stack automagically, I would want to
> 1) make a copy of the stackfile, placing it in the /ui/stackname folder and
> work on the copy
> 2) pull the various behaviors and put them in the /ui/stackfile/behaviors
> folder
> From there, we can argue a lot about the structure of the behaviors
> folder.  On the one hand, if you keep everything in there together, then
> you can kind-of use the names to keep everything straight, because as long
> as you don't change the names of the SOS's, it doesn't matter if you move
> the objects they are tied to from one card to another.  It's just that the
> /behaviors folder can become the storage for hundreds of SOS's.  On the
> other, it might be good to give the developer an option to have subfolders
> for each card, but as soon as they move an object from one card to another
> you have a gigantic mess of the developer wanting the SOS's to move, but
> that will break the references, etc.
>
> I'm glad you're working on this!  Now I can stop thinking about working on
> it and go do something else.
>
> On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > It occurs to me that this isn't as much of a problem as I thought --
> any
> > > button being converted to a stack is highly unlikely to have an
> openstack
> > > handler already in it, and therefore it would be safe to add one and
> > > include setting the behavior of the script-only stack to the
> appropriate
> > > stack up the chain. If there were already an openstack handler in the
> > > chain, then the conversion process could stop at that point, or perhaps
> > log
> > > the error to the user. Unless I'm missing something?
> >
> >
> > Geoff,
> >
> > Keep in mind that script only stacks that are loaded into memory by the
> > engine because they are referenced in the stackfiles of another stack
> won’t
> > be sent any messages.
> >
> > http://quality.livecode.com/show_bug.cgi?id=18223
> >
> > You have to complete the behavior chain in the openStack handler of the
> > stack that is being opened. I think in your case you would process the
> > openStack message in the stack you are setting the stackFiles on.
> >
> > Trevor DeVore
> > ScreenSteps
> >
> > >
> > ___
> > 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
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage

Re: Do script-only stacks support "chained" behaviors?

[Geoff Canyon via use-livecode]

That's disappointing.

On Mon, Jan 22, 2018 at 3:38 AM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
>
> Keep in mind that script only stacks that are loaded into memory by the
> engine because they are referenced in the stackfiles of another stack won’t
> be sent any messages.
>
> http://quality.livecode.com/show_bug.cgi?id=18223
>
> You have to complete the behavior chain in the openStack handler of the
> stack that is being opened. I think in your case you would process the
> openStack message in the stack you are setting the stackFiles on.
___
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: Anyone using a third-party update tool for LC-originated desktop apps?

[Trevor DeVore via use-livecode]

On Mon, Jan 22, 2018 at 5:04 AM, Graham Samuel via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Nowadays it’s customary for quite modest apps after launching to notify
> the user of an update being available, with the possibility of carrying out
> the update there and then, or refusing. A succession of dialog boxes guides
> the user through the updating process and shows progress. The update
> somehow bypasses the normal installation process, accepts existing license
> data, and simply replaces the app. If the app has a document open, then the
> new copy of the app re-opens it.


Graham,

There are a lot of different approaches to this in the community. Here is
my take on it. Currently I'm using the code in the following repository for
automated updates. It is a Helper that I use with the Levure framework and
I haven't documented it at all.

https://github.com/trevordevore/levurehelper-app_updater

It is a combination of Sparkle for macOS (Monte wrapped this up in an
external for me) and LCS for Windows that I've been using over the years.
Both macOS and Windows download an entirely new application. On macOS the
app is zipped up and Sparkle downloads the zip archive, unzips it, and
installs it. If the update requires authentication that is handled. On
Windows the updater just downloads the Windows installer executable that is
used for installing the app for the first time. This is an installer built
using Inno Setup which will prompt the user for administrative permissions
if need be.

I prefer to replace the entire application when I do updates. My apps are
installed in a number of different environments. I would often get reports
of problems when trying to update the app in pieces inside of corporations.
Plus if you don't update the exe on Windows then the version number of your
app won't be reported properly in the File Properties dialog. When I
switched to downloading and running a full installer on Windows the reports
of issues after running the updater dropped to 0.

In my ideal world the Windows side would use WinSparkle as it would be nice
to leverage the work of a 3rd party. I like using code that is being tested
by a lot of other people and which is entirely focused on automatic
updates. I didn't want to create an external around it, however, so I've
been waiting for the LCB to DLL interface in the engine to mature. I
imagine WinSparkle could probably be wrapped using LCB now.

https://winsparkle.org

I would like to see the LC community have a standard automatic update
solution available that is easy to use and is very reliable in all
environments. To me it makes the most sense to leverage the work done by
others who are focused on automatic update.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: Do script-only stacks support "chained" behaviors?

[Mike Kerner via use-livecode]

Geoff,
Since Trevor didn't answer the Levure question,
The way he suggested structuring the projects was putting the ui elements
and their behaviors into /ui/stackName (and then the behaviors for that
stack into /ui/stackName/behaviors/).  As for naming the stacks,
Scriptifier does it one (long) way in an attempt to make all the names
unique.  Trevor had suggested objectTypeobjectName"behavior", but
of course there is no reason why you would would have to be held to that.

It's not that you can't have scripts all over the Levure project, because
you will with libraries, components, etc. but those aren't the major PITA,
and that isn't what you're trying to address with Navigator.

SO, if I was going to convert a stack automagically, I would want to
1) make a copy of the stackfile, placing it in the /ui/stackname folder and
work on the copy
2) pull the various behaviors and put them in the /ui/stackfile/behaviors
folder
From there, we can argue a lot about the structure of the behaviors
folder.  On the one hand, if you keep everything in there together, then
you can kind-of use the names to keep everything straight, because as long
as you don't change the names of the SOS's, it doesn't matter if you move
the objects they are tied to from one card to another.  It's just that the
/behaviors folder can become the storage for hundreds of SOS's.  On the
other, it might be good to give the developer an option to have subfolders
for each card, but as soon as they move an object from one card to another
you have a gigantic mess of the developer wanting the SOS's to move, but
that will break the references, etc.

I'm glad you're working on this!  Now I can stop thinking about working on
it and go do something else.

On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > It occurs to me that this isn't as much of a problem as I thought -- any
> > button being converted to a stack is highly unlikely to have an openstack
> > handler already in it, and therefore it would be safe to add one and
> > include setting the behavior of the script-only stack to the appropriate
> > stack up the chain. If there were already an openstack handler in the
> > chain, then the conversion process could stop at that point, or perhaps
> log
> > the error to the user. Unless I'm missing something?
>
>
> Geoff,
>
> Keep in mind that script only stacks that are loaded into memory by the
> engine because they are referenced in the stackfiles of another stack won’t
> be sent any messages.
>
> http://quality.livecode.com/show_bug.cgi?id=18223
>
> You have to complete the behavior chain in the openStack handler of the
> stack that is being opened. I think in your case you would process the
> openStack message in the stack you are setting the stackFiles on.
>
> Trevor DeVore
> ScreenSteps
>
> >
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

[ANN] This Week in LiveCode 113

[panagiotis merakos via use-livecode]

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #113 here: https://goo.gl/s7EMqE

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.


-- 
Panagiotis Merakos 
LiveCode Software Developer

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: Do script-only stacks support "chained" behaviors?

[Trevor DeVore via use-livecode]

On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> It occurs to me that this isn't as much of a problem as I thought -- any
> button being converted to a stack is highly unlikely to have an openstack
> handler already in it, and therefore it would be safe to add one and
> include setting the behavior of the script-only stack to the appropriate
> stack up the chain. If there were already an openstack handler in the
> chain, then the conversion process could stop at that point, or perhaps log
> the error to the user. Unless I'm missing something?


Geoff,

Keep in mind that script only stacks that are loaded into memory by the
engine because they are referenced in the stackfiles of another stack won’t
be sent any messages.

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

You have to complete the behavior chain in the openStack handler of the
stack that is being opened. I think in your case you would process the
openStack message in the stack you are setting the stackFiles on.

Trevor DeVore
ScreenSteps

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

Anyone using a third-party update tool for LC-originated desktop apps?

[Graham Samuel via use-livecode]

Nowadays it’s customary for quite modest apps after launching to notify the 
user of an update being available, with the possibility of carrying out the 
update there and then, or refusing. A succession of dialog boxes guides the 
user through the updating process and shows progress. The update somehow 
bypasses the normal installation process, accepts existing license data, and 
simply replaces the app. If the app has a document open, then the new copy of 
the app re-opens it.

I was about to embark on coding all this in LC for an app that runs on Mac and 
PC desktops, when I realised that there are third-party tools out there that do 
it for you. At this stage I have not at all looked at the API of these things, 
or indeed checked if any of them are cross-platform. Before I go down one or 
more of these rabbit holes, I’d like to know if anyone on this list is already 
using one or more of these tools, and can give any guidance, including what to 
avoid, gotchas etc.

TIA for any input.

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