Re: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 06:56 PM, Mike Kerner via use-livecode wrote:

so, @markwieder, are you not a fan of synonyms?


Eh? No, very much am. Just usually get my hand slapped when I suggest 
that to the team.


--
 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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 09:18 PM, J. Landman Gay via use-livecode wrote:


I suspect 48% of readers will remember one of those over the others.


...wait... there was more than one?

--
 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: English Like?

[J. Landman Gay via use-livecode]

Now I only have to remember whether it's clockwise or the other one.


Use a mnemonic like "all cows eat grass" and "good boys do fine always":

Little Tykes Read Books

Lethal Tornadoes Ruin Buildings

Lowly Tadpoles Release Bubbles

Loose Tops Reveal Boo... er, Bosoms

I suspect 48% of readers will remember one of those over the others.

--
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: English Like?

[Jerry Jensen via use-livecode]

On May 24, 2017, at 2:30 PM, Mark Wieder via use-livecode 
 wrote:
> 
> On 05/24/2017 01:41 PM, Scott Rossi via use-livecode wrote:
>> @Mark — the sequence/direction is clockwise, if that helps.  So top -> left… 
>> doesn’t work.
> 
> That does, in a way.
> Now I only have to remember whether it's clockwise or the other one.
> And that it doesn't start at the top - TopRightBottomLeft seems more 
> clockwise to me. Or at least more like a clock.

Or just remember TL;DR but D stands for bottom.

Reminiscent of:
“Name’s Pither - just like brotherhood but pi instead of bro and without the 
hood part”
-Michael Palin



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

[William Prothero via use-livecode]

Folks:
Thanks for the comments. I bet the linefeeds caused me the problem, since I 
just took the contents of a text field, put them in an array, and didn’t pay 
attention to linefeeds.

Now I remember why I didn’t try to directly connect to the dB. The security 
issue makes it inadvisable to go direct. It would be nice if there was a 
cautionary statement about that in the dictionary. 

Best,
Bill

> On May 23, 2017, at 6:22 PM, Roger Eller via use-livecode 
>  wrote:
> 
> I have always replaced the linefeeds with a unique placeholder for
> transport, and switched it back to linefeeds in the server script.  I
> didn't even consider replacing with empty.
> 
> On May 23, 2017 8:55 PM, "Jonathan Lynch via use-livecode" <
> use-livecode@lists.runrev.com> wrote:
> 
>> One quick note about base64encode:
>> 
>> LC adds linefeeds. After you base64encode, you may need to replace
>> linefeed with empty in the variable.
>> 
>> Sent from my iPhone
>> 
>>> On May 23, 2017, at 8:10 PM, William Prothero via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Andre,
>>> This is good advice. I did it this way as a shortcut for an app I’ve
>> built for myself only. You are right that it makes debugging harder because
>> I can’t use other management applications to examine the contents.
>>> 
>>> For many years now I’ve used php cgi’s to connect to the remote mysql db
>> and it works well. I just haven’t spent the time to set up JSON.
>>> 
>>> But it looks like I could dispense with the php and directly access the
>> mySQL db from my mobile app, without a cgi?
>>> 
>>> Best,
>>> Bill
>>> 
 On May 23, 2017, at 3:30 PM, Andre Garzia via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
 
 William,
 
 If I may add a bit of personal opinion here... so, I have been using and
 storing LC stuff in databases for a long time. Not only I have been
>> storing
 arrays in database but I had them flying over TCP sockets and being
 decoded/encoded as needed. For a long time I used the same approach as
>> you,
 which is to arrayEncode + base64 the array.
 
 I don't do that any longer. That combination is very hard to debug. I
>> would
 advise you simply to use JSON and store it as JSON on the db. Instead of
 encoding the array twice, you do it only once with jsonexport() and then
 when importing, you do it only once with jsonimport()
 
 Not only that reduces complexity but it also makes it a lot easier to
 debug. As a bonus, your data can be consumed by other applications which
 are not based on LC which may open a whole ecosystem of plugins and
 interoperation to your product.
 
 Cheers
 andre
 
 
 On Sun, May 21, 2017 at 9:45 PM, William Prothero via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
> Never mind. I got it working. I’m not exactly sure about the problem
> because the method I used should have been quite general. However, what
> made it work is that I had the contents of a list field in the array I
>> was
> storing and that somehow caused an error when I tried to decode the
>> array.
> I deleted that array key, because there was no reason I needed to have
>> it
> in the db anyway, and it worked.
> 
> I’ll look into why and report back if I find anything interesting.
> Best,
> Bill
> 
>> On May 21, 2017, at 5:23 PM, William Prothero via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>> 
>> Whoops, I lied.
>> The data is stored incorrectly in the simulator too.
>> Hmm….
>> The IDE stores it correctly. There is something in the encoding that
>> I’m
> missing.
>> Bill
>> 
>>> On May 21, 2017, at 5:03 PM, William Prothero via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Folks:
>>> I have an app that stores data to a mysql database on my server. It
> works fine in the IDE and in the iPhone simulator. However, when I
>> load the
> app onto the iPhone, the saved data is corrupted.
>>> 
>>> I am saving an array. The array is saved in a big string that has
>> been
> base64 encoded.
>>> 
>>> When saving, I do:
>>> 
>>> put arrayEncode(tArray) into tData
>>> 
>>> put base64encode(tData) into xData
>>> 
>>> put urlEncode(xData) into xData
>>> 
>>> xData is sent to the db
>>> 
>>> When I read back the data, I do the inverse:
>>> 
>>> urlDecode
>>> base64Decode
>>> arrayDecode
>>> 
>>> The base64 data on the db is different when I store it from the
>> iPhone.
> I can see this with Navicat, which I use for db management. So, the
>> problem
> is in the storing of the data.
>>> 
>>> What the heck? I am just using a post command to a php script that
> writes to the db.
>>> 
>>> Why would the iPhone data that is sent be different from 

Porridge (was Re: English Like?)

[James Hale via use-livecode]

Richard wrote:
> For those who like salt in their porridge there's LiveCode, and for 
> those who prefer sugar, or syrup, or prunes in their porridge
> there are other puddings on offer.

I actually like both. Couldn't imagine not putting salt in the porridge. Then 
once it is cooked, add sugar and usually sultanas (occasionally a banana.)
Of course I am speaking of rolled oat porridge and made using full cream milk.
(Yes, I like it rich, creamy and sweet.)

Delicious 

___
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

Printed dictionary (was Re: send mouseup to control)

[James Hale via use-livecode]

In following them discussion on execution contexts Richard wrote:
> The executionContexts is documented, though in all fairness that Dict 
> entry includes a note about not relying on the format of its contents. 


Normally I would moan to myself about how I would like to look that up but as I 
am reading this email (and nearly all others) on my iPad I cannot use the 
online dictionary as it can't handle a touch interface (the mothership is aware 
that they do have a non mobile friendly resource for a mobile capable product).

But this morning the printed dictionary arrived! 

So I looked up executionContexts

Where I read...
'' A common use of the executionContexts is to obtain the name of the object 
and handler that called the current handler, this information is available as 
line -2 of the executionContexts."

BTW there was no mention of any caveats in using this property.

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: Is there any way at all to have a mobile app simply resume rather than restart?

[Mike Kerner via use-livecode]

I'm pretty sure you can't do it while it's still in the applications
folder.  You have to command-drag it out of the applications folder, first,
before you modify it - at least I do, anyway.

On Wed, May 24, 2017 at 5:57 PM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This is great Ralph
>
> Thank you
>
> I wonder if this can open up other possibilities as well
>
> Sent from my iPhone
>
> > On May 24, 2017, at 5:17 PM, Ralph DiMola 
> wrote:
> >
> > 1) Go to the Applications folder
> > 2) Right click on the LC app you are using and select "Show Package
> > Contents"
> > 3) Navigate to the "Tools/Runtime/iOS" folder
> > 4) Right click on all the device/simulator folders one at a time and
> select
> > "Get Info"
> > 5) At the bottom click on the "Read only" to the right of your account
> name
> > and select "Read & Write"
> > 6) Repeat 5 for all device/simulator folders
> > 7) In each of the device/simulator folders edit the setting.plist file.
> > 8) To edit... right click the setting.plist file and select "Open With"
> and
> > then "Other..." and select "TextEdit.app".
> > 9) You will get a warning that the file is locked. Choose the Unlock
> option.
> >
> > 10) Either change UIApplicationExitsOnSuspend key value to "False" or
> like I
> > do delete the key all together(2 lines)
> > 11) repeat 8-10 for setting.plist in each of the device/simulator
> folders.
> > 12) Fire up LC and make an iOS app.
> >
> > Ralph DiMola
> > IT Director
> > Evergreen Information Services
> > rdim...@evergreeninfo.net
> >
> >
> > -Original Message-
> > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
> Behalf
> > Of Jonathan Lynch via use-livecode
> > Sent: Wednesday, May 24, 2017 4:37 PM
> > To: How to use LiveCode
> > Cc: jonathandly...@gmail.com
> > Subject: Re: Is there any way at all to have a mobile app simply resume
> > rather than restart?
> >
> > I don't actually know how to do any of the steps for this - would be
> easy on
> > a pc. Researching it now.
> >
> > Sent from my iPhone
> >
> >> On May 24, 2017, at 4:27 PM, jonathandly...@gmail.com wrote:
> >>
> >> I read that on the forums, but I defer to Ralph on this.
> >>
> >> I am playing with the hack now.
> >>
> >> I think I could also have a legitimate reason for playing audio -
> changing
> > the music as a user gets closer to a marker - but that would be a lot of
> > trouble to set up right now.
> >>
> >> Sent from my iPhone
> >>
> >>> On May 24, 2017, at 4:07 PM, Mike Kerner via use-livecode
> >  wrote:
> >>>
> >>> Are you sure?  I'm pretty sure I have at least a couple of apps I
> >>> built in
> >>> 8 that still use the hack.
> >>>
> >>> On Wed, May 24, 2017 at 3:54 PM, Jonathan Lynch via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> >>>
>  It looks like the plist hack is not available in version 8.
> 
>  Choosing background audio works - but that means I need to have a
>  plausible reason for having background audio or Apple reviewers
>  might ding the app.
> 
>  What a pain - why not just allow it to work the way other apps work?
> 
>  Sent from my iPhone
> 
> > On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
> >
> > Thank you!
> >
> > Sent from my iPhone
> >
> >> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode <
>  use-livecode@lists.runrev.com> wrote:
> >>
> >> If you're referring to ios, look up "plist hack", here.  The only
> >> thing
>  to
> >> remember is that for each version of LC, you have to perform the
> >> hack, again, until Edinburgh gives us a Standalone Settings option.
> >>
> >> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>> Having to restart the app from scratch sucks. I can store the
> >>> current state, but my users would have to wait for the map widget
> >>> to reload
>  every
> >>> time they came back from another app.
> >>>
> >>> Sent from my iPhone
> >>> ___
> >>> 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 

Re: Dropbox v1 API - one month until it is shut off!

[Mike Kerner via use-livecode]

and unless I'm missing it, it's not in 9, yet.  I don't see it in dp6.

On Wed, May 24, 2017 at 9:58 PM, Mike Kerner 
wrote:

> Mainly what I was trying to remind everyone was that they have to get
> their code changed, asap.
>
> On Wed, May 24, 2017 at 6:05 PM, Monte Goulding via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> We have a derivative of Gerard’s library in LC 9:
>>
>> https://github.com/livecode/livecode/blob/develop/extensions
>> /script-libraries/dropbox/dropbox.livecodescript <
>> https://github.com/livecode/livecode/blob/develop/extension
>> s/script-libraries/dropbox/dropbox.livecodescript>
>>
>> There is not much point maintaining mergDropbox if there are script
>> library alternatives available.
>>
>> Cheers
>>
>> Monte
>>
>> > On 25 May 2017, at 5:42 am, Mike Kerner via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> >
>> > Reminder, everyone using dropbox, you have until the end of June to get
>> > your apps migrated to the v2 API before your dropbox functionality will
>> > cease.  Rumor says that the Dropbox team is granting reprieves to people
>> > who ask for them, but I don't know if that's for everyone for every app.
>> >
>> > If you are using the phx_dropboxLib library, my advice is that you
>> download
>> > Gerard McCarthy's dropboxAPI_2 lib and get your code switched.  If you
>> > don't already have it, I have it as a repo on github (
>> > https://github.com/macMikey/dropboxapi_v2), both as a binary stack and
>> as a
>> > script-only stack, but it is available in a variety of places.
>> >
>> > If you are using mergDropbox, I just sent a reminder to Edinburgh that
>> > Monte has work to do, but I don't have an ETA.
>> >
>> > --
>> > 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
>
>
>
>
> --
> 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."
>



-- 
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: Dropbox v1 API - one month until it is shut off!

[Mike Kerner via use-livecode]

Mainly what I was trying to remind everyone was that they have to get their
code changed, asap.

On Wed, May 24, 2017 at 6:05 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> We have a derivative of Gerard’s library in LC 9:
>
> https://github.com/livecode/livecode/blob/develop/
> extensions/script-libraries/dropbox/dropbox.livecodescript <
> https://github.com/livecode/livecode/blob/develop/
> extensions/script-libraries/dropbox/dropbox.livecodescript>
>
> There is not much point maintaining mergDropbox if there are script
> library alternatives available.
>
> Cheers
>
> Monte
>
> > On 25 May 2017, at 5:42 am, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Reminder, everyone using dropbox, you have until the end of June to get
> > your apps migrated to the v2 API before your dropbox functionality will
> > cease.  Rumor says that the Dropbox team is granting reprieves to people
> > who ask for them, but I don't know if that's for everyone for every app.
> >
> > If you are using the phx_dropboxLib library, my advice is that you
> download
> > Gerard McCarthy's dropboxAPI_2 lib and get your code switched.  If you
> > don't already have it, I have it as a repo on github (
> > https://github.com/macMikey/dropboxapi_v2), both as a binary stack and
> as a
> > script-only stack, but it is available in a variety of places.
> >
> > If you are using mergDropbox, I just sent a reminder to Edinburgh that
> > Monte has work to do, but I don't have an ETA.
> >
> > --
> > 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




-- 
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: English Like?

[Mike Kerner via use-livecode]

so, @markwieder, are you not a fan of synonyms?

On Wed, May 24, 2017 at 8:31 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 05/24/2017 03:38 PM, Richard Gaskin via use-livecode wrote:
>
>> Mark Wieder wrote:
>>
>>  > Now I only have to remember whether it's clockwise or the other one.
>>  > And that it doesn't start at the top - TopRightBottomLeft seems more
>>  > clockwise to me. Or at least more like a clock.
>>
>> And to the team that designed CSS.
>>
>>
>  don't get me started on CSS inconsistencies...
>
> --
>  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
>



-- 
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: Writing Extensions

[Kay C Lan via use-livecode]

And this is exactly why I love Switch, that I can use Case as an OR
statement whilst using soft wrap \ (CR) for making the script more
readable and understandable as the indenting is different.

My specific situation is I have 99 objects that I need to test. Some
are booleans, some integers, some date and times, some text. As you
can appreciate the possible variations of combination is a very large
number, but thankfully the outcomes fall nicely within a bell curve
and the responses to many 'groups' of conditions is the same. This is
where the discovery of Switch fall through was a godsend.

So I write my Switch statement like this:

switch
  --bell curve case 1
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99))
myHandler1
  break
  --bell curve case 2
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99))
 myHandler2
  break
  case 

  break
  default
answer warning "A Case I have not considered." titled "Case Error"
breakpoint
end switch

What this allows me to do is very quickly capture the middle of the
bell curve of all the 'known' expected cases, but ALWAYS stop at the
outliers - at which point I'll update the code as required.
Unfortunately as a single line it's VERY difficult to figure out the
difference between case 1 and 2 above because the actually difference
is way off the page. So I can use soft line break \ (CR) and a little
thought:

switch
  --bell curve case 1
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
(myVar57 is true) AND (myVar82 is empty)) --the unique bits
myHandler1
  break
  --bell curve case 2
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
 ((myVar33 <> 11) OR (myVar71 contains "uranium"))  --the unique bits
 myHandler2
  break
  case ...

  break
  default
answer warning "A Case I have not considered." titled "Case Error"
breakpoint
end switch

This then makes it very fast and easy to duplicate cases which are
very similar and require the same action, by simple Copy and Paste and
adjust the appropriate unique tests

switch
  --bell curve case 1
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
(myVar57 is true) AND (myVar82 is empty)) --the unique bits
  --FALL THROUGH, an OR, many tests the same, needs to be handled as above
  --bell curve case 1a
  case ((myVar2 = myCondition2) AND (myVar3 < myCondition3) AND ...
(myVar99 contains myCondition99) AND \
(myVar1 <> myCondition1) AND (myVar42 is an integer)) --the unique bits
myHandler1
  break
  --bell curve case 2
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
 ((myVar33 <> 11) OR (myVar71 contains "uranium"))  --the unique bits
 myHandler2
  break
  case ...

  break
  default
answer warning "A Case I have not considered." titled "Case Error"
breakpoint
end switch

And the above is extremely simplistic compared to what I really have.
What I've shown as (myVar1 = myCondition1) AND (myVar2 < myCondition2)
in reality what appears within those bracketed AND statements are
usually multi-conditional OR tests themselves, each one long enough to
disappear off the screen before you get to the first AND! In one area
of the code I have well over 100 case () which fall through, and each
of those lines contains at least one soft wrap \ CR and sometimes more
if it's the contents of blocks of text that is unique. To replace the
fall through case () with a soft wrap OR \ which would then indent
exactly the same as what I've already formatted using soft wraps
it just makes my brain hurt thinking about trying to unravel the mess
that would quickly become.

I appreciate my situation is probably extremely unique, but given the
opportunity to construct a new and improved Switch structure,  if fall
through is the problem then I'd make it clear that it is effectively
an OR, by using it as a keyword in the structure. I would also include
AND as a keyword even though 99.9% of the time it would seem
pointless. But trust me, when you are dealing with billions of
permutations, relying solely on soft wrap CRs \ is NOT VERY HELPFUL.

Having a new CHOOSE structure that auto indented on WHEN, OR, AND and
left you to use soft wrap \ CRs where you saw fit, I'm sure would help
create better blocks of code that would be easier to understand.

On Wed, May 24, 2017 at 11:11 PM, Mike Kerner via use-livecode
 wrote:
> I personally hate switch.  That said, getting rid of the CR's would help
> make the new "choose" easier to read.  If you want a CR, use \
>
> choose tValue
>  when 1 or 2 or 3
>   -- do something
> end choose
>
> choose tValue
>  when 1\
>  or 2\
>  or 3
>   -- do something
> end choose
>
> On Wed, May 24, 2017 at 

Re: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 03:38 PM, Richard Gaskin via use-livecode wrote:

Mark Wieder wrote:

 > Now I only have to remember whether it's clockwise or the other one.
 > And that it doesn't start at the top - TopRightBottomLeft seems more
 > clockwise to me. Or at least more like a clock.

And to the team that designed CSS.



 don't get me started on CSS inconsistencies...

--
 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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 02:57 PM, Alejandro Tejada via use-livecode wrote:

Or you could remember that the
Rectangle of a control is a repetition
of two coordinates: xyxy
Left and Right are on X axis
Top and Bottom are on Y axis.


Indeed - so it's like two points (x,y) , (x,y): leftTop, rightBottom.
Except that it's topLeft and bottomRight. Not saying that it shouldn't 
be... it's just part of being "English-like".


...and I have to laugh at the dictionary's syntax for topLeft:

"set the topLeft of object to left, top"

--
 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: English Like?

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

> Now I only have to remember whether it's clockwise or the other one.
> And that it doesn't start at the top - TopRightBottomLeft seems more
> clockwise to me. Or at least more like a clock.

And to the team that designed CSS.

--
 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: breakpoint on parameter

[Quentin Long via use-livecode]

sez "J. Landman Gay" :
| On 5/23/17 10:36 AM, Matt Maier via use-livecode wrote:
| > I want to find out which parts of my code are making changes to a control's
| > parameter. Specifically, I've got an arrow that I want to be black, and it
| > is black when it's created, but then it turns gray. I can't find the script
| > that's turning it gray.
| > 
| > I don't know where to put a breakpoint in the script.
| > 
| > Can I put a breakpoint on that control's color parameter, so execution
| > stops whenever something modifies it and goes to the script that's doing
| > the modification?
| 
| You can't break for a parameter per se, only at a specified line of 
| script. …
I just had an idea that might be helpful for Matt Maier…

If I'm reading the LC Dictionary aright, the property "executionContexts" 
should be very useful for nailing down which handler did what at whatever time; 
you just need to look at the executionContexts at just the right moment. So, 
use a "send [whatever] in [time]" loop, like so:

on ColorCheck
  if (the color of the specific control) = "gray" then
answer the executionContexts
  end if
  if the optionKey is up then send "ColorCheck" to me in 50 milliseconds
end ColorCheck

Ordinarily, "send [whatever] in [time]" loops are frowned upon because they 
burn cycles gratuitously, thus slowing down the stack's operations. But in this 
case, slowing down the stack's operations should be acceptable, as it gives you 
a better chance of catching the offending command (i.e., the one that's doing 
the color-change) in the act.

Troubleshooting: If what's really happening is an change in the control's blend 
property, that could make the control *appear* to change color while said color 
is actually the same, in which case the "answer the executionContexts" line 
would never execute. If this happens, check for a change in the control's blend 
property, not a change in the control's color property.
   
"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"

Read the webcomic at [ http://www.atarmslength.net ]!

If you like "At Arm's Length", support it at [ 
http://www.patreon.com/DarkwingDude ].

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

[Monte Goulding via use-livecode]

> On 24 May 2017, at 10:21 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
>> Switch in LCB -- Monte asked to have the opportunity to do the job:
>> http://forums.livecode.com/viewtopic.php?p=131509#p131509 
>> 
> 
> Yes... I'm not sure I quite see your point (especially as he said 'Is there 
> any chance switch will be implemented as a control structure.', not 'how 
> would I implement...') :)

Lol… FWIW I still wouldn’t have any idea how to implement it, I still would 
like it and regardless of what the boss says I think it would do my head in if 
we had it and it was different to the LCS one ;-)

Cheers

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

Re: Dropbox v1 API - one month until it is shut off!

[Monte Goulding via use-livecode]

We have a derivative of Gerard’s library in LC 9:

https://github.com/livecode/livecode/blob/develop/extensions/script-libraries/dropbox/dropbox.livecodescript
 


There is not much point maintaining mergDropbox if there are script library 
alternatives available.

Cheers

Monte

> On 25 May 2017, at 5:42 am, Mike Kerner via use-livecode 
>  wrote:
> 
> Reminder, everyone using dropbox, you have until the end of June to get
> your apps migrated to the v2 API before your dropbox functionality will
> cease.  Rumor says that the Dropbox team is granting reprieves to people
> who ask for them, but I don't know if that's for everyone for every app.
> 
> If you are using the phx_dropboxLib library, my advice is that you download
> Gerard McCarthy's dropboxAPI_2 lib and get your code switched.  If you
> don't already have it, I have it as a repo on github (
> https://github.com/macMikey/dropboxapi_v2), both as a binary stack and as a
> script-only stack, but it is available in a variety of places.
> 
> If you are using mergDropbox, I just sent a reminder to Edinburgh that
> Monte has work to do, but I don't have an ETA.
> 
> -- 
> 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

English Like?

[Alejandro Tejada via use-livecode]

Or you could remember that the
Rectangle of a control is a repetition
of two coordinates: xyxy
Left and Right are on X axis
Top and Bottom are on Y axis.

> on 05/24/2017 01:41 PM, Scott Rossi wrote:
> the sequence/direction is clockwise, if that helps.
> So top -> left… doesn’t work.

> Mark Wieder wrote:
> That does, in a way. Now I only have to remember
> whether it's clockwise or the other one.
> And that it doesn't start at the top -
> TopRightBottomLeft seems more clockwise to me.
> Or at least more like a clock.

Al
___
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: Is there any way at all to have a mobile app simply resume rather than restart?

[Jonathan Lynch via use-livecode]

This is great Ralph 

Thank you

I wonder if this can open up other possibilities as well

Sent from my iPhone

> On May 24, 2017, at 5:17 PM, Ralph DiMola  wrote:
> 
> 1) Go to the Applications folder
> 2) Right click on the LC app you are using and select "Show Package
> Contents"
> 3) Navigate to the "Tools/Runtime/iOS" folder
> 4) Right click on all the device/simulator folders one at a time and select
> "Get Info"
> 5) At the bottom click on the "Read only" to the right of your account name
> and select "Read & Write"
> 6) Repeat 5 for all device/simulator folders
> 7) In each of the device/simulator folders edit the setting.plist file.
> 8) To edit... right click the setting.plist file and select "Open With" and
> then "Other..." and select "TextEdit.app".
> 9) You will get a warning that the file is locked. Choose the Unlock option.
> 
> 10) Either change UIApplicationExitsOnSuspend key value to "False" or like I
> do delete the key all together(2 lines)
> 11) repeat 8-10 for setting.plist in each of the device/simulator folders.
> 12) Fire up LC and make an iOS app.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of Jonathan Lynch via use-livecode
> Sent: Wednesday, May 24, 2017 4:37 PM
> To: How to use LiveCode
> Cc: jonathandly...@gmail.com
> Subject: Re: Is there any way at all to have a mobile app simply resume
> rather than restart?
> 
> I don't actually know how to do any of the steps for this - would be easy on
> a pc. Researching it now.
> 
> Sent from my iPhone
> 
>> On May 24, 2017, at 4:27 PM, jonathandly...@gmail.com wrote:
>> 
>> I read that on the forums, but I defer to Ralph on this.
>> 
>> I am playing with the hack now.
>> 
>> I think I could also have a legitimate reason for playing audio - changing
> the music as a user gets closer to a marker - but that would be a lot of
> trouble to set up right now.
>> 
>> Sent from my iPhone
>> 
>>> On May 24, 2017, at 4:07 PM, Mike Kerner via use-livecode
>  wrote:
>>> 
>>> Are you sure?  I'm pretty sure I have at least a couple of apps I 
>>> built in
>>> 8 that still use the hack.
>>> 
>>> On Wed, May 24, 2017 at 3:54 PM, Jonathan Lynch via use-livecode < 
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 It looks like the plist hack is not available in version 8.
 
 Choosing background audio works - but that means I need to have a 
 plausible reason for having background audio or Apple reviewers 
 might ding the app.
 
 What a pain - why not just allow it to work the way other apps work?
 
 Sent from my iPhone
 
> On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
> 
> Thank you!
> 
> Sent from my iPhone
> 
>> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode <
 use-livecode@lists.runrev.com> wrote:
>> 
>> If you're referring to ios, look up "plist hack", here.  The only 
>> thing
 to
>> remember is that for each version of LC, you have to perform the 
>> hack, again, until Edinburgh gives us a Standalone Settings option.
>> 
>> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode < 
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Having to restart the app from scratch sucks. I can store the 
>>> current state, but my users would have to wait for the map widget 
>>> to reload
 every
>>> time they came back from another app.
>>> 
>>> Sent from my iPhone
>>> ___
>>> 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
 
>>> 
>>> 
>>> 
>>> --
>>> On the first day, God created the heavens and the Earth On the second 
>>> day, God created the oceans.
>>> On the third day, God 

Re: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 05:43 AM, Mike Kerner via use-livecode wrote:

One of the other things that the xtalk languages have that makes them more
appealing is synonyms




--
 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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 08:03 AM, Mark Waddingham via use-livecode wrote:

> Syntax is an emotive issue (I could beat Python to death with some of 
the decisions they have made about syntax - but yet I still use it and 
slightly enjoy doing so for the purposes I use it for) - but it is not 
the be-all-and-end-all.


I could say the same for any of the computer languages I use.
And not just computer languages- the various forms of the irregular 
verbs for instance...


Old English beon, beom, bion "be, exist, come to be, become, happen," 
from Proto-Germanic *biju- "I am, I will be." This "b-root" is from PIE 
root *bheue- "to be, exist, grow," and in addition to the words in 
English it yielded German present first and second person singular (bin, 
bist, from Old High German bim "I am," bist "thou art"), Latin 
perfective tenses of esse (fui "I was," etc.), Old Church Slavonic byti 
"be," Greek phu- "become," Old Irish bi'u "I am," Lithuanian bu'ti "to 
be," Russian byt' "to be," etc.


The modern verb to be in its entirety represents the merger of two 
once-distinct verbs, the "b-root" represented by be and the am/was verb, 
which was itself a conglomerate. Roger Lass ("Old English") describes 
the verb as "a collection of semantically related paradigm fragments," 
while Weekley calls it "an accidental conglomeration from the different 
Old English dial[ect]s." It is the most irregular verb in Modern English 
and the most common. Collective in all Germanic languages, it has eight 
different forms in Modern English:


BE (infinitive, subjunctive, imperative)
AM (present 1st person singular)
ARE (present 2nd person singular and all plural)
IS (present 3rd person singular)
WAS (past 1st and 3rd persons singular)
WERE (past 2nd person singular, all plural; subjunctive)
BEING (progressive & present participle; gerund)
BEEN (perfect participle).

Old English am had two plural forms: 1. sind/sindon, sie and 2. 
earon/aron. The s- form (also used in the subjunctive) fell from English 
in the early 13c. (though its cousin continues in German sind, the 3rd 
person plural of "to be") and was replaced by forms of be, but aron (see 
are) continued, and as am and be merged it encroached on some uses that 
previously had belonged to be. By the early 1500s it had established its 
place in standard English.


That but this blow Might be the be all, and the end all.
["Macbeth" I.vii.5]

--
 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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 01:41 PM, Scott Rossi via use-livecode wrote:

@Mark — the sequence/direction is clockwise, if that helps.  So top -> left… 
doesn’t work.


That does, in a way.
Now I only have to remember whether it's clockwise or the other one.
And that it doesn't start at the top - TopRightBottomLeft seems more 
clockwise to me. Or at least more like a clock.


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

[ANN] This Week in LiveCode 83

[Alejandro Tejada via use-livecode]

This Week in LiveCode Newsletter wrote:

> Peter Brett has sadly left us for pastures new,
> we wish him all the best in his new post and
> he will of course be missed. Our thanks for
> his sterling contribution to advancing LiveCode
> over the last few years.

I visited Peter's blog looking for more info:
http://blog.peter-b.co.uk/
but found nothing about this job's change.
Now, Who is the new LiveCode
Technical Project Manager?

Welcome to Alex Brisan and Chris Colman.
I hope that both find time to participate in
the forums and mail list and meet the
wonderful community of people from
this development platform.

Al
___
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: Is there any way at all to have a mobile app simply resume rather than restart?

[Ralph DiMola via use-livecode]

1) Go to the Applications folder
2) Right click on the LC app you are using and select "Show Package
Contents"
3) Navigate to the "Tools/Runtime/iOS" folder
4) Right click on all the device/simulator folders one at a time and select
"Get Info"
5) At the bottom click on the "Read only" to the right of your account name
and select "Read & Write"
6) Repeat 5 for all device/simulator folders
7) In each of the device/simulator folders edit the setting.plist file.
8) To edit... right click the setting.plist file and select "Open With" and
then "Other..." and select "TextEdit.app".
9) You will get a warning that the file is locked. Choose the Unlock option.

10) Either change UIApplicationExitsOnSuspend key value to "False" or like I
do delete the key all together(2 lines)
11) repeat 8-10 for setting.plist in each of the device/simulator folders.
12) Fire up LC and make an iOS app.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Jonathan Lynch via use-livecode
Sent: Wednesday, May 24, 2017 4:37 PM
To: How to use LiveCode
Cc: jonathandly...@gmail.com
Subject: Re: Is there any way at all to have a mobile app simply resume
rather than restart?

I don't actually know how to do any of the steps for this - would be easy on
a pc. Researching it now.

Sent from my iPhone

> On May 24, 2017, at 4:27 PM, jonathandly...@gmail.com wrote:
> 
> I read that on the forums, but I defer to Ralph on this.
> 
> I am playing with the hack now.
> 
> I think I could also have a legitimate reason for playing audio - changing
the music as a user gets closer to a marker - but that would be a lot of
trouble to set up right now.
> 
> Sent from my iPhone
> 
>> On May 24, 2017, at 4:07 PM, Mike Kerner via use-livecode
 wrote:
>> 
>> Are you sure?  I'm pretty sure I have at least a couple of apps I 
>> built in
>> 8 that still use the hack.
>> 
>> On Wed, May 24, 2017 at 3:54 PM, Jonathan Lynch via use-livecode < 
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> It looks like the plist hack is not available in version 8.
>>> 
>>> Choosing background audio works - but that means I need to have a 
>>> plausible reason for having background audio or Apple reviewers 
>>> might ding the app.
>>> 
>>> What a pain - why not just allow it to work the way other apps work?
>>> 
>>> Sent from my iPhone
>>> 
 On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
 
 Thank you!
 
 Sent from my iPhone
 
> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
> 
> If you're referring to ios, look up "plist hack", here.  The only 
> thing
>>> to
> remember is that for each version of LC, you have to perform the 
> hack, again, until Edinburgh gives us a Standalone Settings option.
> 
> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode < 
> use-livecode@lists.runrev.com> wrote:
> 
>> Having to restart the app from scratch sucks. I can store the 
>> current state, but my users would have to wait for the map widget 
>> to reload
>>> every
>> time they came back from another app.
>> 
>> Sent from my iPhone
>> ___
>> 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
>>> 
>> 
>> 
>> 
>> --
>> 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: English Like?

[Scott Rossi via use-livecode]

@Mark — the sequence/direction is clockwise, if that helps.  So top -> left… 
doesn’t work.

Scott Rossi 
Creative Director 
Tactile Media, UX/UI Design 



> On May 24, 2017, at 12:35 PM, Mark Wieder via use-livecode 
>  wrote:
> 
> On 05/24/2017 12:25 PM, Alex Tweedly via use-livecode wrote:
>> constant kRectLeft = 1, kRectTop = 2, kRectRight = 3, kRectBottom = 4
>> (or whatever ... haven't looked it up :-)
> 
> Exactly the point.
> I'd have to store this somewhere, and either grab it each time I need it or 
> look it up and reinvent it each time.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Is there any way at all to have a mobile app simply resume rather than restart?

[Jonathan Lynch via use-livecode]

I don't actually know how to do any of the steps for this - would be easy on a 
pc. Researching it now.

Sent from my iPhone

> On May 24, 2017, at 4:27 PM, jonathandly...@gmail.com wrote:
> 
> I read that on the forums, but I defer to Ralph on this.
> 
> I am playing with the hack now.
> 
> I think I could also have a legitimate reason for playing audio - changing 
> the music as a user gets closer to a marker - but that would be a lot of 
> trouble to set up right now.
> 
> Sent from my iPhone
> 
>> On May 24, 2017, at 4:07 PM, Mike Kerner via use-livecode 
>>  wrote:
>> 
>> Are you sure?  I'm pretty sure I have at least a couple of apps I built in
>> 8 that still use the hack.
>> 
>> On Wed, May 24, 2017 at 3:54 PM, Jonathan Lynch via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> It looks like the plist hack is not available in version 8.
>>> 
>>> Choosing background audio works - but that means I need to have a
>>> plausible reason for having background audio or Apple reviewers might ding
>>> the app.
>>> 
>>> What a pain - why not just allow it to work the way other apps work?
>>> 
>>> Sent from my iPhone
>>> 
 On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
 
 Thank you!
 
 Sent from my iPhone
 
> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
> 
> If you're referring to ios, look up "plist hack", here.  The only thing
>>> to
> remember is that for each version of LC, you have to perform the hack,
> again, until Edinburgh gives us a Standalone Settings option.
> 
> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Having to restart the app from scratch sucks. I can store the current
>> state, but my users would have to wait for the map widget to reload
>>> every
>> time they came back from another app.
>> 
>> Sent from my iPhone
>> ___
>> 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
>>> 
>> 
>> 
>> 
>> -- 
>> 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: Is there any way at all to have a mobile app simply resume rather than restart?

[Jonathan Lynch via use-livecode]

I read that on the forums, but I defer to Ralph on this.

I am playing with the hack now.

I think I could also have a legitimate reason for playing audio - changing the 
music as a user gets closer to a marker - but that would be a lot of trouble to 
set up right now.

Sent from my iPhone

> On May 24, 2017, at 4:07 PM, Mike Kerner via use-livecode 
>  wrote:
> 
> Are you sure?  I'm pretty sure I have at least a couple of apps I built in
> 8 that still use the hack.
> 
> On Wed, May 24, 2017 at 3:54 PM, Jonathan Lynch via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> It looks like the plist hack is not available in version 8.
>> 
>> Choosing background audio works - but that means I need to have a
>> plausible reason for having background audio or Apple reviewers might ding
>> the app.
>> 
>> What a pain - why not just allow it to work the way other apps work?
>> 
>> Sent from my iPhone
>> 
>>> On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
>>> 
>>> Thank you!
>>> 
>>> Sent from my iPhone
>>> 
 On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
 
 If you're referring to ios, look up "plist hack", here.  The only thing
>> to
 remember is that for each version of LC, you have to perform the hack,
 again, until Edinburgh gives us a Standalone Settings option.
 
 On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
> Having to restart the app from scratch sucks. I can store the current
> state, but my users would have to wait for the map widget to reload
>> every
> time they came back from another app.
> 
> Sent from my iPhone
> ___
> 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
>> 
> 
> 
> 
> -- 
> 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: English Like?

[Ali Lloyd via use-livecode]

All this chat reminds me about this old pull request:
https://github.com/livecode/livecode/pull/1587/files and blog post
https://livecode.com/extending-the-refactored-engine-properties/

the top/bottom/left/right/middle/area etc of rect could probably be done in
the same way.

OK so it's maybe not quite the right approach but it was fun to implement!

On Wed, May 24, 2017 at 8:35 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 05/24/2017 12:25 PM, Alex Tweedly via use-livecode wrote:
> > constant kRectLeft = 1, kRectTop = 2, kRectRight = 3, kRectBottom = 4
> >
> > (or whatever ... haven't looked it up :-)
>
> Exactly the point.
> I'd have to store this somewhere, and either grab it each time I need it
> or look it up and reinvent it each time.
>
> --
>   Mark Wieder
>   ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Is there any way at all to have a mobile app simply resume rather than restart?

[Mike Kerner via use-livecode]

Are you sure?  I'm pretty sure I have at least a couple of apps I built in
8 that still use the hack.

On Wed, May 24, 2017 at 3:54 PM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> It looks like the plist hack is not available in version 8.
>
> Choosing background audio works - but that means I need to have a
> plausible reason for having background audio or Apple reviewers might ding
> the app.
>
> What a pain - why not just allow it to work the way other apps work?
>
> Sent from my iPhone
>
> > On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
> >
> > Thank you!
> >
> > Sent from my iPhone
> >
> >> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> If you're referring to ios, look up "plist hack", here.  The only thing
> to
> >> remember is that for each version of LC, you have to perform the hack,
> >> again, until Edinburgh gives us a Standalone Settings option.
> >>
> >> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>> Having to restart the app from scratch sucks. I can store the current
> >>> state, but my users would have to wait for the map widget to reload
> every
> >>> time they came back from another app.
> >>>
> >>> Sent from my iPhone
> >>> ___
> >>> 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
>



-- 
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: Is there any way at all to have a mobile app simply resume rather than restart?

[Ralph DiMola via use-livecode]

Jonathan,

This works in V8/V9. I don't make a copy.

1) In the app bundle look in the folder ==>"Tools/Runtime/iOS" set all the
folders to read/write.
2) Edit the setting.plist in each of the folders and change
UIApplicationExitsOnSuspend key value to "False" (or like I do...delete the
key all together)

Apple has never complained. But... Ticking the "Background Audio" option
sets UIBackgroundModes key to "audio". You will get rejected if you app does
not play background audio.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Jonathan Lynch via use-livecode
Sent: Wednesday, May 24, 2017 3:55 PM
To: How to use LiveCode
Cc: jonathandly...@gmail.com
Subject: Re: Is there any way at all to have a mobile app simply resume
rather than restart?

It looks like the plist hack is not available in version 8. 

Choosing background audio works - but that means I need to have a plausible
reason for having background audio or Apple reviewers might ding the app.

What a pain - why not just allow it to work the way other apps work?

Sent from my iPhone

> On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
> 
> Thank you!
> 
> Sent from my iPhone
> 
>> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode
 wrote:
>> 
>> If you're referring to ios, look up "plist hack", here.  The only 
>> thing to remember is that for each version of LC, you have to perform 
>> the hack, again, until Edinburgh gives us a Standalone Settings option.
>> 
>> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode < 
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Having to restart the app from scratch sucks. I can store the 
>>> current state, but my users would have to wait for the map widget to 
>>> reload every time they came back from another app.
>>> 
>>> Sent from my iPhone
>>> ___
>>> 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


___
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: Is there any way at all to have a mobile app simply resume rather than restart?

[Jonathan Lynch via use-livecode]

It looks like the plist hack is not available in version 8. 

Choosing background audio works - but that means I need to have a plausible 
reason for having background audio or Apple reviewers might ding the app.

What a pain - why not just allow it to work the way other apps work?

Sent from my iPhone

> On May 24, 2017, at 3:43 PM, jonathandly...@gmail.com wrote:
> 
> Thank you!
> 
> Sent from my iPhone
> 
>> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode 
>>  wrote:
>> 
>> If you're referring to ios, look up "plist hack", here.  The only thing to
>> remember is that for each version of LC, you have to perform the hack,
>> again, until Edinburgh gives us a Standalone Settings option.
>> 
>> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Having to restart the app from scratch sucks. I can store the current
>>> state, but my users would have to wait for the map widget to reload every
>>> time they came back from another app.
>>> 
>>> Sent from my iPhone
>>> ___
>>> 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: Is there any way at all to have a mobile app simply resume rather than restart?

[Mike Kerner via use-livecode]

The other thing to remember is that you will have to command-drag the LC
app out of your Applications folder, modify it, then put it back (you can't
modify an application in the applications folder).

On Wed, May 24, 2017 at 3:43 PM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thank you!
>
> Sent from my iPhone
>
> > On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > If you're referring to ios, look up "plist hack", here.  The only thing
> to
> > remember is that for each version of LC, you have to perform the hack,
> > again, until Edinburgh gives us a Standalone Settings option.
> >
> > On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> Having to restart the app from scratch sucks. I can store the current
> >> state, but my users would have to wait for the map widget to reload
> every
> >> time they came back from another app.
> >>
> >> Sent from my iPhone
> >> ___
> >> 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
>



-- 
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: send mouseup to control

[Richard Gaskin via use-livecode]

Mark Wieder wrote:


On 05/24/2017 11:50 AM, Richard Gaskin via use-livecode wrote:
I'd go with executionContexts.  Are there circumstances where this 
wouldn't work?:


function CallerID
-- Line -1 = this function
-- Line -2 = the script that called this function
-- so:
return item 1 of line -3 of the executionContexts
end CallerID



That would work, but (to use the proper terminology) it has a code 
smell. It's first of all dependent on the executionContexts format if 
you're going to pick out the control ID, and while that format isn't 
likely to change even though undocumented, it seems like yet another 
level of dependency. There's already a dependence on having to know and 
IDs of the calling objects, so the mouseUp handler is dependent on the 
controls that might possibly call it. Any design change in the app might 
require modifying the mouseUp code.


True, it relies on data returned from the engine, and that the scripter 
using the function understands how to use it.


But those seem modest requirements.  I can't think of much in any 
language or library not exposed to those two potential weaknesses. :)


The executionContexts is documented, though in all fairness that Dict 
entry includes a note about not relying on the format of its contents. 
But a LOT of code in the LC universe currently depends on it, and the 
role it serves is essential for critical things like debugging.  And it 
hasn't changed in more than 15 years.


Given all that, for myself I find the trade-offs acceptable.  If the 
format changes down the road I certainly won't be the only person 
changing scripts to keep current.




Refactoring to remove the dependencies could look like:

on mouseUp
   -- what actually happens with a real mouse click
   doRealMouseStuff
end mouseUp

on handler1
   -- make a jazz noise here
end handler1

on handler2
   -- this space intentionally left blank
end handler2

-- in some other control...
-- dispatch "mouseUp" to controlWithHandlers -- deprecated
dispatch "handler1" to controlWithHandlers

Now the object with the handlers doesn't have to know a thing about any 
other controls that might call its handlers, and the external controls 
only need know that there is a "handler1" handler in that object. A 
judicious use of revAvailableHandlers() (again undocumented) could also 
be useful here.


I would be much more hesitant to rely on a function designed for IDE use 
like revAvailableHandlers, but even there we don't really have an 
alternative other than hand-crafing a slower replacement, so I use that 
one too (though in only one place in my dev tools).


As for the refactoring, so much depends on the particulars of the 
use-case.


Your outline above might be ideal if handling a specific number of 
objects/options.


But if the handler being called needs to know the caller ID for some 
purpose other than simple branching among a small number of options, 
factoring could range from tedious to impractical.


Like so much in code, it all depends on "Why" we need a given piece of 
information.



> Heh. Couldn't resist adding this:
> https://techbeacon.com/35-bad-programming-habits-make-your-code-smell

Fun read, and very relevant:  many of the items in that list appear to 
contradict others.  I don't see that as a bad thing.  Coding is a mix of 
knowing so-called "best practices", and knowing when to skip 'em. :)  As 
such, that list is an uncommonly realistic one.


Everything in a finite and imperfect universe involves trade-offs

--
 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: English Like?

[Alex Tweedly via use-livecode]

Then I'll confess that what I would actually do is

 - make them globals (??!!)

 - initialize them in the "on librarystack" handler of my standard 
(i.e. always used) library stack


 - and be comforted that my use of 'explicitvars' will ensure I know if 
they are not included as global in any script that uses them.


Now if only I could have "constant global"s I'd be (almost*) happy.

Alex.

* almost - because I'd then still grumble about not being able to do 
simple expressions in constant statements; e.g.  constant kSecsPerDay = 
60 * 60 * 24, kSpD = kSpM * kMpH * kHpD



On 24/05/2017 20:35, Mark Wieder via use-livecode wrote:

On 05/24/2017 12:25 PM, Alex Tweedly via use-livecode wrote:

constant kRectLeft = 1, kRectTop = 2, kRectRight = 3, kRectBottom = 4

(or whatever ... haven't looked it up :-)


Exactly the point.
I'd have to store this somewhere, and either grab it each time I need 
it or look it up and reinvent it each time.





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

Re: English Like?

[Roger Eller via use-livecode]

On Wed, May 24, 2017 at 12:47 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hehe - what an enjoyable post to read - I couldn't resist 'biting'
> on a few things though ;)
>
> On 2017-05-24 17:57, Richmond Mathewson via use-livecode wrote:
>
>> Probably most of those programmers (like many well-established
>> LiveCode programmers) have invested so much time and effort
>> in learning the high level language(s) they already use that they are
>> unlikely to switch.
>
>
> This is partly true - however, 'no man is an island', people develop
> preconceptions about things over time which influence the choices in
> the future.
>
> I think it would be fair to say there might well be some sort of general
> 'meme' which floats around with regards to 'English-like' languages
> and not necessarily a positive one.



Star Trek is the best advocate for English-like computing in the future.
And now Siri, Alexa, and Google Assistant have made it a reality.

Meme-like:  http://imgur.com/Dtp7IPQ

~Roger
___
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: Is there any way at all to have a mobile app simply resume rather than restart?

[Jonathan Lynch via use-livecode]

Thank you!

Sent from my iPhone

> On May 24, 2017, at 3:34 PM, Mike Kerner via use-livecode 
>  wrote:
> 
> If you're referring to ios, look up "plist hack", here.  The only thing to
> remember is that for each version of LC, you have to perform the hack,
> again, until Edinburgh gives us a Standalone Settings option.
> 
> On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Having to restart the app from scratch sucks. I can store the current
>> state, but my users would have to wait for the map widget to reload every
>> time they came back from another app.
>> 
>> Sent from my iPhone
>> ___
>> 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

Dropbox v1 API - one month until it is shut off!

[Mike Kerner via use-livecode]

Reminder, everyone using dropbox, you have until the end of June to get
your apps migrated to the v2 API before your dropbox functionality will
cease.  Rumor says that the Dropbox team is granting reprieves to people
who ask for them, but I don't know if that's for everyone for every app.

If you are using the phx_dropboxLib library, my advice is that you download
Gerard McCarthy's dropboxAPI_2 lib and get your code switched.  If you
don't already have it, I have it as a repo on github (
https://github.com/macMikey/dropboxapi_v2), both as a binary stack and as a
script-only stack, but it is available in a variety of places.

If you are using mergDropbox, I just sent a reminder to Edinburgh that
Monte has work to do, but I don't have an ETA.

-- 
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: Is there any way at all to have a mobile app simply resume rather than restart?

[Mike Kerner via use-livecode]

If you're referring to ios, look up "plist hack", here.  The only thing to
remember is that for each version of LC, you have to perform the hack,
again, until Edinburgh gives us a Standalone Settings option.

On Wed, May 24, 2017 at 3:22 PM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Having to restart the app from scratch sucks. I can store the current
> state, but my users would have to wait for the map widget to reload every
> time they came back from another app.
>
> Sent from my iPhone
> ___
> 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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 12:25 PM, Alex Tweedly via use-livecode wrote:

constant kRectLeft = 1, kRectTop = 2, kRectRight = 3, kRectBottom = 4

(or whatever ... haven't looked it up :-)


Exactly the point.
I'd have to store this somewhere, and either grab it each time I need it 
or look it up and reinvent it each time.


--
 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: English Like?

[Alex Tweedly via use-livecode]

constant kRectLeft = 1, kRectTop = 2, kRectRight = 3, kRectBottom = 4

(or whatever ... haven't looked it up :-)

Alex.


On 24/05/2017 18:27, Mark Wieder via use-livecode wrote:

The one that's always bugged me is

put item 2 of the rect of someObject into tVar

Rects have a defined order of items, and I can never remember whether 
it's "left,top..." or "top,left..." and I end up looking it up every 
time. I'd love to have a more normal (all right, English-like... 
there... I've said it) way to remember and write this.





___
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

Is there any way at all to have a mobile app simply resume rather than restart?

[Jonathan Lynch via use-livecode]

Having to restart the app from scratch sucks. I can store the current state, 
but my users would have to wait for the map widget to reload every time they 
came back from another app.

Sent from my iPhone
___
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: send mouseup to control

[Mark Wieder via use-livecode]

Heh. Couldn't resist adding this:

https://techbeacon.com/35-bad-programming-habits-make-your-code-smell

--
 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: send mouseup to control

[Mark Wieder via use-livecode]

On 05/24/2017 11:50 AM, Richard Gaskin via use-livecode wrote:

Mark Wieder wrote:

 > You could pull the information out of the executionContexts, but you'd
 > probably be better off with a bit of refactoring.

I'd go with executionContexts.  Are there circumstances where this 
wouldn't work?:



function CallerID
-- Line -1 = this function
-- Line -2 = the script that called this function
-- so:
return item 1 of line -3 of the executionContexts
end CallerID




That would work, but (to use the proper terminology) it has a code 
smell. It's first of all dependent on the executionContexts format if 
you're going to pick out the control ID, and while that format isn't 
likely to change even though undocumented, it seems like yet another 
level of dependency. There's already a dependence on having to know and 
IDs of the calling objects, so the mouseUp handler is dependent on the 
controls that might possibly call it. Any design change in the app might 
require modifying the mouseUp code.


Refactoring to remove the dependencies could look like:

on mouseUp
  -- what actually happens with a real mouse click
  doRealMouseStuff
end mouseUp

on handler1
  -- make a jazz noise here
end handler1

on handler2
  -- this space intentionally left blank
end handler2

-- in some other control...
-- dispatch "mouseUp" to controlWithHandlers -- deprecated
dispatch "handler1" to controlWithHandlers

Now the object with the handlers doesn't have to know a thing about any 
other controls that might call its handlers, and the external controls 
only need know that there is a "handler1" handler in that object. A 
judicious use of revAvailableHandlers() (again undocumented) could also 
be useful here.


--
 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: send mouseup to control

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

> You could pull the information out of the executionContexts, but you'd
> probably be better off with a bit of refactoring.

I'd go with executionContexts.  Are there circumstances where this 
wouldn't work?:



function CallerID
   -- Line -1 = this function
   -- Line -2 = the script that called this function
   -- so:
   return item 1 of line -3 of the executionContexts
end CallerID


--
 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: send mouseup to control

[Jonathan Lynch via use-livecode]

I just send the ID of the sending object as a parameter.

Sent from my iPhone

On May 24, 2017, at 1:58 PM, hh via use-livecode 
 wrote:

>> Alejandro T. wrote:
>> Reading LiveCode Dictionary about the target and send,
>> could not find an obvious way to get the name of a message
>> sender without putting first this name in another container
>> (a custom property, a field or a global variable).
> 
> Yet another option could be to use more parameters:
> -- b is the button number (obligatory)
> -- [b may be also misused for any positive integer]
> -- clicking the control with that handler leaves x empty
> on mouseUp b,x
> switch x
>case ...
>  break
>case ...
> ...
>default -- x is empty
>  -- the direct-click code, use b
>   end switch
> end mouseUp
> 
> 
> ___
> 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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 10:54 AM, Mike Kerner via use-livecode wrote:

like "put the left of someObject"?


Heh. Shoulda used a different example.

No, my problem is more with changing the rect of an object. Setting the 
left of an object has repercussions with respect to the other object 
parameters. If I explicitly want to store values into the rect then I 
have to use the "item 2" form.


--
 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: English Like?

[Lagi Pittas via use-livecode]

Bob,

You forget right upto Visual Foxpro 9, Fox still was backwards compatible
with Dbase 2 and still had the STORE statement.

STORE A TO B
STORE 1+15 to C
STORE 5 to a,b,,c,d
STORE "HELLO" to message

The HC and DBASE way  is the logical way to do it for mere mortals,  but
when the whole computer has  4K WORDS of magnetic backing store (IBM 704
that FORTRAN  was written on) you have to use concise syntaxt - a=b instead
of put a into B a 25% of the characters in this case.

Secondly if your output is paper -  Teletype 33 - 10 characters a second ,
that is another reason.

WE do things not because they are the best way but because in the past
there were limitations we have forgotten about.

To paraphrase  Max Planck:-

A programming  language does not triumph by convincing its opponents and
making them see the light, but rather because its opponents eventually die
and a new generation grows up that is familiar with it.

Regards Lagi



On 24 May 2017 at 18:54, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'll bite. One of the reasons that the heartbleed bug passed muster was
> because the code OpenSSL is written in is *not* easily human readable. It's
> hard enough to spot a bug in LC script. Being human readable makes it
> tolerable to debug by reading through code.
>
> The first time I encountered x = "123" in FoxPro, I thought to myself, "Is
> that a test that returns true or false? If so where is the result stored?"
> It isn't the least bit intuitive. And FoxPro/dBase WAS a scripting
> language, but they were inexorably tied to prior language conventions like
> Pascal, or else they feared "real programmers" would not adopt it.
>
> There is also the issue of pride. Everyone wants to think the decisions
> they made are the "best" decision that could have been made at the time. To
> acknowledge there *might* have been something better, or just other, that
> they could have adopted is personally offensive to some. To suggest it
> might be easier to develop in Livecode when they already are proficient in
> C or Java might seem like a criticism of past choices to many.
>
> Finally there is the fear of the unknown. The greatest difficuly I have
> trying to teach people how to work with OS X, is that having spent all the
> time and effort learning Windows, they imagine the same time and effort
> will be required to learn OS X. Of course anyone who knows both operating
> systems knows that is an irrational fear. Most of the things you learn
> about either OS is common to both. The same applies to software
> development. The principles are all in place. It's convention that differs.
>
> Bob S
>
>
>
> ___
> 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: send mouseup to control

[hh via use-livecode]

> Alejandro T. wrote:
> Reading LiveCode Dictionary about the target and send,
> could not find an obvious way to get the name of a message
> sender without putting first this name in another container
> (a custom property, a field or a global variable).

Yet another option could be to use more parameters:
-- b is the button number (obligatory)
-- [b may be also misused for any positive integer]
-- clicking the control with that handler leaves x empty
on mouseUp b,x
 switch x
case ...
  break
case ...
 ...
default -- x is empty
  -- the direct-click code, use b
   end switch
end mouseUp


___
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: send mouseup to control

[Richmond Mathewson via use-livecode]

Replied with demo stack on the Forums: 
http://forums.livecode.com/viewtopic.php?f=9=29290


Richmond.

On 5/24/17 8:21 pm, Alejandro Tejada via use-livecode wrote:

Hi All,

Reading LiveCode Dictionary about the target and send,
could not find an obvious way to get the name of a message
sender without putting first this name in another container
(a custom property, a field or a global variable).

Why do I need to know which control send a message
to another control?

Because the handler in the control executes different code
depending of which control sends it a mouseup handler.

For now, I am using a mouseup button parameter that
could be 1 or 2 or 3. If the control receive a mouseup with
parameter 1, then executes handler 1. If the mouseup is
received with a parameter 2 then control executes
handler 2.

Which other ways could I use to produce the same result?

Al
___
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: English Like?

[Mike Kerner via use-livecode]

like "put the left of someObject"?

On Wed, May 24, 2017 at 1:27 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 05/24/2017 08:11 AM, Martin Koob via use-livecode wrote:
>
>> I agree that LiveCode script should become more English like as time goes
>> on
>> not only with english words but also with more natural(or intuitive)
>> grammar.
>>
>> From your examples I think it would be more natural to type.
>>>
>>
>> put the third index of tNumericArray into tFoo
>>
>
> The one that's always bugged me is
>
> put item 2 of the rect of someObject into tVar
>
> Rects have a defined order of items, and I can never remember whether it's
> "left,top..." or "top,left..." and I end up looking it up every time. I'd
> love to have a more normal (all right, English-like... there... I've said
> it) way to remember and write this.
>
> --
>  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
>



-- 
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: English Like?

[Bob Sneidar via use-livecode]

I'll bite. One of the reasons that the heartbleed bug passed muster was because 
the code OpenSSL is written in is *not* easily human readable. It's hard enough 
to spot a bug in LC script. Being human readable makes it tolerable to debug by 
reading through code. 

The first time I encountered x = "123" in FoxPro, I thought to myself, "Is that 
a test that returns true or false? If so where is the result stored?" It isn't 
the least bit intuitive. And FoxPro/dBase WAS a scripting language, but they 
were inexorably tied to prior language conventions like Pascal, or else they 
feared "real programmers" would not adopt it. 

There is also the issue of pride. Everyone wants to think the decisions they 
made are the "best" decision that could have been made at the time. To 
acknowledge there *might* have been something better, or just other, that they 
could have adopted is personally offensive to some. To suggest it might be 
easier to develop in Livecode when they already are proficient in C or Java 
might seem like a criticism of past choices to many. 

Finally there is the fear of the unknown. The greatest difficuly I have trying 
to teach people how to work with OS X, is that having spent all the time and 
effort learning Windows, they imagine the same time and effort will be required 
to learn OS X. Of course anyone who knows both operating systems knows that is 
an irrational fear. Most of the things you learn about either OS is common to 
both. The same applies to software development. The principles are all in 
place. It's convention that differs. 

Bob S



___
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: English Like?

[Dr. Hawkins via use-livecode]

On Wed, May 24, 2017 at 10:27 AM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Rects have a defined order of items, and I can never remember whether it's
> "left,top..." or "top,left..." and I end up looking it up every time. I'd
> love to have a more normal (all right, English-like... there... I've said
> it) way to remember and write this.


You seem to be a bit  LTRBed by this . . .

:)

-- 
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: send mouseup to control

[Dr. Hawkins via use-livecode]

On Wed, May 24, 2017 at 10:21 AM, Alejandro Tejada via use-livecode <
use-livecode@lists.runrev.com> wrote:

> For now, I am using a mouseup button parameter that
> could be 1 or 2 or 3. If the control receive a mouseup with
> parameter 1, then executes handler 1. If the mouseup is
> received with a parameter 2 then control executes
> handler 2.
>



1) take a look at the values of "me" and "the target" once the handler
begins

2) I have plenty of buttons with the script, "dispatch the short name of me"

3) similar would be

send doIt && the short name of me to someObject



-- 
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: send mouseup to control

[Phil Davis via use-livecode]

Hi Al,

I wonder if the "call" command could simplify things for you. (Probably 
not but I thought I would mention it.)


Otherwise maybe put your mouseUp code in separate handlers outside of 
"mouseUp" so you can have more parameter options in their execution.


Thanks -
Phil Davis


On 5/24/17 10:21 AM, Alejandro Tejada via use-livecode wrote:

Hi All,

Reading LiveCode Dictionary about the target and send,
could not find an obvious way to get the name of a message
sender without putting first this name in another container
(a custom property, a field or a global variable).

Why do I need to know which control send a message
to another control?

Because the handler in the control executes different code
depending of which control sends it a mouseup handler.

For now, I am using a mouseup button parameter that
could be 1 or 2 or 3. If the control receive a mouseup with
parameter 1, then executes handler 1. If the mouseup is
received with a parameter 2 then control executes
handler 2.

Which other ways could I use to produce the same result?

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



--
Phil Davis


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

Re: send mouseup to control

[Mark Wieder via use-livecode]

On 05/24/2017 10:21 AM, Alejandro Tejada via use-livecode wrote:

Hi All,

Reading LiveCode Dictionary about the target and send,
could not find an obvious way to get the name of a message
sender without putting first this name in another container
(a custom property, a field or a global variable).

Why do I need to know which control send a message
to another control?

Because the handler in the control executes different code
depending of which control sends it a mouseup handler.

For now, I am using a mouseup button parameter that
could be 1 or 2 or 3. If the control receive a mouseup with
parameter 1, then executes handler 1. If the mouseup is
received with a parameter 2 then control executes
handler 2.

Which other ways could I use to produce the same result?


You could pull the information out of the executionContexts, but you'd 
probably be better off with a bit of refactoring. Instead of sending a 
mouseUp message, I'd send the handler 1 or handler 2 message directly.


--
 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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 08:11 AM, Martin Koob via use-livecode wrote:

I agree that LiveCode script should become more English like as time goes on
not only with english words but also with more natural(or intuitive)
grammar.


From your examples I think it would be more natural to type.


put the third index of tNumericArray into tFoo


The one that's always bugged me is

put item 2 of the rect of someObject into tVar

Rects have a defined order of items, and I can never remember whether 
it's "left,top..." or "top,left..." and I end up looking it up every 
time. I'd love to have a more normal (all right, English-like... 
there... I've said it) way to remember and write this.


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

send mouseup to control

[Alejandro Tejada via use-livecode]

Hi All,

Reading LiveCode Dictionary about the target and send,
could not find an obvious way to get the name of a message
sender without putting first this name in another container
(a custom property, a field or a global variable).

Why do I need to know which control send a message
to another control?

Because the handler in the control executes different code
depending of which control sends it a mouseup handler.

For now, I am using a mouseup button parameter that
could be 1 or 2 or 3. If the control receive a mouseup with
parameter 1, then executes handler 1. If the mouseup is
received with a parameter 2 then control executes
handler 2.

Which other ways could I use to produce the same result?

Al
___
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: English Like?

[Mark Wieder via use-livecode]

On 05/24/2017 08:03 AM, Mark Waddingham via use-livecode wrote:

Anyway, I shall now get off my (small?) soap-box. Again this is a 
discussion, there are lots of reasons why people don't choose LiveCode 
and we try our very best to determine them, and deal with them. There 
are certainly easier ones to tackle than adding a new 'syntax style' and 
of course we intend to address those first...


I just want to say that in spite of all the verbiage that showed up 
overnight, this has been a most enjoyable thread to wake up to.


--
 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: Sql problem

[Bob Sneidar via use-livecode]

My problem with that is that I use sqlYoga in a fairly complex app. How would I 
incorporate sqlYoga calls with a web interface and still retrieve the data in 
the same format as I currently have? If I cannot do that, then the burden of 
refactoring the entire application would be considerable. 

Bob S


> On May 23, 2017, at 17:53 , Andre Garzia via use-livecode 
>  wrote:
> 
> William,
> 
> You could but it is not a good security practice to expose a mysql database
> to the larger internet. The internet is very hostile and keeping your mysql
> server safe would be a job on its own. Best you use your php cgi or
> anything else to put a wall between your database and the net.
> 
> Never, ever, expose a database server. Thats a golden rule. Now, if you're
> building something that is for internal use on a LAN, business network,
> intranet, then the rules are different, even though, even in this case, I
> would put something in front of the database if it was up to me to make
> such decision.
> 
> Cheers
> andre
> 
> 
> -- 
> http://www.andregarzia.com -- All We Do Is Code.
> http://fon.nu -- minimalist url shortening service.


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

Re: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-24 18:44, Mark Wieder via use-livecode wrote:
As I said before, the lack of switch in LCB isn't because we don't 
want

a construct like that; just that we'd like one which doesn't have the
issues of C-style switch. (The best way to avoid people accidentally
introducing subtle bugs, is to ensure the language is designed to not
let them do so!)


It's *always* possible to introduce bugs, subtle or not. The best way
to avoid that is not to allow people to code 


Hehe - well that is certainly true - no one can argue with that!

Of course it is always possible to introduce bugs, but when you have
a control structure with a syntax which is almost begging for people
to make mistakes with it - surely it is worth considering how it could
be restructured to prevent that?

Indeed, the evidence that there is a problem here is held up by the
fact that more recent C compilers have explicit warnings which tell you 
about

potential errors in your switch statements - indeed, IIRC, there is even
a way to mark *explicit* fall-through in recent GCC or clang so that
you don't get a warning (which is important if you compile your code
with warnings-as-errors - we've started to turn more and more warning
flags into errors on our codebase to make sure that we don't introduce
the errors they warn about).

Generally compiler writers aren't going to spend time adding warnings
for things which *aren't* a common problem in end-user code - there's
far too many other fish to fry. So I generally think that if something 
in a

language design requires compiler writers to add explicit warnings
about potential problems in a construct then it suggests the construct
is perhaps not as good as it could be.

Warmest Regards,

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: English Like?

[Mark Waddingham via use-livecode]

Hehe - what an enjoyable post to read - I couldn't resist 'biting'
on a few things though ;)

On 2017-05-24 17:57, Richmond Mathewson via use-livecode wrote:

Probably most of those programmers (like many well-established
LiveCode programmers) have invested so much time and effort
in learning the high level language(s) they already use that they are
unlikely to switch.


But if we can make them switch, that benefits LiveCode as a whole.


From a marketing point of view I believe that this question is more
pressing than the other one, just because people new to coding have
not got stuck in the groove of a particulalr programming language.


This is partly true - however, 'no man is an island', people develop
preconceptions about things over time which influence the choices in
the future.

I think it would be fair to say there might well be some sort of general
'meme' which floats around with regards to 'English-like' languages
and not necessarily a positive one.

Ergo - someone who has never been a programmer, who perhaps is thinking
of dabbling, might get put off by LiveCode because of its language, just
because they have that 'meme' embedded in that psyche without even 
trying

it properly.


What does need to be born in mind is that most of LiveCode's installed
user-base like their pudding the way LiveCode serves,
and changing the recipe to attract other people might only serve to
alienate current users rather than attarct others;
probably not worth the risk.


So we must make sure that the 'pudding' our current user-base isn't
diluted in the process. Most companies might start out producing only 
one
kind of 'pudding', but if they never diversify they risk ceasing to be 
at some
point when some other company produces 'pudding+' which people like 
better;
or if they can no longer produce 'pudding' because some 'nanny' decides 
that

a key ingredient should not be allowed anymore for the health of all.

Having all your eggs in one basket is a little risky...


My school now runs at exactly the size I want it to; those 'factories'
still run. Nobody, as far as I can tell, feels threatened by my
operation,
and I don't feel threatened by them. This is because, although we all
"sell" English as a Foreign Language, we do it in different ways; and
the children who come to my school are quite unlike those who go to
the other ones (which suits me 100%). There is room in the
multiverse of EFL for a variety of products.


It is great that you've reached a 'steady state' with your EFL school :)

However, it is perhaps fair to say that the world of EFL teaching does
not move at quite the same rate as the world of computers, there are 
lots
of very large 'pudding behemoths' out there who care not one whit for 
small
'pudding' manufacturers - and quite often trample them under foot 
without

a moment's thought.

I would also conjecture that the infrastructure requirements for our
particular kind of 'pudding' are somewhat larger than for a single
successful EFL school - and when combined with the fast paced 
environment
our 'pudding' is couched in, one needs to be careful that one can 
support

one's 'pudding' manufacture now and into the long term future.


No: a lot of the syntax isn't English-like, and the claims that have
been flying around about that ever since HyperCard seem almost
as crook as the "programming is easy" porky.


I agree with the statement that 'programming is easy' in general is a 
bit of a porky.


Most things are not easy when you get below a certain depth (kind of a 
tautology,

easy things generally being quite shallow in any domain).

However, I am firmly in the belief that many of the reasons why it is 
not 'easy'
right now are not because they could not be easier, but because like 
most
industries there is a huge inertia with how things are currently done 
and
when you are in the midst of doing something, you have to get it done, 
and perhaps

thinking about 'how to make it easier' is a distant thought.

In general I'd like to think that LiveCode does make some things easier 
than

other languages - and, in general, it is going in the right direction.


In regards to 'English-like' - then well let's just say LiveCode is 
'fibbidy-dab'
if 'English-like' is considered too inaccurate. In comparison with 
pretty much
ever other programming language which exists today and is still 
maintained,
I'd say LiveCode is significantly more 'English-like' than any of them 
thus

justifying its tag of 'English-like' ;)



"Intuitive" . . . ha, ha, ha. Human languages are not intuitive:
otherwise we'd all be learning a new language every 3 or 4 weeks
and the Tower of Babel wouldn't look like Trump Tower!


Indeed - human languages have evolved organically - but they have some
nice properties which most programming languages do not (particularly
in terms of how they reflect, at least in some part, how our brains
would appear to work - being something which has resulted from our 
brains

rather than the 

Re: Writing Extensions

[Mark Wieder via use-livecode]

On 05/24/2017 03:25 AM, Mark Waddingham via use-livecode wrote:

The use-case which causes subtle bugs and errors is where one case 
requires a 'bit more code' before the others (where code, fallthrough, 
code is *not* erroneous but intended) - also it is a rarely used pattern 
in C (because it is difficult to maintain).


I hesitate to get into religious wars here (especially with you, because 
there's no way I'd end up on top ) but...


I use switch statements all the time. All the time. I utilize the 
fallthrough mechanism where it's useful to avoid repeating code and I've 
just gotten into the habit of writing a break statement immediately 
after writing a case statement, so I (mostly) keep out of trouble that way.


That said, the "problem" with switch statements is exactly what you have 
laid out, user errors with forgetting the break statement.




Taking this into account, then perhaps a better solution would be 
('choose' used here for the sake of argument):


   choose tValue
 when 1
 when 2
 when 3
   -- executes if tValue is 1, 2 or 3
   -- never falls through

 when 4
   -- never falls through

 default
   end choose

This caters for both cases (1) and (2) and is unambiguous.



ruby implements almost exactly this syntax ("case" instead of "choose", 
but otherwise):


case x
when "a", "b"
puts "a or b"
when "c"
puts "just c"
else
puts "something else"
end

while python doesn't have a switch construct as such, dictionaries 
neatly provide the same functionality in a possibly more readable and 
maintainable form (here as a function):


def f(x):
return {
'a': 1,
'b': 2,
}[x]

> As I said before, the lack of switch in LCB isn't because we don't want
> a construct like that; just that we'd like one which doesn't have the
> issues of C-style switch. (The best way to avoid people accidentally
> introducing subtle bugs, is to ensure the language is designed to not
> let them do so!)

It's *always* possible to introduce bugs, subtle or not. The best way to 
avoid that is not to allow people to code . The idea of a "continue" 
statement to force a fallthrough is intriguing, although I can't get the 
unwanted images of Cobol out of my mind. I do like the idea of having 
the language guide users to preventing errors, and possibly the ruby 
syntax with the continue statement might be the best way forward. In 
that case (heh...) I'd also like the syntax to allow for


case x
when someFunctionThatReturnsAorB()
puts "a or b"
else
puts "something else"
end

--
 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: breakpoint on parameter

[Mark Wieder via use-livecode]

On 05/24/2017 08:23 AM, Mark Waddingham via use-livecode wrote:

Right now, though there might be a way in the IDE by using an IDE 
mechanism - the IDE has an API allowing an object to subscribe to a 
message when any properties of that object change:


   revIDESubscribe "idePropertyChanged", 

The idePropertyChanged message gets sent to the object which calls 
revIDESubscribe. In that handler you can inspect the malfunctioning 
object's properties.


That's a clever solution. And there's a corresponding revIDEUnsubscribe 
message as well as a revIDEUnsubscribeAll for when you're done. I don't 
believe any of these are documented, but they're useful and, in my case 
at least, essential.


For now the subscribe messages are limited to a predefined set of IDE 
messages, but the long-term plan as I understand it is to open up the 
mechanism to allow for user-defined messages as well.


--
 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: English Like?

[Richmond Mathewson via use-livecode]

On 5/24/17 6:19 pm, prothero--- via use-livecode wrote:

Ok,ok, I hear y'all about the approachability of the htalk language. I do know that when 
we get familiar with an intellectual construct, we tend to give validity to information 
or attitudes that agree with that construct. Confirmation bias seemed to be a huge factor 
in news "facts" acceptance in the recent US election, as well.

As to the subject at hand, experienced programmers are going to favor 
constructs they are already familiar with.


Yup: but that is has no more objective validity than people from the 
British Isles favoUring different spelling conventions.


Whether someone spells the word "quha" or "who" is, ultimately neither 
here nor there. If I were ti hire a computer programmer to do a job
I would be concerned whether that programmer could produce a finished 
product for me that looked and functioned the way I wanted
it to: I really wouldn't give a tuppeny toss which language/development 
environment s/he used to achieve that.



  It will not be possible to settle the question of whether using x=3 or put 3 
into x is more logical using this audience. In addition, the question is 
ill-posed.
This question is about a matter of taste, not logic, and those who think 
that it refers to logic are unaware of how they have let
themselves be lulled into accepting one way of doing things as "the 
logical way".



One question is whether programmers experienced in other high level languages 
would find livecode an attractive option for their work.


Probably most of those programmers (like many well-established LiveCode 
programmers) have invested so much time and effort
in learning the high level language(s) they already use that they are 
unlikely to switch.



Or conversely, would people new to coding find htalk easy and intuitive?


From a marketing point of view I believe that this question is more 
pressing than the other one, just because people new to coding have not 
got stuck in the groove of a particulalr programming language.


The other day I revived my BBC Master Compact that I bought in 1989 and 
started doing some programming on it and was both surprised and 
enlightened that I took quite some time to get up to speed after some 27 
years not touching BBC BASIC.


Surprised because I had not realised how much the "LiveCode way" had 
permeated my way of doing things.


Enlightened because I began to remember what life was like before 
HyperCard, Graphic User Interfaces and all the stuff we now all

too readily take for granted with computers.

I'm trying to get a FORTRAN IV ROM chip to install in my BBC . . . .

  These are two different questions and a rigorous answer will most likely not 
come from knowledgeable livecode programmers. No insult is intended, as I 
accept that I am guilty of the same bias.

In my humble opinion, the proof is in the pudding.


Indeed: and different people like different puddings.

What does need to be born in mind is that most of LiveCode's installed 
user-base like their pudding the way LiveCode serves,
and changing the recipe to attract other people might only serve to 
alienate current users rather than attarct others;

probably not worth the risk.

For those who like salt in their porridge there's LiveCode, and for 
those who prefer sugar, or syrup, or prunes in their porridge

there are other puddings on offer.

When I started my EFL school in Bulgaria 12 years ago I was "up against" 
4 major 'factory' EFL schools, and people were telling me all sorts
of "good" advice as to how I should drive them out of business and 
become "Mr English" in the town. I didn't listen.


My school now runs at exactly the size I want it to; those 'factories' 
still run. Nobody, as far as I can tell, feels threatened by my operation,
and I don't feel threatened by them. This is because, although we all 
"sell" English as a Foreign Language, we do it in different ways; and
the children who come to my school are quite unlike those who go to the 
other ones (which suits me 100%). There is room in the

multiverse of EFL for a variety of products.


  What can I build with this application and how easy will it be to build what 
I want? I may prefer other syntaxes, but what the heck?


Well, there are probably nearly as many variables to be weighed up as 
there are potential LiveCode programmers; here's one more:


1. Can I afford the necessary time needed to get reasonably competent at 
programming in LiveCode and will that be justifiable

   when I can develop my next-big-thing in language X that I already know?


  As long as I can find what I need to make what I want, and have this fantastic array of 
users who help me out, I'm a very happy camper. So, for a bottom line, I really don't 
give a hoot about the "put 3 into x" syntax as long as I can build what I want. 
My initial posting was to comment that a LOT of the syntax for important operations is 
neither English-like, nor intuitive.


No: a lot of the 

[ANN] This Week in LiveCode 83

[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 #83 here: https://goo.gl/rRF66V

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: English Like?

[Roger Eller via use-livecode]

On Wed, May 24, 2017 at 11:03 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-05-24 15:45, dunbarx via use-livecode wrote:
>
>> There is a far more important issue here. New learners are far more
>> likely to
>> be coaxed into continuing to spend the time and effort, and to put away
>> their fears, if they see and use "put x into y". It is why we have stacks
>> and cards, and in the olden days, rolodexes. The original HC team did all
>> that on purpose.
>>
>
>
> I think a lot of us get hung up on the syntax (even me - who will always
> be quick to point out that 'syntax is just sugar' in many situations - I'm
> a polyglot when it comes to programming languages but many people are not
> and never will be). I can certainly say that whilst I am in the position I
> am in, I will not see LiveCode Script become some sort of syntactic mongrel
> (indeed the places where it is slightly 'mongrelic', I would quite like to
> have alternative non-mongrel forms much more in keeping with the language
> as a whole). However, again, there is more to LiveCode than just the syntax
> of the language.
>
> Anyway, I shall now get off my (small?) soap-box. Again this is a
> discussion, there are lots of reasons why people don't choose LiveCode and
> we try our very best to determine them, and deal with them. There are
> certainly easier ones to tackle than adding a new 'syntax style' and of
> course we intend to address those first...
>
> However, let us imagine that we were able to demonstrate that a
> significant proportion of people who might use LiveCode end up not doing so
> because of the language itself, and *if* the language had a different
> syntactic style then we would have significantly more users... Then surely
> it is worthy of some discussion and consideration?
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>

Firstly, THANK YOU for standing on that small soap-box, Mark.  LC and it's
English-likeness is well worth defending, IMHO.  I wouldn't be here if it
were too much more like 'standard' programming languages.  The great thing
about LC for those who prefer the more arcane syntax is they can fork it
and make it their own.  Yay OSS!

~Roger
___
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: English Like?

[Martin Koob via use-livecode]

I agree that LiveCode script should become more English like as time goes on
not only with english words but also with more natural(or intuitive)
grammar.

>From your examples I think it would be more natural to type.

   put the third index of tNumericArray into tFoo

OR

put the backColor of control "foo" into tVarBackColor

(in this example have the engine know it has to get the long id of control
"foo" to access the backColor than for the programmer to remember to assign
it first.)

Often when I am typing a script and I am not sure how to do it I wing it
first to see if what I intuitively write will work.   If that fails then go
to the dictionary or then forums.   

One example is the following.

I wanted a button in a group to access a property of the group so I typed.

   put the width of this group into tWidth.

When I apply that in the script editor it shows no errors but when I run it
it stops with the following error:

 (Chunk: can't find background)

The above line would work if I used card or stack instead of group.  In this
case I had to put.

   put the width of the owner of me into tWidth

So that is grammatically English but not the way I intuitively thought of it
and the sentence is a little unnatural.

I can fake a more natural sentence using a function to hide the way of
accessing the group to get it to read better.

   put the width of this_Group() into tGroupWidth

   function this_Group
  return the owner of me
   end this_Group

It would be nice if this is the direction of the language.

My nickel's* worth.  

* in Canada we ditched the penny a couple of years ago so every purchase is
rounded to the nearest nickel. :-)

Martin


Mark Waddingham via use-livecode wrote
> Of course, LiveCode syntax isn't perfect - it has [] for array access 
> for example - it might be nice to be
> able to do:
> 
> put index 3 of tNumericArray into tFoo
> put the foo of tAssocArray into tBar
> 
> Which is perhaps the way I'd suggest the language should go - replacing 
> what we currently use symbols (operators) for with 'English-like' forms.
> 
> It should be noted in all of this that syntax is just sugar (but don't 
> take that as meaning that sugar isn't important - if you forget the 
> sugar in recipes you often end up with inedible things). A handler such 
> as:
> 
>command Foo
>  put the long id of control "Foo" into tVar
>  put the backColor of tVar into tVarBackColor
>  set the backColor of char 3 to 5 of field 3 to tVarBackColor
>end Foo
> 
> 
> Just my two pence :)
> 
> Warmest Regards,
> 
> Mark.
> 
> 
> 
> -- 
> Mark Waddingham ~ 

> mark@

>  ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list

> use-livecode@.runrev

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





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/English-Like-tp4714951p4715152.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: breakpoint on parameter

[Mark Waddingham via use-livecode]

On 2017-05-23 17:45, Richard Gaskin via use-livecode wrote:

Matt Maier wrote:

I want to find out which parts of my code are making changes to a
control's parameter. Specifically, I've got an arrow that I want
to be black, and it is black when it's created, but then it turns
gray. I can't find the script that's turning it gray.

I don't know where to put a breakpoint in the script.

Can I put a breakpoint on that control's color parameter, so execution
stops whenever something modifies it and goes to the script that's
doing the modification?


There's a request to allow getProp and setProp for built-in object 
properties:

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

I would imagine this is a non-trivial request, given what I'm guessing
would be performance penalties.


I don't think the performance penalty is necessarily an issue any more 
(see forum thread I posted in another reply).


I did something years ago to how handlers in the message path worked 
(changed the search from linear to binary-per-handler-type) - I didn't 
think anything of it at the time (didn't even mention it). However, it 
has vastly reduced the overhead of dispatching a message through the 
message path.


Now, there are potentially other dragons lurking there with the request 
- in terms of interpretation of tokens which the engine reserves to 
itself, and the order in which the engine does things currently. I'd be 
a little concerned that either might cause significant 
backwards-compatibility issues. However, that just means it needs more 
thought and validation.



Perhaps Mark Waddingham could offer insight on this.


In terms of the original question - it is certainly worth of a 
enhancement request (to hook up a debug message for 'control property 
changed' situation, like we have one for variables).


Right now, though there might be a way in the IDE by using an IDE 
mechanism - the IDE has an API allowing an object to subscribe to a 
message when any properties of that object change:


  revIDESubscribe "idePropertyChanged", 

The idePropertyChanged message gets sent to the object which calls 
revIDESubscribe. In that handler you can inspect the malfunctioning 
object's properties.


It might not be fine-grained enough (the engine coalesces such messages 
otherwise they would flood the IDE and grind things to a halt) - but it 
*might* give you some insight.


Warmest Regards,

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: English Like?

[prothero--- via use-livecode]

Ok,ok, I hear y'all about the approachability of the htalk language. I do know 
that when we get familiar with an intellectual construct, we tend to give 
validity to information or attitudes that agree with that construct. 
Confirmation bias seemed to be a huge factor in news "facts" acceptance in the 
recent US election, as well.

As to the subject at hand, experienced programmers are going to favor 
constructs they are already familiar with. It will not be possible to settle 
the question of whether using x=3 or put 3 into x is more logical using this 
audience. In addition, the question is ill-posed. One question is whether 
programmers experienced in other high level languages would find livecode an 
attractive option for their work. Or conversely, would people new to coding 
find htalk easy and intuitive? These are two different questions and a rigorous 
answer will most likely not come from knowledgeable livecode programmers. No 
insult is intended, as I accept that I am guilty of the same bias.

In my humble opinion, the proof is in the pudding. What can I build with this 
application and how easy will it be to build what I want? I may prefer other 
syntaxes, but what the heck? As long as I can find what I need to make what I 
want, and have this fantastic array of users who help me out, I'm a very happy 
camper. So, for a bottom line, I really don't give a hoot about the "put 3 into 
x" syntax as long as I can build what I want. My initial posting was to comment 
that a LOT of the syntax for important operations is neither English-like, nor 
intuitive.

The reason I moved to Livecode was its capabilities, multiple platform 
deployment, but mostly the potential of the development team and the dynamic 
way they are improving the product and keeping up as technology continues to 
evolve. The refactoring of a very mature code base was a very positive 
development, in my view. The responsiveness and engagement of the development 
team is another huge positive for me.

One of the sayings among academic departments is that "the battles are so 
fierce because the stakes are so small". The discussion is fun and interesting, 
but ... maybe less important.

Off to breakfast on a foggy Santa Barbara morning.

Best,
Bill P

William Prothero
http://es.earthednet.org

> On May 24, 2017, at 7:13 AM, Mike Kerner via use-livecode 
>  wrote:
> 
> That is certainly true.  The approachability of the language is the hook
> that got me hooked, even though HC was my...8th?  9th?  15th? language.
> For beginners, we should be asking what else we can do to make their life
> easier.  Community is free and it gets you in, but you can't build even the
> simplest ios app without paying apple and then fighting through all of the
> other things you have to do to get the app built and on your device just so
> you can play with it.  That would be a nifty service to provide for
> learning.  The n00b would have to upload their stack, and the ID of the one
> device they want to mess with it on.  Hmm..
> 
> On Wed, May 24, 2017 at 9:45 AM, dunbarx via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> There is a far more important issue here. New learners are far more likely
>> to
>> be coaxed into continuing to spend the time and effort, and to put away
>> their fears, if they see and use "put x into y". It is why we have stacks
>> and cards, and in the olden days, rolodexes. The original HC team did all
>> that on purpose.
>> 
>> Remember "for the rest of us"?
>> 
>> Experienced users are being academic and pedantic to raise this issue as if
>> it were something important. We need new users, not old ones.
>> 
>> No offense, please.
>> 
>> Craig Newman
>> 
>> 
>> 
>> --
>> View this message in context: http://runtime-revolution.2783
>> 05.n4.nabble.com/English-Like-tp4714951p4715143.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
>> 
> 
> 
> 
> -- 
> 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: breakpoint on parameter

[Mark Waddingham via use-livecode]

On 2017-05-23 17:57, Mark Wieder via use-livecode wrote:

On 05/23/2017 08:45 AM, Richard Gaskin via use-livecode wrote:


There's a request to allow getProp and setProp for built-in object
properties:
http://quality.livecode.com/show_bug.cgi?id=3126


...and it's from  2005, rev version 2.6...


The ball was dropped on that one somewhat:

  http://forums.livecode.com/viewtopic.php?f=66=14819

Monte submitted a PR, which kinda got lost in the huge behemoth that was 
the refactor. Definitely something to revisit at some point.


Of course, the fact I've still not managed to figure out a solution to:

  http://forums.livecode.com/viewtopic.php?f=66=18048

Irks me greatly.

Warmest Regards,

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: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-24 15:45, dunbarx via use-livecode wrote:
There is a far more important issue here. New learners are far more 
likely to

be coaxed into continuing to spend the time and effort, and to put away
their fears, if they see and use "put x into y". It is why we have 
stacks
and cards, and in the olden days, rolodexes. The original HC team did 
all

that on purpose.


Which 'new learners'? I can absolutely assure you there is no homogenous 
group there.


At one point after years of collecting surveys and analysing data we 
managed to divide up users and non-users into 7 (or thereabouts) 
distinct groups. Recently, taking a slightly different approach we have 
reduced this to 3 (7 was too fine-grained to actually be able to do much 
with, 3 is more manageable and seems to work much better in terms of 
targetting).


Why have we done this - because we need to actually *sell* LiveCode - 
nothing sells itself. Market segmentation and understanding your users 
and potential users is perhaps the most significant piece of selling.


( Okay, that's my marketing brain cell exhausted for a while ;) ).

It is quite possibly true that as many people get put off by LiveCode 
because of its 'English-like' language, who get sucked in because of it. 
We have to concede that point - if it weren't (at least in some part) 
true we wouldn't hear such phrases as 'babyish' and 'insult to 
intelligence' that are often heard about xTalks (and LiveCode in 
particular).


(Btw, @WilliamProthero: Please don't think I'm singling your comments 
out or taking offense by them - you echo words I have heard many times - 
as have all of us I suspect when we get asked by some - 'so what's 
LiveCode like').



Remember "for the rest of us"?

Experienced users are being academic and pedantic to raise this issue 
as if

it were something important. We need new users, not old ones.

No offence, please.


No offence taken - it is a discussion :)

However, it is important to realize that whilst it is not important to 
you (I get you are quite invested in LCS - as am I, much more than is 
ever apparent at times), it *is* important to others (otherwise we 
wouldn't get some comments about the language that we do).


Syntax is an emotive issue (I could beat Python to death with some of 
the decisions they have made about syntax - but yet I still use it and 
slightly enjoy doing so for the purposes I use it for) - but it is not 
the be-all-and-end-all.


I mentioned in my last post about the 'high priest' mentality - let us 
not risk falling into the same mentality but in reverse. The time for 
being an island in our own right passed with the passing of HyperCard. I 
think it is fair to say that, these days the world of computing is 
inordinately larger and much more diverse (look at the rise in the 
HTML/JavaScript world for just one example). There is huge value in 
being 'maverick', but it perhaps makes things much harder than they 
would be otherwise.


In reality the scripting language LiveCode has, whilst one of its 
greatest strengths IMHO (otherwise I can quite honestly say I wouldn't 
be here), is only one part of the ecosystem:


  - we have an interactive IDE which allows to edit and run code 'live' 
(for some definition of live)


  - we have a large GUI framework

  - we have large collections of libraries (script, externals, LCB) all 
giving high-level access to new

features

  - in order to build and maintain LiveCode we have a large 
infrastructure which allows us to build

on 7 different platforms.

Furthermore, we all want more features - we all want LiveCode to do 
everything in a way commensurate with how LiveCode 'is'. However, the 
breadth of knowledge that requires is immense - we do quite well as a 
team, sitting here (mostly in Scotland), we also do well as a (small, in 
the grand scheme of things) global community. Our current solution to 
help achieve this 'doing everything goal' is LCB and expanding its FFI 
capabilities - but that is a tool - it still needs knowledge and a great 
deal of effort to use.


We need to attract people from other worlds, and as many as possible - 
in there heads lies so much knowledge about how to use the concrete 
things which do exist in other language ecosystems (whether it be 
JavaScript libraries, Java libraries, C# libraries, ActiveX widgets, the 
list goes on and on) it seems quite sensible to ensure that we can fold 
that knowledge into our own so we can benefit from all that currently 
exists, and not just what a team of a few can generate, or a small 
community can generate.


Pre-7 what I suggested in my previous email was just not possible (in 
terms of a different syntax style) - or, should I say, the cost of 
attempting to do it would be far in excess of its potential benefit at 
the time. However, the main part of the refactor is done, we are in a 
very different situation technically - perhaps it really is something to 
seriously consider *if* the cost of doing 

Re: English Like?

[Mike Kerner via use-livecode]

The problem with this idea is the need to register the device through
apple's developer portal, but I wonder if testFlight could be leveraged to
make that work.  TestFlight apps are time-limited, so that takes care of
that problem...

On Wed, May 24, 2017 at 10:13 AM, Mike Kerner 
wrote:

> That is certainly true.  The approachability of the language is the hook
> that got me hooked, even though HC was my...8th?  9th?  15th? language.
> For beginners, we should be asking what else we can do to make their life
> easier.  Community is free and it gets you in, but you can't build even the
> simplest ios app without paying apple and then fighting through all of the
> other things you have to do to get the app built and on your device just so
> you can play with it.  That would be a nifty service to provide for
> learning.  The n00b would have to upload their stack, and the ID of the one
> device they want to mess with it on.  Hmm..
>
> On Wed, May 24, 2017 at 9:45 AM, dunbarx via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> There is a far more important issue here. New learners are far more
>> likely to
>> be coaxed into continuing to spend the time and effort, and to put away
>> their fears, if they see and use "put x into y". It is why we have stacks
>> and cards, and in the olden days, rolodexes. The original HC team did all
>> that on purpose.
>>
>> Remember "for the rest of us"?
>>
>> Experienced users are being academic and pedantic to raise this issue as
>> if
>> it were something important. We need new users, not old ones.
>>
>> No offense, please.
>>
>> Craig Newman
>>
>>
>>
>> --
>> View this message in context: http://runtime-revolution.2783
>> 05.n4.nabble.com/English-Like-tp4714951p4715143.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
>>
>
>
>
> --
> 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."
>



-- 
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: English Like?

[Mike Kerner via use-livecode]

That is certainly true.  The approachability of the language is the hook
that got me hooked, even though HC was my...8th?  9th?  15th? language.
For beginners, we should be asking what else we can do to make their life
easier.  Community is free and it gets you in, but you can't build even the
simplest ios app without paying apple and then fighting through all of the
other things you have to do to get the app built and on your device just so
you can play with it.  That would be a nifty service to provide for
learning.  The n00b would have to upload their stack, and the ID of the one
device they want to mess with it on.  Hmm..

On Wed, May 24, 2017 at 9:45 AM, dunbarx via use-livecode <
use-livecode@lists.runrev.com> wrote:

> There is a far more important issue here. New learners are far more likely
> to
> be coaxed into continuing to spend the time and effort, and to put away
> their fears, if they see and use "put x into y". It is why we have stacks
> and cards, and in the olden days, rolodexes. The original HC team did all
> that on purpose.
>
> Remember "for the rest of us"?
>
> Experienced users are being academic and pedantic to raise this issue as if
> it were something important. We need new users, not old ones.
>
> No offense, please.
>
> Craig Newman
>
>
>
> --
> View this message in context: http://runtime-revolution.2783
> 05.n4.nabble.com/English-Like-tp4714951p4715143.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
>



-- 
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: Writing Extensions

[Mike Kerner via use-livecode]

It's just difficult to get my brain wrapped around it, still.  Elanor's
course (that I think still has not been released to the public) was a help,
but more of that is needed, since we aren't in your brain.

On Wed, May 24, 2017 at 9:21 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-05-24 14:55, Mike Kerner via use-livecode wrote:
>
>> On the CompileIt thoughts, that was what I was hoping we were going to get
>> with LCB (We already have Double-XX).  You could make any Mac Toolbox call
>> in CompileIt, which meant you could build any XCMD/XFCN to add to your
>> stack, but the syntax was still HC (with some restrictions).
>>
>
> LCB already has the ability to call C functions - which is what CompileIt
> allowed you to do (as far as I understand). However, there is a fair bit of
> glue required to deal with things like C arrays (which are just pointers at
> the end of the day) and structs - that is something we would like to make
> much easier.
>
> [ That being said, many C APIs are moving towards 'opaque pointers with
> accessor functions' rather than exposing C-bound concepts - mainly because
> that way it is much easier to bind to 'higher-level' languages (Python,
> Ruby, JavaScript etc.) - which just mean you have to deal with opaque
> pointers. ]
>
> What we don't have is much documentation as to *how* to use the features
> which already exist. Although there is some usage of the feature littered
> about in some of the engine LCB files, I can appreciate that is not that
> easy to grok.
>
> We also have an almost complete Java FFI system - Ali is currently working
> on the final piece: adding 'Listener' support (essentially callbacks) which
> the Android APIs use ubiquitously - e.g. for event handlers on Views.
>
> I can attest to the fact that LCB FFI (for C) works - our LCFM plugin is
> written in LCB and the FM Plugin API is wrapped in LCB using the current C
> FFI features which are available (doing so has given me some more ideas
> about how to make such things easier *and* safer - which is a critical
> factor these days).
>
> For Mac / iOS APIs we need to add a way to wrap an Obj-C object, and
> implement a Delegate (although you can manipulate Obj-C objects through a C
> API so technically you can do this already, if you don't mind a bit of bit
> munching). However, now we have done Java, Obj-C should follow very
> quickly. Both Obj-C objects and Java objects have very similar (abstract)
> properties in terms of how you access from from native code; and Listeners
> and Delegates are very similar things also.
>
> In terms of actually compiling stuff to native code - it is a goal we
> have; but there are a few more ducks to get in a row before it can become a
> reality.
>
>
> Warmest Regards,
>
> 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
>



-- 
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: English Like?

[dunbarx via use-livecode]

There is a far more important issue here. New learners are far more likely to
be coaxed into continuing to spend the time and effort, and to put away
their fears, if they see and use "put x into y". It is why we have stacks
and cards, and in the olden days, rolodexes. The original HC team did all
that on purpose.

Remember "for the rest of us"?

Experienced users are being academic and pedantic to raise this issue as if
it were something important. We need new users, not old ones.

No offense, please.

Craig Newman



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/English-Like-tp4714951p4715143.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: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-24 14:52, Lagi Pittas via use-livecode wrote:

Mark

You are a big Tease.


Hehe - I don't mean to be a tease - making correct/good technical 
choices as to how things should work under the hood opens up an array of 
options for the future. We always try and design things with that in 
mind.


The 7 refactor was a large and rather difficult project, the full fruits 
of which have yet to become apparent. I can't say when some of the 
things we might like to do might happen, but at least they are possible 
now; when they weren't before.


Warmest Regards,

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: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-24 14:55, Mike Kerner via use-livecode wrote:
On the CompileIt thoughts, that was what I was hoping we were going to 
get
with LCB (We already have Double-XX).  You could make any Mac Toolbox 
call

in CompileIt, which meant you could build any XCMD/XFCN to add to your
stack, but the syntax was still HC (with some restrictions).


LCB already has the ability to call C functions - which is what 
CompileIt allowed you to do (as far as I understand). However, there is 
a fair bit of glue required to deal with things like C arrays (which are 
just pointers at the end of the day) and structs - that is something we 
would like to make much easier.


[ That being said, many C APIs are moving towards 'opaque pointers with 
accessor functions' rather than exposing C-bound concepts - mainly 
because that way it is much easier to bind to 'higher-level' languages 
(Python, Ruby, JavaScript etc.) - which just mean you have to deal with 
opaque pointers. ]


What we don't have is much documentation as to *how* to use the features 
which already exist. Although there is some usage of the feature 
littered about in some of the engine LCB files, I can appreciate that is 
not that easy to grok.


We also have an almost complete Java FFI system - Ali is currently 
working on the final piece: adding 'Listener' support (essentially 
callbacks) which the Android APIs use ubiquitously - e.g. for event 
handlers on Views.


I can attest to the fact that LCB FFI (for C) works - our LCFM plugin is 
written in LCB and the FM Plugin API is wrapped in LCB using the current 
C FFI features which are available (doing so has given me some more 
ideas about how to make such things easier *and* safer - which is a 
critical factor these days).


For Mac / iOS APIs we need to add a way to wrap an Obj-C object, and 
implement a Delegate (although you can manipulate Obj-C objects through 
a C API so technically you can do this already, if you don't mind a bit 
of bit munching). However, now we have done Java, Obj-C should follow 
very quickly. Both Obj-C objects and Java objects have very similar 
(abstract) properties in terms of how you access from from native code; 
and Listeners and Delegates are very similar things also.


In terms of actually compiling stuff to native code - it is a goal we 
have; but there are a few more ducks to get in a row before it can 
become a reality.


Warmest Regards,

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: Writing Extensions

[Mike Kerner via use-livecode]

I personally hate switch.  That said, getting rid of the CR's would help
make the new "choose" easier to read.  If you want a CR, use \

choose tValue
 when 1 or 2 or 3
  -- do something
end choose

choose tValue
 when 1\
 or 2\
 or 3
  -- do something
end choose

On Wed, May 24, 2017 at 9:03 AM, Kay C Lan via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Wed, May 24, 2017 at 8:25 PM, Mark Waddingham via use-livecode
>  wrote:
> >
> Thanks Mark for the explanation.
>
> >   choose tValue
> > when 1
> > when 2
> > when 3
> >   -- executes if tValue is 1, 2 or 3
> >   -- never falls through
> >
> > when 4
> >   -- never falls through
> >
> > default
> >   end choose
> >
> > This caters for both cases (1) and (2) and is unambiguous.
> >
> Whilst I certainly like the above and think it an improvement, if I
> were to 'step back' and redesign Switch I think I'd make it clearer
> that 'fall through' is just an OR - it took me ages to realise and
> I've have very very long: case (() OR () OR () ) which
> were extremely long and very hard to read until I rewrote them as
>
> case
> case
> case
> case
> ---do something
> break
>
> What I can't currently solve is the many case ((.) AND () AND
> () AND (...)... )
>
> So, again if I were reinventing Switch:
>
> choose tVale
>   when 1
>   or 2
>   or 3
> --do something
> -- no further fall through
>   when > 6
>   and < 60
>   and even
> --do something else
> --no further fall through
>   when 4
> --do another thing
>   default
> --some other thing
> end choose
>
> Just makes it clear that fall through is being used to combine the
> statements, but in my design it isn't just restricted to OR.
>
> ___
> 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: Writing Extensions

[Kay C Lan via use-livecode]

On Wed, May 24, 2017 at 8:25 PM, Mark Waddingham via use-livecode
 wrote:
>
Thanks Mark for the explanation.

>   choose tValue
> when 1
> when 2
> when 3
>   -- executes if tValue is 1, 2 or 3
>   -- never falls through
>
> when 4
>   -- never falls through
>
> default
>   end choose
>
> This caters for both cases (1) and (2) and is unambiguous.
>
Whilst I certainly like the above and think it an improvement, if I
were to 'step back' and redesign Switch I think I'd make it clearer
that 'fall through' is just an OR - it took me ages to realise and
I've have very very long: case (() OR () OR () ) which
were extremely long and very hard to read until I rewrote them as

case
case
case
case
---do something
break

What I can't currently solve is the many case ((.) AND () AND
() AND (...)... )

So, again if I were reinventing Switch:

choose tVale
  when 1
  or 2
  or 3
--do something
-- no further fall through
  when > 6
  and < 60
  and even
--do something else
--no further fall through
  when 4
--do another thing
  default
--some other thing
end choose

Just makes it clear that fall through is being used to combine the
statements, but in my design it isn't just restricted to OR.

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

[Mike Kerner via use-livecode]

On the CompileIt thoughts, that was what I was hoping we were going to get
with LCB (We already have Double-XX).  You could make any Mac Toolbox call
in CompileIt, which meant you could build any XCMD/XFCN to add to your
stack, but the syntax was still HC (with some restrictions).

On Wed, May 24, 2017 at 8:21 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-05-24 12:35, hh via use-livecode wrote:
>
>> Switch in LCB -- Monte asked to have the opportunity to do the job:
>> http://forums.livecode.com/viewtopic.php?p=131509#p131509
>>
>
> Yes... I'm not sure I quite see your point (especially as he said 'Is
> there any chance switch will be implemented as a control structure.', not
> 'how would I implement...') :)
>
> So...
>
> Would some sort of switch statement be useful in LCB? Yes - it is a
> generally useful thing to have.
>
> Has anyone proposed *any* design yet which does not have the flaws (we'd
> like to avoid) in the C-switch mode? No (well until it came up on the list
> the other day - there's a conversation going on that topic now which might
> bear some fruit, at least in terms of a design).
>
> Is 'switch' more important than a number of other things we need to do to
> LCB to meet its goals? No I don't think it is because it is equivalent to
> if/elseif/.../endif and we have that. For example, right now more code
> economy (taking into account the current main uses of LCB in the LiveCode
> ecosystem) would probably be gained (for example) by adding a bridge
> between LiveCode script's string lists, and LCB's lists; or enumerations or
> ...
>
> There's a whole chasm between saying 'I want a switch control structure in
> LCB' and having a switch control structure in LCB. If there wasn't then
> no-one on this list who programs for a living would have a job - last time
> I checked I can't just ask my computer 'please implement the switch control
> structure in LCB' ;)
>
> Warmest Regards,
>
> 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
>



-- 
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: English Like?

[Lagi Pittas via use-livecode]

Mark

You are a big Tease.

Lagi

On 24 May 2017 at 13:13, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-05-17 22:41, William Prothero via use-livecode wrote:
>
>> Folks:
>> It can be difficult for long term users of an application to
>> appreciate the “exceptions” to the philosophy of a dev app. I think
>> the livecode community is affected by “familiarity” over clarity
>> sometimes. For years (when Director was a viable dev platform), I had
>> a negative feeling about Hypercard type syntax. I had done some pretty
>> extensive programming in Hypercard and Supercard too. I liked the way
>> Director worked. I liked that it did not insult my intelligence by
>> requiring “put 3 into x” instead of the universal "x=3” syntax that
>> all algebra students lewarn in gradeschool, When Director died, I
>> looked around, held my nose, and jumped to livecode, and now I’m glad
>> I jumped that initial negative barrier. But, I take exception to the
>> many claims that livecode is “english-like” (in spite of the many
>> “english-like” commands), especially if you want to do the advanced
>> work that most of the users do.
>>
>
> Finally getting around to responding to this, as it is something which
> interests me... Specifically, we often hear about how LC's syntax
> 'insults intelligence' or is 'babyish' etc. However, I have to say that
> I've
> never understood *why* really.
>
> The only two reasons I really come up with are:
>
>   1) The 'high-priest' argument: programming languages should use somewhat
> arcane and obscure means of expression so that it limits who would want to
> / can use them.
>
>   2) The 'burnt by limited English-like systems in the past' argument: the
> incorrect association between being 'English-like' syntax wise, and not
> being a full, general, programming environment (the point here being the
> limits are in the implementations, not in the concept).
>
> I'd be really quite interested to know what other people think here.
>
> In particular, the use of 'put X into Y' rather than 'X = Y' comes up
> periodically.
>
> 
> The mathematician in me has to point out that the argument that 'X = Y' is
> 'better because we learn it in algebra' is technically erroneous. Algebra
> (and mathematics in general) operates on pure substitution - all values are
> singletons and the *only* thing which is equal to any value, is the value
> itself. Put another way, algebra does not have 'variables' in the sense we
> mean it in computing, 'X = 3' really does mean that X *is* 3, not that it
> should have 3 assigned to it, hence in a mathematical expression you can
> replace every occurrence of X *with* 3. (Modelling computer languages in
> the pure world of mathematics requires a bit of mental leap - what we
> consider a procedure is transformed into a function on the set of all
> possible states of the computer it is running on, rather than as sequential
> actions which occur on a single mutable state). Indeed, many languages
> choose ':=' for assignment and not '=' for this reason (it also means you
> don't have to use '==' for equality, and can use '=' which is a much better
> fit with what we do learn in Algebra).
> 
>
> Okay, so back to the point, if one wants a language to be readable and
> easily understandable it needs to be consistent. So, in isolation, perhaps
> have 'X := Y' for assignment might seem more economic. However, LiveCode's
> 'put' command is actually a fair bit more flexible. You can do:
>
>   put X into Y
>   put X after Y
>   put X before Y
>
> So if you have code which does:
>
>   put "foo" after X
>   put X into Y
>   put "bar" before Y
>
> You end up with:
>
>   put "foo" after X
>   Y := X
>   put "bar" before Y
>
> Here you end up having to do mental contortions because the sense of the
> 'before' and 'after' forms are opposite to the assignment (copy) form -
> easy readability vanishes. In particular, put flows from left to right, in
> contrast to the right to leftness of ':='.
>
> Certainly one could replace 'put X into Y' with 'X := Y', and even 'put X
> after Y' with 'X &= Y' - but what about before? 'X =& Y'? e.g.
>
>   X &= "foo"
>   Y := X
>   Y =& "bar"
>
> This looks really quite subtle to me, much easier to miss that one is
> 'append' and the other is 'prepend'.
>
> One thing I think LiveCode does do because of its slightly more verbose
> syntax is that it encourages readability (and as a result perhaps more
> maintainability) in code - something which other languages do not
> directly... Indeed, writing C programs which are readable and maintainable
> can take a great deal of time to learn *how* to do well - the language in
> and of itself doesn't really help you much at all. (That isn't to say it
> isn't possible to write unreadable code in LiveCode, because it clearly is
> - muddy abstractions can cause that as much as the syntax itself, but I'd
> like to think that LiveCode lends itself to more readable code by
> default... As 

Re: English Like?

[Mike Kerner via use-livecode]

One of the other things that the xtalk languages have that makes them more
appealing is synonyms (and similarly, abbreviations), which makes it a much
more personalized experience as a writer with fewer mental gymnastics.  I
tend to prefer the longer, more verbose forms when writing.  I will open
file/read from file/write to file/close file even though I could just use
the URL-file form.  I think it reads better, later, when I'm trying to
figure out what I did.  Some people prefer "cd", and I prefer "card".
Think about the different ways to reference a group, or to write a comment.

To Mark's comment on addressing arrays differently, the xTalk way would be
to just add a different way, not change the existing way.  Most of the code
that most of us write will be managed and maintained by one person.  It is
therefore more important to give us more ways to say the same thing so that
we can help our future self understand what we were thinking when we wrote
the original.

On Wed, May 24, 2017 at 8:13 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-05-17 22:41, William Prothero via use-livecode wrote:
>
>> Folks:
>> It can be difficult for long term users of an application to
>> appreciate the “exceptions” to the philosophy of a dev app. I think
>> the livecode community is affected by “familiarity” over clarity
>> sometimes. For years (when Director was a viable dev platform), I had
>> a negative feeling about Hypercard type syntax. I had done some pretty
>> extensive programming in Hypercard and Supercard too. I liked the way
>> Director worked. I liked that it did not insult my intelligence by
>> requiring “put 3 into x” instead of the universal "x=3” syntax that
>> all algebra students lewarn in gradeschool, When Director died, I
>> looked around, held my nose, and jumped to livecode, and now I’m glad
>> I jumped that initial negative barrier. But, I take exception to the
>> many claims that livecode is “english-like” (in spite of the many
>> “english-like” commands), especially if you want to do the advanced
>> work that most of the users do.
>>
>
> Finally getting around to responding to this, as it is something which
> interests me... Specifically, we often hear about how LC's syntax
> 'insults intelligence' or is 'babyish' etc. However, I have to say that
> I've
> never understood *why* really.
>
> The only two reasons I really come up with are:
>
>   1) The 'high-priest' argument: programming languages should use somewhat
> arcane and obscure means of expression so that it limits who would want to
> / can use them.
>
>   2) The 'burnt by limited English-like systems in the past' argument: the
> incorrect association between being 'English-like' syntax wise, and not
> being a full, general, programming environment (the point here being the
> limits are in the implementations, not in the concept).
>
> I'd be really quite interested to know what other people think here.
>
> In particular, the use of 'put X into Y' rather than 'X = Y' comes up
> periodically.
>
> 
> The mathematician in me has to point out that the argument that 'X = Y' is
> 'better because we learn it in algebra' is technically erroneous. Algebra
> (and mathematics in general) operates on pure substitution - all values are
> singletons and the *only* thing which is equal to any value, is the value
> itself. Put another way, algebra does not have 'variables' in the sense we
> mean it in computing, 'X = 3' really does mean that X *is* 3, not that it
> should have 3 assigned to it, hence in a mathematical expression you can
> replace every occurrence of X *with* 3. (Modelling computer languages in
> the pure world of mathematics requires a bit of mental leap - what we
> consider a procedure is transformed into a function on the set of all
> possible states of the computer it is running on, rather than as sequential
> actions which occur on a single mutable state). Indeed, many languages
> choose ':=' for assignment and not '=' for this reason (it also means you
> don't have to use '==' for equality, and can use '=' which is a much better
> fit with what we do learn in Algebra).
> 
>
> Okay, so back to the point, if one wants a language to be readable and
> easily understandable it needs to be consistent. So, in isolation, perhaps
> have 'X := Y' for assignment might seem more economic. However, LiveCode's
> 'put' command is actually a fair bit more flexible. You can do:
>
>   put X into Y
>   put X after Y
>   put X before Y
>
> So if you have code which does:
>
>   put "foo" after X
>   put X into Y
>   put "bar" before Y
>
> You end up with:
>
>   put "foo" after X
>   Y := X
>   put "bar" before Y
>
> Here you end up having to do mental contortions because the sense of the
> 'before' and 'after' forms are opposite to the assignment (copy) form -
> easy readability vanishes. In particular, put flows from left to right, in
> contrast to the right to leftness of ':='.
>
> Certainly one could replace 

Re: Writing Extensions

[Mark Waddingham via use-livecode]

On 2017-05-24 12:35, hh via use-livecode wrote:

Switch in LCB -- Monte asked to have the opportunity to do the job:
http://forums.livecode.com/viewtopic.php?p=131509#p131509


Yes... I'm not sure I quite see your point (especially as he said 'Is 
there any chance switch will be implemented as a control structure.', 
not 'how would I implement...') :)


So...

Would some sort of switch statement be useful in LCB? Yes - it is a 
generally useful thing to have.


Has anyone proposed *any* design yet which does not have the flaws (we'd 
like to avoid) in the C-switch mode? No (well until it came up on the 
list the other day - there's a conversation going on that topic now 
which might bear some fruit, at least in terms of a design).


Is 'switch' more important than a number of other things we need to do 
to LCB to meet its goals? No I don't think it is because it is 
equivalent to if/elseif/.../endif and we have that. For example, right 
now more code economy (taking into account the current main uses of LCB 
in the LiveCode ecosystem) would probably be gained (for example) by 
adding a bridge between LiveCode script's string lists, and LCB's lists; 
or enumerations or ...


There's a whole chasm between saying 'I want a switch control structure 
in LCB' and having a switch control structure in LCB. If there wasn't 
then no-one on this list who programs for a living would have a job - 
last time I checked I can't just ask my computer 'please implement the 
switch control structure in LCB' ;)


Warmest Regards,

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: English Like?

[Mark Waddingham via use-livecode]

On 2017-05-17 22:41, William Prothero via use-livecode wrote:

Folks:
It can be difficult for long term users of an application to
appreciate the “exceptions” to the philosophy of a dev app. I think
the livecode community is affected by “familiarity” over clarity
sometimes. For years (when Director was a viable dev platform), I had
a negative feeling about Hypercard type syntax. I had done some pretty
extensive programming in Hypercard and Supercard too. I liked the way
Director worked. I liked that it did not insult my intelligence by
requiring “put 3 into x” instead of the universal "x=3” syntax that
all algebra students lewarn in gradeschool, When Director died, I
looked around, held my nose, and jumped to livecode, and now I’m glad
I jumped that initial negative barrier. But, I take exception to the
many claims that livecode is “english-like” (in spite of the many
“english-like” commands), especially if you want to do the advanced
work that most of the users do.


Finally getting around to responding to this, as it is something which
interests me... Specifically, we often hear about how LC's syntax
'insults intelligence' or is 'babyish' etc. However, I have to say that 
I've

never understood *why* really.

The only two reasons I really come up with are:

  1) The 'high-priest' argument: programming languages should use 
somewhat arcane and obscure means of expression so that it limits who 
would want to / can use them.


  2) The 'burnt by limited English-like systems in the past' argument: 
the incorrect association between being 'English-like' syntax wise, and 
not being a full, general, programming environment (the point here being 
the limits are in the implementations, not in the concept).


I'd be really quite interested to know what other people think here.

In particular, the use of 'put X into Y' rather than 'X = Y' comes up
periodically.


The mathematician in me has to point out that the argument that 'X = Y' 
is 'better because we learn it in algebra' is technically erroneous. 
Algebra (and mathematics in general) operates on pure substitution - all 
values are singletons and the *only* thing which is equal to any value, 
is the value itself. Put another way, algebra does not have 'variables' 
in the sense we mean it in computing, 'X = 3' really does mean that X 
*is* 3, not that it should have 3 assigned to it, hence in a 
mathematical expression you can replace every occurrence of X *with* 3. 
(Modelling computer languages in the pure world of mathematics requires 
a bit of mental leap - what we consider a procedure is transformed into 
a function on the set of all possible states of the computer it is 
running on, rather than as sequential actions which occur on a single 
mutable state). Indeed, many languages choose ':=' for assignment and 
not '=' for this reason (it also means you don't have to use '==' for 
equality, and can use '=' which is a much better fit with what we do 
learn in Algebra).



Okay, so back to the point, if one wants a language to be readable and 
easily understandable it needs to be consistent. So, in isolation, 
perhaps have 'X := Y' for assignment might seem more economic. However, 
LiveCode's 'put' command is actually a fair bit more flexible. You can 
do:


  put X into Y
  put X after Y
  put X before Y

So if you have code which does:

  put "foo" after X
  put X into Y
  put "bar" before Y

You end up with:

  put "foo" after X
  Y := X
  put "bar" before Y

Here you end up having to do mental contortions because the sense of the 
'before' and 'after' forms are opposite to the assignment (copy) form - 
easy readability vanishes. In particular, put flows from left to right, 
in contrast to the right to leftness of ':='.


Certainly one could replace 'put X into Y' with 'X := Y', and even 'put 
X after Y' with 'X &= Y' - but what about before? 'X =& Y'? e.g.


  X &= "foo"
  Y := X
  Y =& "bar"

This looks really quite subtle to me, much easier to miss that one is 
'append' and the other is 'prepend'.


One thing I think LiveCode does do because of its slightly more verbose 
syntax is that it encourages readability (and as a result perhaps more 
maintainability) in code - something which other languages do not 
directly... Indeed, writing C programs which are readable and 
maintainable can take a great deal of time to learn *how* to do well - 
the language in and of itself doesn't really help you much at all. (That 
isn't to say it isn't possible to write unreadable code in LiveCode, 
because it clearly is - muddy abstractions can cause that as much as the 
syntax itself, but I'd like to think that LiveCode lends itself to more 
readable code by default... As subjective as that might be!)


Of course, LiveCode syntax isn't perfect - it has [] for array access 
for example - it might be nice to be

able to do:

   put index 3 of tNumericArray into tFoo
   put the foo of tAssocArray into tBar

Which is perhaps the way I'd suggest the language should go - 

LC 8.1.4 - referenced images doesn't load anymore

[Tiemo Hollmann TB via use-livecode]

Hello,

Has anybody experienced the same? An image, which filename is referenced to
the Resources folder, doesn't load anymore in LC 8.1.4 rc1 + 2 in a Mac
Standalone.

In LC 8.1.3 it works fine on Mac.

In both versions the image is being copied into the bundle folder:
/content/Resources/_MacOS/Resources/ when specified in the standalone
settings

On Win everything still works fine in 8.1.4.

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

Re: Writing Extensions

[hh via use-livecode]

Switch in LCB -- Monte asked to have the opportunity to do the job:
http://forums.livecode.com/viewtopic.php?p=131509#p131509

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

[Mark Waddingham via use-livecode]

On 2017-05-24 12:03, Mark Waddingham via use-livecode wrote:

Perhaps a better model would be to use 'continue', rather than 'break':

switch yourName
  case "Mark"
-- do something and finish
  case "John"
continue
  case "Jon"
-- do something else
end switch

The idea being that 'continue' in a case, jumps to the next choice to
check. This works particularly nicely when you don't have an
expression, so the cases can be expressions as that essentially gives
you a 'match' type construct with back-tracking (quite useful for
processing hierarchical arrays and transforming them - a common
operation in writing compilers, for example).


Okay, so that isn't quite right - for a switch-on-value switch, continue
would have to continue into the top the next case, ignoring the case 
value which is not quite the same as it would be in switch-on-case-expr 
switch.


Certainly a 'fallthrough' type keyword would work... However, stepping 
back and looking at the utility of switch. I'd say that in almost all 
cases you either want to:


  1) Map a single case to a block of code

  2) Map multiple cases to a block of code

The use-case which causes subtle bugs and errors is where one case 
requires a 'bit more code' before the others (where code, fallthrough, 
code is *not* erroneous but intended) - also it is a rarely used pattern 
in C (because it is difficult to maintain).


Taking this into account, then perhaps a better solution would be 
('choose' used here for the sake of argument):


  choose tValue
when 1
when 2
when 3
  -- executes if tValue is 1, 2 or 3
  -- never falls through

when 4
  -- never falls through

default
  end choose

This caters for both cases (1) and (2) and is unambiguous.

As I said before, the lack of switch in LCB isn't because we don't want 
a construct like that; just that we'd like one which doesn't have the 
issues of C-style switch. (The best way to avoid people accidentally 
introducing subtle bugs, is to ensure the language is designed to not 
let them do so!).


Warmest Regards,

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: Writing Extensions

[Mark Waddingham via use-livecode]

Hi Kay

On 2017-05-24 10:19, Kay C Lan via use-livecode wrote:

In that last one the only inference I could find was that due to the
probability that in 97% of use 'fall through' is not intended, a whole
heap of typing could be saved if no keyword (break) was required for
the 97%, and a keyword was only used to activate fall through. i.e.

switch yourName
case "Mark"
  -- do something
break
case "John"
case "Jon"
  -- do somethingElse
break
case "Ali"
  -- do anotherThing
break
end switch

would become

switch yourName
case "Mark"
  -- do something
case "John"
   fall --or some other keyword
case "Jon"
  -- do somethingElse
case "Ali"
  -- do anotherThing
end switch


11 less character to write. Is this the only problem with the current
implementation of Switch?


Okay so I was perhaps a little vociferous in what I said... However, 
fallthrough is
the key problem - there have been numerous subtle bugs in the engine due 
to it

(similarly, switch statements without 'default' can cause subtle
bugs too - if you add a value to an enum, but don't update all the 
switches which

switch on it).

Perhaps a better model would be to use 'continue', rather than 'break':

switch yourName
  case "Mark"
-- do something and finish
  case "John"
continue
  case "Jon"
-- do something else
end switch

The idea being that 'continue' in a case, jumps to the next choice to 
check. This works particularly nicely when you don't have an expression, 
so the cases can be expressions as that essentially gives you a 'match' 
type construct with back-tracking (quite useful for processing 
hierarchical arrays and transforming them - a common operation in 
writing compilers, for example).


However, it would probably be better to change the switch syntax to use 
different keywords (perhaps choice?). The 'switch'/'case'/'break' 
paradigm is so ubiquitous (due to C) that making it work differently 
would be very jarring.


Warmest Regards,

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: Writing Extensions

[Kay C Lan via use-livecode]

On Wed, May 24, 2017 at 2:49 AM, Mark Waddingham via use-livecode
 wrote:
> On 2017-05-23 18:02, Mark Wieder via use-livecode wrote:
>
> In regards to 'switch' - 'switch' in LiveCode copied the C 'switch' which
> is pretty much universally considered to be one of the worst designs of
> such a thing and we didn't want to repeat that 'mistake'.
>
I apologise for straying off topic but as one who found HyperCard to
be a revelation, and then stumbled across Switch in Revolution and was
just blown away (I'm pretty sure HC didn't have Switch) and now use it
EVERY time I script I was wondering if you'd be kind enough to
elaborate on what's wrong with LCs Switch.

I tried to google 'faults with C implementation of switch statement'
and other similar searches but didn't find any smoking gun:

https://www.codeproject.com/Articles/100473/Something-You-May-Not-Know-About-the-Switch-Statem

https://softwareengineering.stackexchange.com/questions/162615/why-dont-languages-use-explicit-fall-through-on-switch-statements

In that last one the only inference I could find was that due to the
probability that in 97% of use 'fall through' is not intended, a whole
heap of typing could be saved if no keyword (break) was required for
the 97%, and a keyword was only used to activate fall through. i.e.

switch yourName
case "Mark"
  -- do something
break
case "John"
case "Jon"
  -- do somethingElse
break
case "Ali"
  -- do anotherThing
break
end switch

would become

switch yourName
case "Mark"
  -- do something
case "John"
   fall --or some other keyword
case "Jon"
  -- do somethingElse
case "Ali"
  -- do anotherThing
end switch


11 less character to write. Is this the only problem with the current
implementation of Switch?

___
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

Accesing Mac file icons

[Michael Kristensen via use-livecode]

Hi there

There is some pretty big icons that show the content of a mac file. Fx graphics 
files show a picture of the actual graphic in the file.

Is it possible to acces that icon or picture from livecode?

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