Help: Does anyone use legacy message box behavior?

[Monte Goulding via use-livecode]

Hi Folks

I’m in the midst of making the message box redirect work in all engines 
(https://github.com/livecode/livecode/pull/5156 
) and it would seem that 
there’s a legacy message box behavior that could be removed from the engine. 
It’s not used by the IDE. The behavior is if no message box redirect is set 
then it looks for a stack named “Message Box”, sets the text of the first field 
then raises the stack. As this is only an IDE thing I strongly suspect we are 
ok to remove the code but while I’m waiting for the team to wake up in Scotland 
I thought I’d check here!

It would be easy to work around even if you have been depending on it because 
it’s just setting the property and then handling msgChanged to put msg where 
ever you want.

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: Help: Does anyone use legacy message box behavior?

[Monte Goulding via use-livecode]

> On 8 Feb 2017, at 11:02 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Monte Goulding wrote:
> 
> >> On 8 Feb 2017, at 3:04 am, Richard Gaskin wrote:
> >>
> >> My Message Box replacement sets the revMessageBox redirect to empty
> >> when it closes, and after doing so the LC IDE Message Box resumes
> >> normal behavior.
> >
> > Yes it does use it but it also (at least the single line msg box)
> > happens to conform to the old spec too (stack is named “Message
> > Box”). Also it sets it when loading the message box so that might
> > be fixing it for you.
> >>
> >> Is it necessary to remove the old behavior?
> >
> > Not overly so, however, every line removed is something we don’t
> > need to waste time maintaining. You might think we don’t need to
> > touch it but it has been touched recently because of a change in
> > the way we retain object references.
> 
> Now I'm curious: anything interesting there in terms of features, 
> performance, or memory handling?

The main advantage is stability. You might remember that in one of the early 8 
releases (not sure which one as it was just before I started) the memory 
management of objects changed so they would be released sooner if deleted 
within tight script loops instead of waiting for the next main loop to released 
them. It was a response to a bug where creating and deleting lots of objects in 
a loop bloated memory use I believe. Well deleting them earlier resulted in 
*lots* of instability where there were references to objects (say the internal 
defaultStack global for example) but the object had been deleted. Things like 
scripts still executing on objects that are meant to be deleted or setting the 
defaultStack to a stack that has just been deleted. Anyway in order to make it 
easier for us to resolve these issues Fraser wrote a class to use as an object 
handle whenever we want to keep a reference to an object. So now we can do 
stuff like t_stack.IsValid() before doing something with t_stack.

For example one crash that I just fixed is this one: 
https://github.com/livecode/livecode/pull/5143 


In that crash we were getting the stack of an object when it is being sent a 
message then using it later but the particular crashing code was deleting the 
stack the target object was on in a frontScript which was executed between 
getting the reference to the stack and using it. So the change now uses an 
object handle so we can check it’s still valid before sending the message after 
the frontScripts are executed ;-)
> 
> 
> > BTW our internal discussions have led us to consider dropping the
> > message box redirect entirely and just sending msgChanged to the
> > defaultStack which is inline with other messages. The less special
> > cases in the way we do things the better. The IDE pubsub library
> > can dispatch ideMsgChanged to any subscribers and they can do what
> > they like. If it’s unhandled or passed to the engine then it can be
> > sent to the appropriate system logs (or stdout… not sure which just
> > yet and perhaps will depend on if its in no ui mode as there’s a
> > legacy there).
> 
> My first inclination would be as you'd anticipated, that it would be such a 
> low priority as to be barely worth the net trade-off of trimming some code in 
> one place while writing other code elsewhere.
> 
> But if we're at last in a place where the IDE spec we're working with will 
> finally settle down, I'm okay with rewriting my stuff to work with it.
> 
> And best of all, since both the IDE code and our code will be coming from an 
> engine-borne message (I like msgChanged), I have options for how I handle 
> that, either through the IDE pubsub or in a well-managed frontscript as all 
> my other tools tend to use (which is why they don't generally break with IDE 
> changes ), and that freedom is as important to me as being able to rely on 
> the message within a standalone when I need to do that too.
> 
> In short, go for it. :)

;-) OK

> 
> Thanks for running this by the community.

It’s worth remembering that almost all of what we do is run by the community 
because everyone is free to subscrib to our github feed and comment on our PRs.

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: Help: Does anyone use legacy message box behavior?

[Monte Goulding via use-livecode]

> On 8 Feb 2017, at 3:04 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> I sent this a while ago, and oddly enough another message I'd sent lae came 
> in but this one did not.
> 
> After thinking about this some more, I wonder:  are you sure the LC IDE 
> doesn't rely on this?
> 
> My Message Box replacement sets the revMessageBox redirect to empty when it 
> closes, and after doing so the LC IDE Message Box resumes normal behavior.

Yes it does use it but it also (at least the single line msg box) happens to 
conform to the old spec too (stack is named “Message Box”). Also it sets it 
when loading the message box so that might be fixing it for you.
> 
> Is it necessary to remove the old behavior?

Not overly so, however, every line removed is something we don’t need to waste 
time maintaining. You might think we don’t need to touch it but it has been 
touched recently because of a change in the way we retain object references.

BTW our internal discussions have led us to consider dropping the message box 
redirect entirely and just sending msgChanged to the defaultStack which is 
inline with other messages. The less special cases in the way we do things the 
better. The IDE pubsub library can dispatch ideMsgChanged to any subscribers 
and they can do what they like. If it’s unhandled or passed to the engine then 
it can be sent to the appropriate system logs (or stdout… not sure which just 
yet and perhaps will depend on if its in no ui mode as there’s a legacy there).

Cheers

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

Re: Script locals in library stack script

[Monte Goulding via use-livecode]

> On 9 Feb 2017, at 9:32 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> I have a splash stack that opens a data stack from a server. The data stack 
> has a substack which is used as a library with "start using".
> 
> The handlers in the library work okay. Some of them store data in script 
> local variables in the library script. The script locals do not retain their 
> values, they are almost always empty when the library tries to access them 
> later.
> 
> Is this something others have seen? LC 8.1.3 rc 1.

I’m guessing you don’t mean in a separate request on the server. I’m not aware 
of anything special about the way server does stuff with variables so someone 
would need to chase this down based on a bug report I think.

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: Built-in JSON functions not working in standalone

[Monte Goulding via use-livecode]

Hmm… yes the new support library for mergJSON should be now be included in 
standalones if you include mergJSON. Please open a bug report if that’s not the 
case so we can sort the issue out. Note that it will *not* be included via 
search for inclusions.

Cheers

Monte

> On 31 Jan 2017, at 9:04 am, pink via use-livecode 
>  wrote:
> 
> JSONToArray and ArrayToJSON are both in the dictionary, if these functions
> don't do what they're advertised to do, then someone needs to revise the
> dictionary
> 
> from the Livecode Dictionary:
> 
> JSONToArray
> 
> Type  function
> Syntax  JSONToArray(pJSON)
> Associationsws.goulding.script-library.mergjson
> 
> Summary
> Parse JSON to a LiveCode array
> 
> 
> 
> Trevor DeVore via use-livecode wrote
>> To my knowledge, the functions are not built into Livecode. You may have a
>> stack loaded and part of the message path that has those functions there
>> already. You will need to add the functions to your project in order to
>> parse/encode JSON.
>> 
>> Bob
>> 
>>> On Jan 30, 2017, at 4:12 PM, pink via use-livecode 
> 
>> use-livecode@.runrev
> 
>>  wrote:
>>> 
>>> The JSONToArray and ArrayToJSON functions are built into Livecode now.
>>> Again, they work fine in the IDE, it is just in the standalone that it
>>> fails.
>> 
>> ___
>> 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
> 
> 
> 
> 
> 
> -
> ---
> Greg (pink) Miller
> mad, pink and dangerous to code
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/Built-in-JSON-functions-not-working-in-standalone-tp4712045p4712064.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


___
use-livecode mailing list
use-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: Storing and object reference in a var

[Monte Goulding via use-livecode]

> On 25 Jan 2017, at 9:53 am, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> put the long id of fld "daily-lesson-text" into tTargetField
> put "Hello" into tTargetField
> 
> what am I doing wrong?

You are writing ambiguous code and the engine can’t read your mind ;-)

Try:

set the text of tTargetField to “Hello”

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: Storing and object reference in a var

[Monte Goulding via use-livecode]

> On 25 Jan 2017, at 10:58 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Good news:  In v10 the LiveCode language will be reduced to a single command, 
> "build", which will automatically build whatever you're imagining.
> 
> Bad news:  Requirements for the new interface include a state-issued 
> mind-reading dongle inserted into your cerebral cortex, which will grant 
> backdoor access by officials (for your protection, of course).

Even worse news: The company supplying the mind-reading dongles will be bought 
out by a company with an injectable nanobot replacement. They only need the 
government contract so promptly brick all the dongles which has the unfortunate 
side effect of causing the zombie apocalypse.
___
use-livecode mailing list
use-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: [ANN] Release 9.0.0 DP-5

[Monte Goulding via use-livecode]

> On 24 Feb 2017, at 9:42 am, Mike Kerner via use-livecode 
>  wrote:
> 
> Another question:  Does the mobile have to be tethered to the desktop?  If
> I build a standalone, how are we going to communicate?

They communicate via sockets so no it doesn’t need to be tethered.

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: deploy?

[Monte Goulding via use-livecode]

> On 24 Feb 2017, at 1:19 pm, Richard Gaskin via use-livecode 
>  wrote:
> 
> Sounds useful for automating build systems.  At least part of it is 
> documented in the latest Release Notes - where can I find the rest of the 
> docs on that?

It isn’t part of the engine I know much about nor am I sure if/where the 
documentation might be. You would probably be better working with standalone 
builder scripts to automate building anyway.

Have a look at the standalone builder tests for command line building 
https://github.com/livecode/livecode-ide/tree/develop/tests/standalonebuilder 

___
use-livecode mailing list
use-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: deploy?

[Monte Goulding via use-livecode]

It’s an IDE only internal command for creating standalone engines.

> On 24 Feb 2017, at 12:51 pm, Richard Gaskin via use-livecode 
>  wrote:
> 
> The v9dp5 Release Notes include:
> 
>  Script-only deploy (9.0.0-dp-5)
>  It is now possible to use script-only stacks in the mainstack
>  and auxiliary stack parameters to the deploy command.
> 
> Sounds cool. What's the "deploy" command?  It's not in the Dictionary.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Remote debugger

[Monte Goulding via use-livecode]

You need to ensure the internet permission is on for android. We probably 
should make that automagicial with the test button..

Sent from my iPhone

> On 24 Feb 2017, at 4:44 pm, J. Landman Gay via use-livecode 
>  wrote:
> 
> I jumped all over this right away. I set a breakpoint in a test stack, 
> tethered my phone to the Mac, and clicked the Test button.
> 
> My button script:
> 
> on mouseUp
>  get "Testing"
>  put it into fld 1 -- breakpoint set here
> end mouseUP
> 
> The app launched on my phone and the script stopped executing at the right 
> place (nothing went into fld 1) but I wasn't asked if I wanted to start a 
> debugging session and the IDE didn't go into debug mode.
> 
> Is there something else I need to do to in the stack to activate remote 
> debugging?
> 
> Samsung S4, Android 5.0.1
> 
> -- 
> 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


___
use-livecode mailing list
use-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: Remote debugger

[Monte Goulding via use-livecode]

Thanks for the positive feedback. It was an interesting project but *hard* to 
debug when something went wrong.

> On 25 Feb 2017, at 6:48 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> I'd suggest that documentation make it clear what permissions and inclusions 
> need to be set up. I'm not sure I'd make the permission automatic, since the 
> final standalone may not want that permission set and the developer will 
> probably forget to unset it, especially if they didn't know it was turned on 
> in the first place.


We probably need a system of standalone settings dependencies for inclusions in 
general anyway ;-)

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: Windows and OSX 64-bit builds?

[Monte Goulding via use-livecode]

> On 10 Feb 2017, at 12:40 pm, Tom Glod via use-livecode 
>  wrote:
> 
> Does anyone know if there are plans for 64 bit windows and mac builds
> anytime soon? I'm bumping up against limits that seems all too ancient
> to be deallng with in 2017.
> 
> Just wanna know if its wishful thinking at this point or if its feasible to
> wait for 65 bit builds and save myself the work of optimizng for 32-bit?

Hi Tom

Mac 64 bit has been available for quite some time now. Windows 64 bit is in 
motion.

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: Windows and OSX 64-bit builds?

[Monte Goulding via use-livecode]

> On 10 Feb 2017, at 1:04 pm, Tom Glod via use-livecode 
>  wrote:
> 
> thanks monte. thats what i wanted to hearsorry i didn't notice the
> osx 64 builds. only ever saw llinux 64.. but i work on
> windowsso its music to my ears. what are we looking at ?...a few
> months?

I’m not really sure when the first versions will make a stable release but the 
work required to get things building on our build servers is on the go. It 
requires some drastic changes to things is all I know. Peter, Mark or Fraser 
would be better to give you more detail than that ;-)

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: Windows and OSX 64-bit builds?

[Monte Goulding via use-livecode]

> On 10 Feb 2017, at 1:03 pm, Tom Glod via use-livecode 
>  wrote:
> 
> trying to export snapshots of lage groups with many image controls. 
> can't get past 10k

10k controls or 10k pixels. Control rect origins are 16 bit ints and sizes are 
16 bit unsigned ints so if you are trying to position a control at > 32767 then 
it won’t work. That won’t change when we compile the engine as 64 bit.

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: Windows and OSX 64-bit builds?

[Monte Goulding via use-livecode]

> On 10 Feb 2017, at 1:33 pm, Tom Glod via use-livecode 
>  wrote:
> 
> but snapshot export just hard crashes Livecode as
> soon as it is triggered

If you have a recipe for a hard crash please post  bug report

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: Exit without quitting

[Monte Goulding via use-livecode]

> On 19 Jan 2017, at 11:20 am, Bob Sneidar via use-livecode 
>  wrote:
> 
> That is to say, it QUITS the app. BTW this "feature" is not documented. If 
> it's not supposed to quit the app, I can report it as a bug, but I recall 
> past conversations about this I think.

Please report this. It definitely sounds like a bug to me!



___
use-livecode mailing list
use-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: Documentation on Dispatch

[Monte Goulding via use-livecode]

Try this:

on mouseUp
 dispatch function "foo" to me with 1,2
 put the result
end mouseUp

function foo p1, p2
 return p1 + p2
end foo

___
use-livecode mailing list
use-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: Array Properties in a Standalone

[Monte Goulding via use-livecode]

> On 11 Jan 2017, at 2:24 pm, Bob Sneidar via use-livecode 
>  wrote:
> 
> Ooookaaay. In the IDE I can set a property of the mainstack (not the Splash 
> Stack mind you that I use to "shell" the application) to an array. When I 
> retrieve that property and access a key of that array, all is well. 
> HOWEVER... when I compile to a standalone, that key is apparently 
> inaccessible. 

I’m not sure if I understand your description of the problem but if you are 
trying to save to a stack that is embedded in the executable then that won’t 
work.

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: Array Properties in a Standalone

[Monte Goulding via use-livecode]

> On 11 Jan 2017, at 2:52 pm, Bob Sneidar via use-livecode 
>  wrote:
> 
> In the IDE this works famously. In a compiled application however, the column 
> updateby in every table I insert or update is empty. The only explanation I 
> can come up with for this is that arrays do NOT get stored properly is stacks 
> or substacks. Normal values I can retrieve for sure, because I store the 
> current unique ID's of table records like custid, siteid, deviceid etc. in 
> properties so that I can retrieve  them later when inserting/updating into 
> the SQL database. That works in the IDE AND Standalones.


I can’t give you any solid leads here but I think the idea that custom property 
sets don’t work in a standalone is a red herring. I’d start by finding the bit 
of code that sets the custom property set and wrap the whole handler in a 
try/catch structure and throw up an answer dialog with any error. Debugging 
standalones isn’t that much fun at the moment (we have a remote debugger in the 
works).

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: I'm a stupid GIT

[Monte Goulding via use-livecode]

> On 8 Jan 2017, at 8:00 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Malte Brill wrote:
> 
> > I also am a stupid GIT. Way over my head.

It isn’t you know. Everything you need is linked from the README here 
https://github.com/livecode/livecode . 
The only platform that is complicated to build is Windows and that’s largely 
because we need to use very old tooling to support Windows XP.

> That said - can’t this be
> > somehow automated so that one could download nightly builds?
> 
> While nightly builds can be a good practice for many projects, LC is 
> unusually complex, and requires a LOT of time to run their build system.

We do nightly builds and the occasional manually triggered build. We use them 
to manually confirm our bug fixes worked as we intended. I believe we have an 
unadvertised service for a fee to access these internal builds so if you need 
that then it’s worth asking.
> 
> This multiplies the time so much that I would imagine it would take many 
> hours to build a release.

Last I checked it takes about an hour and a half to build all platforms and 
installers etc.

Our process is:

- all patches are built and automated tests are run on the free CI server 
Travis for 64 bit Linux and OS X
- if that passes then someone manually reviews the patch and others might chime 
in with comments
- If it is reviewed OK then we have a bot that polls the github api to check 
for reviewed patches and build against all platforms just to check it builds OK
- If that passes then the patch is merged and the nightly build that includes 
it will be installed to check it so it can be closed on bugzilla.
- The nightly becomes a release once everything we want in has been checked

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: {Merry | Happy} [{Christmas | Hanukkah | Solstice | Holidays | Festivus | Saturnalia}]

[Monte Goulding via use-livecode]

> On 30 Dec 2016, at 7:59 am, Kay C Lan  wrote:
> 
> Stumbled upon a Tim Minchin show in New York a couple of years back
> when one of my team mates happened to be an acquaintance of Tim - his
> mother was best friends with Tim's mother. After the show met up and
> went for dinner with Tim - the whole night was a barrel of laughs.

Very jealous. I have linked the Tim Minchin song that is most relevant to this 
list for those that don’t know what we are talking about ;-) 
https://www.youtube.com/watch?v=bVKCHZqax84 


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: Translating escape sequence

[Monte Goulding via use-livecode]

> On 15 Mar 2017, at 3:28 pm, J. Landman Gay via use-livecode 
>  wrote:
> 
> So I'm stuck, I don't see any way to deal with these. I'll put in a bug 
> report about jsonImport() but it will probably be a while before it gets 
> fixed.
> 
> I hope someone else has an idea.

I do -)

Jansson (the library that mergJSON uses) does actually handle all escaped 
unicode codepoints just fine. There is, however, an issue with the JSONToArray 
function. Try patching it like I have done here 
https://github.com/montegoulding/mergJSON/pull/8

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: Translating escape sequence

[Monte Goulding via use-livecode]

> On 15 Mar 2017, at 5:08 pm, J. Landman Gay via use-livecode 
>  wrote:
> 
> Cool. :) I'd patch it if I knew how to do that but I don't know enough about 
> git to even start. But since you've put in a pull request, I can wait until 
> the next dp.

I meant you could patch it in your copy of LC. Just edit the script of stack 
“ws.goulding.script-library.mergjson”. You may need to mess with the 
permissions of the app bundle if you want to save on Mac.
> 
> Thanks much, Monte. I owe you another sandwich.

;-)
___
use-livecode mailing list
use-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: remote debugger on windows

[Monte Goulding via use-livecode]

Hmm… the remote debugger uses sockets. You might want to check the IDE is being 
allowed to accept connections. Also perhaps check if there are any rogue 
processes of the standalone or IDE in the task manager.

> On 5 Apr 2017, at 9:32 am, Matt Maier via use-livecode 
>  wrote:
> 
> I'm not trying to do anything fancy like debug an app on iOS/Android. I'm
> just trying to debug a standalone running on my windows desktop.
> 
> So I've got 9.0 dp 6
> script debug mode is checked
> test target is windows
> remote debugger is checked in standalone inclusions
> 
> I've tried just running a test from the IDE and saving as a standalone,
> then running that standalone with the IDE also running. Neither gives me
> the "remote debugging session" popup anymore. It appeared once or twice the
> first time I tried but hasn't reappeared since then.
> 
> The running application partially freezes at the moment when I would expect
> the script window to popup due to a breakpoint. Some of the functions don't
> respond, some do. No script window appears, no popup.
> 
> Am I missing something?
> ___
> use-livecode mailing list
> use-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: remote debugger on windows

[Monte Goulding via use-livecode]

> On 5 Apr 2017, at 11:11 am, Mark Wieder via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> On 04/04/2017 04:49 PM, Monte Goulding via use-livecode wrote:
>> Hmm… the remote debugger uses sockets.
> 
> What socket(s) does the remote debugger use? I'd like to stay out of its way.

It begins at 54321 and bumps the port each time accept fails until it finds 
one. The standalone is then inited with the current port in use by the IDE at 
build time.

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: OS X Firewall triggering on launch

[Monte Goulding via use-livecode]

> On 12 Apr 2017, at 4:48 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> And it is still putting up the alert on launch. Seems I'm stuck with it.

Hmm… that’s odd. I’ll ask the team if anyone has any ideas why this is 
occurring. Just to make sure you aren’t saving anything within the LC app 
bundle are you?

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: LC crashing when trying to save a standalone

[Monte Goulding via use-livecode]

> On 10 Apr 2017, at 9:18 am, Jonathan Lynch via use-livecode 
>  wrote:
> 
> I had been able to save a standalone of my app on 8.1.3 on a mac, but all of 
> a sudden it crashes every time.
> 
> I cannot see where I changed anything in the app that would cause this. Has 
> anyone else experienced this and how did you resolve it?

Could you please attach the crash log to a bug report so we can work out 
exactly what’s causing the crash. It would also help if you checked if LC 8.1.4 
RC 1 crashes with the same recipe.

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: LC crashing when trying to save a standalone

[Monte Goulding via use-livecode]

> On 10 Apr 2017, at 10:39 am, Jonathan Lynch via use-livecode 
>  wrote:
> 
> Not sure if I should bother with a bug report, since it is just my stack, but 
> no idea how to fix my stack either.

Please do. The engine shouldn’t crash.

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: LC crashing when trying to save a standalone

[Monte Goulding via use-livecode]

> On 10 Apr 2017, at 10:58 am, Jonathan Lynch via use-livecode 
>  wrote:
> 
> One more update - an earlier version of the app will save to a standalone.
> So, definitely something wrong with the stack. Going to try cloning the stack 
> or something like that.

It sounds like attaching the stack to the report would be a big help too then.

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: OS X Firewall triggering on launch

[Monte Goulding via use-livecode]

> On 11 Apr 2017, at 4:21 pm, J. Landman Gay via use-livecode 
>  wrote:
> 
> LC 9.0dp6 triggers the OS X firewall every time I launch it. I know I can set 
> the firewall to accept LC so it won't warn me, but I'm wondering what LC is 
> doing that makes that happen. I suspect it has something to do with remote 
> debugging. Does anyone know?

Yes the IDE is accepting connections for the remote debugger to work. 
Standalones then open sockets to the IDE. You should only get this dialog if 
you don’t allow signed apps to accept connections by default and/or don’t allow 
it the first time you run LC. Once you allow it you shouldn’t see this again 
unless LC gets modified or something.

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

[Monte Goulding via use-livecode]

Hi Folks

You probably want to get some docs for the robot and find out the service UUID 
that it offers then scan for peripherals with that service UUID. That’s the 
normal way of doing things but if there’s no docs available (from the looks of 
their downloads page you will need to request dev docs) you can scan for any 
peripherals and inspect them to work out what’s on offer. It would be great to 
get a write up of this for the LC blog if you get it all working.

The demo stack are inside that Ext folder which on mac is inside the app bundle 
-> Contents > Tools > Ext > mergBLE  > mergBLE.livecode. It isn’t 
pretty (just the baste basics needed to test functionality). We know this isn’t 
the most helpful location. At some point it would be nice to have a open demo 
stack button on the docs.

Cheers

Monte
> On 13 Apr 2017, at 12:30 am, Mike Kerner via use-livecode 
>  wrote:
> 
> Have a look in the dictionary.  I don't know if Monte still has the demo
> stacks available, but perhaps that would also help.
> 
> On Wed, Apr 12, 2017 at 10:23 AM, Roger Eller via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I have never used it, but this is in the LC forum:
>> 
>> try
>>  mergBLEStopScanningForPeripherals
>> catch e
>>  answer e
>> end try
>> 
>> http://forums.livecode.com/viewtopic.php?f=9=28007=
>> 147215=mergBLE#p147215
>> 
>> 
>> On Wed, Apr 12, 2017 at 10:18 AM, Richmond Mathewson via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> I must be really stupid . . . but . . .
>>> 
>>> How do I use mergBLE to get a simple list of BlueTooth devices in a
>>> listField?
>>> 
>>> Richmond.
>>> 
>>> 
>>> 
>>> On 4/12/17 4:08 pm, Roger Eller via use-livecode wrote:
>>> 
 That looks really cool (for teaching)!
 
 "PLEASE NOTE: Blue-Bot® is compatible with any iOS device with version
 3.0/4.0+ EDR Bluetooth (e.g. iPad3 and later)"
 
 So...  I would think you would use mergBLE for this.
 http://mergext.com/home/mergble/
 
 ~Roger
 
 
 On Wed, Apr 12, 2017 at 9:01 AM, Richmond Mathewson via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
 Yup: https://www.bee-bot.us/bluebot.html
> 
> http://forums.livecode.com/viewtopic.php?f=5=29121
> 
> I really would like to control the Blue-Bot via a LiveCode front-end
> rather than the crappy interface that
> one has to pay $50 for that stinks.
> 
> Richmond.
> 
> 
> On 4/12/17 3:58 pm, Roger Eller via use-livecode wrote:
> 
> Robot?
>> 
>> 
>> On Wed, Apr 12, 2017 at 8:57 AM, Richmond Mathewson via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>> OK: now for the goofy questions . . . .
>> 
>>> 1. How do I find my robot's pUUID on a Mac?
>>> 
>>> 
>>> Richmond.
>>> 
>>> 
>>> ___
>>> 
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> 
> 
> 
> -- 
> 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 

Re: "ouch: the beginning of the end"

[Monte Goulding via use-livecode]

> On 8 Mar 2017, at 10:59 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
> - Option 1 - bi-level background images
> 
> Here I'm assuming that your original PDFs do not change that often and (given 
> the
> requirements you have found out from the government department involved) the 
> forms
> must be used as is. Thus, I presume any 'recurring sections' would need to be
> rendered on repeated images of the appropriate page rather than cutting up the
> original forms into pieces and just replicating those parts.
> 
> In this case, then pre-rendering all the pages as high-resolution 
> black-and-white
> 1bpp bitmaps and then rendering those underneath the LiveCode fields is 
> probably not
> that bad an option. Given that the average printer people will be using will 
> probably
> only have a true black-and-white resolution of 300-600dpi and most printed 
> forms are
> only about 5% black pixels you will get immensely high compression ratios. 
> The only
> slight snafu here right now is that PDF printing support in LC does not yet 
> exist
> for Android, and would need a small patch to pass PNG data straight through 
> to the
> PDF (at present it only does this for JPEG). [ The reason PDF printing is not 
> currently
> supported on Android is due to text rendering which is not a straightforward 
> thing in
> PDF nor PostScript; the reason only JPEG image data is currently supported is 
> that
> when the pass-through was implemented the library we use to do PDF printing - 
> cairo -
> only supported it for JPEG, I *think* it does support certain PNG formats now 
> though
> since we updated the library for other reasons a while back ].

If the required platforms are limited to Mac and Windows then you can use XPDF 
to generate the images ;-)

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: Remote debugger

[Monte Goulding via use-livecode]

> On 7 Mar 2017, at 4:01 am, Mike Kerner via use-livecode 
>  wrote:
> 
> 1) There may be a crash bug related to mergDeploy (19365).  I don't KNOW
> that's mergDeploy related, but if MD is enabled, LC crashes, and if it is
> not, it doesn't.
> 2) Seeing !n instead of device name (19376)

Hopefully the new version of mergDeploy will have fixed those already ;-)
___
use-livecode mailing list
use-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: Remote debugger

[Monte Goulding via use-livecode]

Hi Folks

gREVDevelopment is not necessary for the remote debugger to function.

I have create an enhancement report for the remote debugger to automatically 
turn on android internet permissions:
http://quality.livecode.com/show_bug.cgi?id=19370 


The new version of mergDeploy didn’t make DP 5. Hopefully it will make the next 
DP but as I have been off for a week I’m not sure if work is complete on that 
and it will be in the one after. This will enable the IDE to recognise attached 
iOS devices and the Test button to install apps onto them. The only difference 
to Android is you need to tap the app icon on the device to start it running.

Cheers

Monte


> On 5 Mar 2017, at 5:53 pm, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Never mind… went thru the whole process again. on android → force stop the 
> app and then the IDE says the debugging session closed.
> 
> Awesome I found an obscure bug or rather difference
> 
> binfile://someAppPath/Unicode.txt  into myNewText
> 
> works on iOS and Mac OSX
> 
> but not on android
> 
> only 1 slash allowed.. 
> 
> binfile:/someAppPath/Unicode.txt  into myNewText #now works everywhere
> 
> This is a great step forward! Thank you Monte for the hard work!
> 
> BR
> 
> 
> 
> On 3/4/17, 8:37 PM, "use-livecode on behalf of Sannyasin Brahmanathaswami via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
>So far, so good; but I could "escape out" -- my app is locked upon the 
> phone, (because I'm in the script editor no doubt) app and IDE on my desktop 
> is locked. There was no way to return to development and look at the source.. 
> I had to quit my main stack and start it again… on the phone I went to 
> settings/Apps/SivaSiva -- force stop…did not have to quit LC though…
> 
> ___
> use-livecode mailing list
> use-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: Compiling LiveCode on Sierra

[Monte Goulding via use-livecode]

> Recent versions of Xcode have a setting in an internal plist to (by default) 
> ignore the 10.9 SDK - this can be solved by:
> 
> "edit (with Xcode) the MinimumSDKVersion key value in 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist"

We have a script that does Xcode tinkering in tools/setup_xcode_sdks.sh & .py. 

PS if you are going to run this against an automagically downloaded from the 
app store version of Xcode you will need to mess with permissions in the Xcode 
app bundle before you do it because you won’t be the owner. Also make sure you 
open Xcode before running the script as the initial setup stuff Xcode does must 
be done first otherwise it bricks the app.

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

[Monte Goulding via use-livecode]

> On 30 Jul 2017, at 1:01 am, Mark Wieder via use-livecode 
>  wrote:
> 
> On 07/29/2017 01:44 AM, Mark Waddingham via use-livecode wrote:
>> P.S. None of us tend to sit on gitter.io  - we can only 
>> process so many simultaneous inputs - however gitter does send email 
>> notifications when someone posts something on there and usually it doesn't 
>> take too long for one of us to notice (weekends, notwithstanding!).
> 
> While I think the original idea for using gitter (after trying Slack first) 
> was to set up sort of an IM channel, I have stopped expecting it to be that 
> and instead I use it for conversations where I need some deeper or arcane 
> expertise and don't feel like cluttering up the uselist or the web forums 
> that would be of interest to nobody else. And, once I stopped expecting it to 
> be an IM channel, I have to say that whatever the subject, I have always 
> gotten immensely useful information from the team on gitter.


As we get more contributors gitter will become more active and you will be able 
to answer many of the questions for each other. There’s little point expecting 
a great deal of chatter if there’s only half a dozen people outside the company 
that have built livecode from source. FWIW I have it on my phone and open on my 
desktop so I get notifications and respond if I know the answer. Usually it’s 
“Have you updated submodules?” ;-)

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

[Monte Goulding via use-livecode]

> On 30 Jul 2017, at 8:59 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> I'd rather suffer internal grumblings from our team due to having to have an 
> IDE submodule, than much larger shouts from our users when we make an error 
> like we did in 8.1.6-rc-2. I have a thick skin, I can happily ignore such 
> grumblings; less so very long, and very valid threads on the use-list :)

I’m actually not sure I see the connection between the ide submodule and the 
8.1.6-rc-2.

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: Compiling LiveCode on Sierra

[Monte Goulding via use-livecode]

> On 30 Jul 2017, at 7:04 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> Completely unrelated to the SDK thing, but it is worth mentioning (as Brian 
> obviously also noticed issues with develop-8.1)...
> 
> If you are building from source keep an entirely separate clone for 
> develop-8.1 and develop - don't switch within them to branches of the 
> opposite base as you'll end up getting funky errors whilst building quite a 
> lot.
> 
> We changed the way prebuilts work on develop compared to develop-8.1 - and 
> the two methods don't get along very well (at all, really!)

Hmm… I don’t do that and I seem to get along ok. Indeed in the newer versions 
of Xcode I can witch branches then regenerate the config and Xcode is fine with 
that.

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

[Monte Goulding via use-livecode]

Hi Alex

You could use the new httpd library that is already included in LiveCode 9 for 
this. Indeed this is what it was created for. We build a standalone with all 
our tests and serve it with the library. What would be ideal is to create a 
deploy library similar to the the iOS and Android ones. That way the Test 
button would build and launch the standalone in your browser. 

Cheers

Monte

> On 1 Aug 2017, at 5:22 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> Does anyone have a copy of (or a currently working link to) Andre's revHTTP ?
> 
> Thanks
> 
> Alex
> 
> P.S. I'm thinking of making a script-only stack that is a UI-free Simple HTTP 
> server - and then suggesting to Livecode Ltd that the HTML5 deployment guide 
> recommend it rather than the Python SimpleHTTPServer solution currently 
> suggested. Building this on top of Andre's core code would probably mean I'd 
> get a working version, without too many bugs, much more quickly than if I do 
> it myself.
> 
> P.P.S and as a bonus, I'd then be able to add the bridge/relay function 
> easily, so I can download off-domain web pages for my little app :-)
> 
> 
> ___
> use-livecode mailing list
> use-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: "Cascading" Object-Behaviors

[Monte Goulding via use-livecode]

The url got messed up somehow there try:
https://github.com/livecode/livecode/pull/5600 
<https://github.com/livecode/livecode/pull/5600>

> On 1 Aug 2017, at 6:12 am, Bob Sneidar via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> I click the link, I go there I log in I cannot see anywhere where there is a 
> file to download or code to copy. 
> 
> Bob S
> 
> 
>> On Jul 30, 2017, at 13:27 , Monte Goulding via use-livecode 
>> <use-livecode@lists.runrev.com> wrote:
>> 
>> I have implemented a scriptifier utility script if you are interested here 
>> https://github.com/livecode/livecode/pull/5600<https://github.com/livecode/livecode/pull/5600>
> 
> 
> ___
> use-livecode mailing list
> use-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: revHTTP

[Monte Goulding via use-livecode]

> On 1 Aug 2017, at 6:34 am, Matthias Rebbe via use-livecode 
>  wrote:
> 
> 
> it´s include in LC 9 DP7 and up.
> 
> Please note that you have to manually load it with
> start using stack "httpd"
> 
> This is a known issue and was mentioned in the “Known issues” in the release 
> emails, but unfortunately not in the release notes.

That will be fixed in dp-9.

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: "Cascading" Object-Behaviors

[Monte Goulding via use-livecode]

> On 1 Aug 2017, at 7:00 am, Bob Sneidar via use-livecode 
>  wrote:
> 
> OK got it. I take it this is supposed to be a script only stack? That is how 
> I saved it. 

Yes it will generate a very simple UI when you open it

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: "Cascading" Object-Behaviors

[Monte Goulding via use-livecode]

Use the following url:

<https://raw.githubusercontent.com/montegoulding/livecode/811fa6e77e514c7e3ccae150af5fd856199719e1/tools/Scriptifier.livecodescript
 
<https://raw.githubusercontent.com/montegoulding/livecode/811fa6e77e514c7e3ccae150af5fd856199719e1/tools/Scriptifier.livecodescript>>

I’d like to say you can go stack url with this url but you can’t because it’s 
broken for script only stacks although from the looks of things go stack byte 4 
to -1 of url might work in LC 9…

http://quality.livecode.com/show_bug.cgi?id=18998 
<http://quality.livecode.com/show_bug.cgi?id=18998>

Cheers

Monte

> On 2 Aug 2017, at 1:25 pm, Sannyasin Brahmanathaswami via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> "GIT DUMMY" here..
> 
> 
> How does one get the script without downloading the entire LC repository?
> 
> All I can see is to copy it.. which works I guess you have to then remove all 
> the leading "+" signs and save to your plugins folder?
> 
> BR
> 
> 
> 
> 
> On 7/30/17, 10:28 AM, "use-livecode on behalf of Monte Goulding via 
> use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of 
> use-livecode@lists.runrev.com> wrote:
> 
>I have implemented a scriptifier utility script if you are interested here 
> https://github.com/livecode/livecode/pull/5600<https://github.com/livecode/livecode/pull/5600>
> 
> ___
> use-livecode mailing list
> use-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: App Rejected: IPv6 network?

[Monte Goulding via use-livecode]

Are you using sockets? We do not support IPv6 sockets and they will rejection 
from Apple when they test on an IPv6 _only_ network which is their policy to do.

Cheers

Monte

> On 2 Aug 2017, at 3:14 pm, Dan Friedman via use-livecode 
>  wrote:
> 
> Hello.  My app was rejected my Apple today.   :(  Here’s what they said:
> 
> 
> We discovered one or more bugs in your app when reviewed on iPhone and iPad 
> running iOS 10.3.3 on Wi-Fi connected to an IPv6 network.
> 
> The error occurs after launch with the only option to quit the app.
> 
> Please see attached screenshots for details.
> 
> 
> The screen shot is of a answer command with the result of the download:  
> “can’t connect to host”.
> 
> The app, on launch, downloads a file (a compressed stack) from my server.  I 
> know for fact that went without error.  That freshly downloaded stack then 
> downloads another compressed stack.  The error happened on this second stack.
> 
> The app (with the development profile, of course) works perfectly on numerous 
> iPads and iPhones (using several versions of iOS including 10.3.3) tested on 
> several WI-Fi wireless networks at multiple locations.  It also preformed 
> perfectly using cellular data.
> 
> The message from Apple reports they use a IPv6 network.  Are there any issues 
> with LC 8.1.5 on a IPv6 network?
> 
> Thank you for any advice!
> -Dan
> 
> ___
> use-livecode mailing list
> use-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: "Cascading" Object-Behaviors

[Monte Goulding via use-livecode]

> On 3 Aug 2017, at 6:44 am, Brian Milby via use-livecode 
>  wrote:
> 
> So is the BOM causing the issue with detection of the URL being a script
> only stack or is it in the function that actually reads in the file?
> Trying to wrap my head around how the go stack works (still looking at
> code).

Go stack tries to work out whether it has been passed a blob that is the 
content of a stack file. Script only stacks may have a BOM but the current 
detection doesn’t handle that.

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

[Monte Goulding via use-livecode]

> On 2 Aug 2017, at 8:57 am, Andre Garzia via use-livecode 
>  wrote:
> 
> I just looked at the source code for the new httpd library, it is quite
> similar in "what it is doing" to mchttpd and my own revhttpd. Basically
> both of them use LC to accept and process requests. I had the impression
> that the new library was using some C/C++ based implementation.
> 
> The implementation Monte made is very minimalist and elegant. It is easy to
> follow and can even serve as a base for more ambitious projects. It suffers
> from the same problems as mchttpd and revhttpd though which is, it can't
> handle any form of concurrency. If your callback handler blocks, there is a
> great chance that any other requests will be discarded (unless LC is
> actually buffering and queueing them which would be awesome and also solve
> the same issue on the other implementations).

It is only really intended to be a simple implementation to use to serve 
something on localhost. As I mentioned previously it was only implemented for 
serving a HTML5 standalone in one of our test tools but generalised into a 
library for reuse for a number of things (HTML5 deploy library & FileMaker 
plugin web view, users serving things like reports in a local browser). I would 
not use it on a public webserver although it probably could handle some low 
traffic. It has not had any load testing done on it but I’m really not sure why 
it would drop requests unless the client has a very short timeout or each 
request takes a long time to handle. Of course if there’s a thousand requests 
coming in a second or something you’re on your own ;-)

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: httpd library and missed opportunity.

[Monte Goulding via use-livecode]

> On 2 Aug 2017, at 10:36 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> The 'test' button is handy - but it's not the only way.
> In fact, I rarely use it - I build my standalones, then try it out on 2 or 3 
> platforms (OK, this may be very untypical, because I am just starting to play 
> with mobile and html5 ... but I suspect it will continue to be a viable 
> work-flow - if only because of frequent interruptions, etc.) So I would hope 
> to be able to run the server,  and then make multiple tests with a single 
> standalone.

Hmm… Well click the Test button and then from your other platform enter the IP 
of the machine with the IDE. Should work fine.

> You said "[HTTPd library] ...  now that we have one included in the IDE we 
> ...". So is it the intention that this library is only available in the IDE, 
> and won't be available for inclusion in a standalone, or for use from 
> LCServer ?  (I can't see it in the list of inclusions in the SB, unlike diff, 
> getopt, etc. - though that list is getting long enough that scrolling through 
> it to see if something is there or not is becoming  inexact).

It should be in the list in dp-9.

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

[Monte Goulding via use-livecode]

Thanks for your thoughts Andre

> On 2 Aug 2017, at 8:48 am, Andre Garzia  wrote:
> 
> Yes, I can give more details, I am not talking about library documentation as 
> it is generated by lcdoc but the overall state of the documentation. The main 
> issue for me is a UX one. The built-in LC dictionary UI is not good. For 
> example, on my Surface 4 Pro, I can't change the little dropdown to select 
> the httpd API as the popup list is larger than my screen and does not scroll 
> with the trackpad.

Yes, we know this is not right. Plans are afoot to merge all the extension APIs 
into the LiveCode script one which will solve the problem above.

> That is just an example, a simple list of opportunities for enhancement would 
> be:
> 
> * Provide sample stacks for all LC dictionary entries (multiple entries can 
> share the same sample but no entry can be without at least one sample). The 
> sample stacks need to be something that the person can click and run.

Yes we need some kind of related resources thing where we can setup two way 
links between in a lesson, example stack or interactive tutorial. 

I’ve opened a report here http://quality.livecode.com/show_bug.cgi?id=20215 


My suggestion is the tags be expanded to all resources rather than just api so 
it’s easy to setup a blob of resources about a thing.

> * A better wiki or comment system.

We are encouraging people that have something to contribute to do so directly 
to the document as that way it both gets reviewed and more visibility. I know 
this presents a bit of a hurdle for some potential contributors but it also 
means there isn’t yet another place for good information to get lost in.

> * Libraries need to be more discoverable.

Indeed (mentioned above)
> 
> Right now we have documentation spread all over the place. There are things 
> in release notes, things in emails, stuff in the dictionary, stuff only on 
> the website, and finding things is quite hard. The navigation is challenging, 
> for example, searching httpd on the website yields nothing. I had to go to 
> github and look for the source.

In the past it was possible for stuff to be in the release notes but not 
documented in the dictionary but that shouldn’t be the case with anything new 
and anything that is not in the API please open a report on.

We know we need to do better with the docs, however, there are a *lot* of them 
so community contributions really do need to be a big part of getting them 
right.  Adding tags is a good place to start.

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: Can't use double finger scroll on mac for grouped controls

[Monte Goulding via use-livecode]

This is something you need to script for groups. Something like this:

on rawKeyDown pKeyCode
   if pKeyCode is 65308 then
  get the scroll of me
  add 10 to it
  set the scroll of me to it
   else if pKeyCode is 65309 then
  get the scroll of me
  subtract 10 from it
  set the scroll of me to it
   end if
end rawKeyDown

> On 2 Aug 2017, at 8:21 am, Kaveh Bazargan via use-livecode 
>  wrote:
> 
> Using LiveCode 9 on Mac OSX
> 
> I have some controls that are grouped and the group has been made smaller,
> so have a vertical scroll bar – very nice feature.
> 
> On one stack I can use two finger scroll on mac trackpad, but on another I
> can't. But mouse on scroll bar works ok.
> 
> I have checked and all settings are the same. Is there a particular setting
> that allows two finger scrolling?
> 
> -- 
> Kaveh Bazargan
> Director
> River Valley Technologies
> @kaveh1000
> +44 7771 824 111
> www.rivervalleytechnologies.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: Sluggish on Mobile Device

[Monte Goulding via use-livecode]

> On 2 Aug 2017, at 1:10 pm, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Ahhh, I wonder if  we only had two groups like this
> 
> card "portal"
>  group "SivaSiva Portal Scrolling"  # this is the group that scrolls very 
> badly no matter what we do.
>  # Sub groups
>   Header-group 
>   row 1 -(small group)
>row 2 -(small group)
>row 3 -(small group)
>  row 4 -(small group)
>   row 5 -(small group)
> 
>   group "SivaSiva Portal Navigation
>  # this a fixed tool bar at the bottom of the screen
> 
> so that the group that scrolls is *not* inside another group… if accelerated 
> Rending  make it scroll better.

I haven’t been following this thread sorry but yes if the group is directly on 
the card instead of nested then you can use scrolling layer mode otherwise it 
won’t work. You can check the effective layerMode to determine if you are 
getting what you think you should be getting. You also need to ensure you have 
no adornments like borders, graphic effects etc…

I just opened this report which should make things easier for people if we can 
do that http://quality.livecode.com/show_bug.cgi?id=20217 


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: httpd library and missed opportunity.

[Monte Goulding via use-livecode]

> On 2 Aug 2017, at 7:16 am, Alex Tweedly via use-livecode 
>  wrote:
> 
>> python -m SimpleHTTPServer 8080
>> This will let you access your standalone by opening your web browser and 
>> visiting http://localhost:8080 .
>> 
> What ?  IMO, this is just plain "wrong".

I think there’s a couple of things here. The scope of the original HTML5 
implementation did not include writing a HTTP server in LCS. It was before my 
time at the company but I believe a significant proportion of the project was 
Peter’s first thing he did in LC and he probably wasn’t aware of the fact 
there’s a few HTTPd implementations around the community. Anyway, now that we 
have one included in the IDE we definitely want to implement a deploy library 
so that you just need to click the Test button and it will pop up in your 
browser. Bonus points for being able to add extra browsers so you can choose a 
target.

I create a report about this a while back 
http://quality.livecode.com/show_bug.cgi?id=19909 


Anyway, this could either be contributed by someone in the community or done in 
house when we get a chance.

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: how to get the value of a custom property if the name of the cProperty is in a variable?

[Monte Goulding via use-livecode]

> On 3 Aug 2017, at 7:36 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> Of course, if you'd like to file a bug report / enhancement about being able 
> to do 'the "mycustompropname" of ... - then that is probably the 'future' 
> much better solution :)

Er… why if you know the name wouldn’t you type it unquoted? Are you really 
suggesting to put any expression there? The property/function ambiguity with 
`the` will make our heads explode!

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

[Monte Goulding via use-livecode]

> On 2 Aug 2017, at 4:02 am, Andre Garzia via use-livecode 
>  wrote:
> 
> I wish there was a more comprehensive documentation effort going on.

Hi Andre

Can you give a little more detail on your complaint here. All our new libraries 
are documented with lcdoc block comments which are extracted during the build 
and appear in the documentation. At the moment you need to choose the extension 
you are interested in as they don’t appear in the LiveCode Script api but in 
the future we will change this so all things available from LiveCode script are 
in the LiveCode Script API section.

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: MouseDown sent to button in group, but MouseUp sent to card

[Monte Goulding via use-livecode]

> On 4 Aug 2017, at 6:16 am, Monte Goulding via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> They probably should be deprecated.

I have started some internal discussion about this. There’s mouseStillDown as 
well. I think they shouldn’t be in the handler list as they may not be 
deprecated but are certainly not recommended. We will see what Mark thinks when 
he’s back from his G drinking holiday ;-) or not as he seems to be responding 
to lots of things anyway!

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: MouseDown sent to button in group, but MouseUp sent to card

[Monte Goulding via use-livecode]

> On 3 Aug 2017, at 10:54 pm, dunbarx via use-livecode 
>  wrote:
> 
> Note: If there is no mouseWithin handler in the target object's script, no
> mouseWithin message is sent, even if there is a mouseWithin handler in an
> object that's further along the message path.
> 
> Why this should be so is a mystery, but maybe someone from the team will
> chime in.

This is the case with the idle handler as well. These are very inefficient and 
would basically bog down the message path if they traversed the it for every 
object on every cycle. They probably should be deprecated.

A better mouseWithin would be something like this:

local sMouseWithin = false

on mouseEnter
   put true into sMouseWithin
end mouseEnter

on mouseLeave
   put false into sMouseWithin
end mouseLeave

Or just handle mouseMove instead of mouseWithin.

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: MouseDown sent to button in group, but MouseUp sent to card

[Monte Goulding via use-livecode]

> On 4 Aug 2017, at 6:38 am, hh via use-livecode 
>  wrote:
> 
>> Monte wrote:
>> ... G drinking holiday ;-)
> 
> Practising Geometry & Trigonometry and drinking??

Yeah I know… crazy mathematicians! What can you do.

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: common code patterns

[Monte Goulding via use-livecode]

> On 15 Aug 2017, at 2:10 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> But maybe not enough markdown to change how the human eye works. :)

Sure, my preferable end goal does not include backticks but I’ll take anything 
if it’s the only way I can have a string with escapes ;-)

The conclusion I came to on the bug report is we should have a goal of 
supporting escapes in all string forms (like JavaScript) but that we can’t do 
double quote yet due to backwards compatibility. That would come with open 
language which will have a script translation step and one of those steps can 
be “\” -> “\\” everywhere but format et al. For readability we would like a 
single quote delimited string so that it can include double quotes. If we add a 
single quote delimited string it can have escapes now because it’s something 
new. So we would have a few years of single quote delimited strings that 
process escape sequences and double quoted strings that don’t but eventually 
all would.

As far as interpolation goes I think I can live with the merge function 
particularly if I can pass it a string with escape sequences:

put “Hello" into tFoo
put “World” into tBar
put merge(‘[[ tFoo ]]\n[[ tBar ]]!’)

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: String delimiters [WAS Re: common code patterns]

[Monte Goulding via use-livecode]

> On 15 Aug 2017, at 5:22 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> put {{
> That's better!
> A really readable and short
> version that I can deal with.
> }} into temp

It’s really unlikely we would use { } because one day we will want to implement 
array literals. You know one time I messed with the server tag code in the 
parser so that reverse server tags could be used for this ;-)

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


That of course would never pass the sniff test!

Anyway, if I might propose an alternative of allowing the line continuation 
char (which happens to be escape) within strings. The sequence \ & return & 
 would be replaced with just return in the string.

Something like this:

put “foo\
 bar”

would put:

foo
bar

Of course if you need leading whitespace then that’s a bit trickier but the 
above could be relatively easily implemented in both the script editor and the 
parser.

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: String delimiters [WAS Re: common code patterns]

[Monte Goulding via use-livecode]

> On 15 Aug 2017, at 7:33 am, Monte Goulding via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> put “foo\
> bar”
> 
> would put:
> 
> foo
> bar

I had a little play while munching my muesli this morning with adding this to 
my (probably won’t get in the engine) PR for escaped strings. It was only a few 
lines to add but I didn’t look at colorization yet. I put a gif up here 
https://github.com/livecode/livecode/pull/5781 
<https://github.com/livecode/livecode/pull/5781>

Of course that is:

put ‘foo\
  bar’

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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 6:20 am, Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/10/2017 10:38 AM, Ralph DiMola via use-livecode wrote:
>> To make this even more flexible:
>> repeat for each line tLine in tLines with [counter] tIndex [start] [{1}|x]
>> [step] [{1}|y]
>>  end repeat
> 
> I would change the syntax slightly:
> 
> repeat for each line tLine in tLines [using tIndex [start [to end]]]
> end repeat
> 
> but otherwise +1: I end up writing loops like this a lot.

Sorry folks I should have been more specific and said using existing syntax. So 
the original thing posted is what I’m after at the moment:

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
   — code
   add 1 to tIndex
end repeat

Jacque the break thing is possible but not what I’m after at the moment. Could 
you open an enhancement request and I’ll try and get that done for you.

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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 7:02 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Except that's wrong. :)
> 
> I tend to use 0 as the initial value, and increment at the top of the loop:
> 
>  local tIndex
>  put 0 into tIndex
>  repeat for each line tLine in tLines
>  add 1 to tIndex
>  — code
>  end repeat
> 
> I've found two benefits from this habit:
> 
> 1. (minor) Clearer distinction between unincremented and incremented counter.
> 
> 2. (major) I can "next repeat" at any point in the block and know that the 
> counter is appropriately updated.
> 
> Indeed, it was a runaway loop many years ago that set me know this path.

Aha… well it probably depends on what you are using tIndex for but yes your 
pattern is much more reliable if tIndex is meant to represent the line number. 
If on the other hand tIndex is meant to only be incremented if you haven’t 
exited the loop at some point while processing tLine then you may want the 
other pattern so perhaps both have value as examples but I’m not sure how one 
would name the two different patterns. I guess you could do this which is 
probably best:

 local tIndex
 put 0 into tIndex
 repeat for each line tLine in tLines
 — code for ensuring tIndex should be incremented
 add 1 to tIndex
 — code for using tIndex
 end repeat
> 
> 
> 
> All this raises a bigger question:  can we for now provide some sparse 
> minimums and perhaps consider adding more later if truly needed?
> 
> Saves work for you folks, and obviates the need to have what would likely be 
> really long threads here about different coding styles (or whether all 
> possible styles should be supported in Prefs  - "Damnation to the dangling 
> 'thens'!" ).

Sparse minimums are fine. I just need a few examples for the moment. Down the 
track once you all see _why_ I’m asking then we can expand on things a bit ;-)

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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 7:15 am, Mike Kerner via use-livecode 
>  wrote:
> 
> So back to my original question, and my original comment - you're talking
> about macros?  See my first reply.

However they are used the patterns will be the same ;-)

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: common code patterns

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 1:37 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> So, let me rephrase - what are the use-cases people can see for allowing 
> (some variant of):
> 
>   repeat ... with counter tCounter starting from tStart

Hmm…. what about:

repeat for each line tLine in line 5 to -1 of tLines with counter tCounter 
starting from 5

BTW if we ever do this could the following be ordered if the array is a 1..N 
sequence… I’m not really sure if repeat for each element is ordered in any way 
currently.

repeat for each element tElement in tArray with counter tCounter

I guess we could have more explicit syntax here which might be more flexible too

repeat for each element tElement and key tKey in tArray ordered numeric 
ascending

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: Speed of control lookup (Was Re: Parent of Target)

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 8:11 am, Mark Wieder via use-livecode 
>  wrote:
> 
>> Hmm… Would it be a good idea to create a new ID form with the bare minimum 
>> to identify an object. 
> 
> 
> UUID
> 

Let’s not start that again ;-)
___
use-livecode mailing list
use-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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 9:40 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> repeat with i=1 to paramcount()-1
>put param(i)&"," after theValue
> end repeat
> put param(paramcount()) after theValue
> 
> Shorter, faster, and just plain tidier :-)

Hmm… there’s a few reasons I’m not a fan of this pattern:

- you can’t really clearly document the handler parameters although this could 
feasibly be worked around by redefining what a parameter is in your docs
- if any of your parameters may contain whatever delimiter you are using when 
parsing the params then everything breaks if you are using comma as suggested 
above then it’s not safe to pass object references to the handler.

So my question therefore is are there many people that use this pattern and 
should we throw it around a bit to get a more robust form or is this an edge 
case of a particular developer’s scripting style?

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: Speed of control lookup (Was Re: Parent of Target)

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 1:23 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> It has also suggested (to me, at least) a slightly different approach - we 
> make the return value of the 'long id' property of objects what you might 
> call a StringyLongId value. Instead of returning a string:
> 
>  button id 1003 of group id 1004 of card id 1002 of stack "MyStackName"
> 
> It would be a value which acts like a string, but internally stores:
> 
>[ BUTTON, 1003, [ 1004 ], 1002, "MyStackName" ]

Hmm… Would it be a good idea to create a new ID form with the bare minimum to 
identify an object. Say:

 id  of card id  of stack “”

Although I guess unplaced groups would need just  id  of stack 
“”

That would mean speed improvements could be done on an object reference that is 
relatively robust to changes in the object tree and unless you are creating an 
IDE you would be very unlikely to need to do the LCB object reference 
repository thing.

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: [OT] HyperCard preservation society

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 11:27 am, Mark Wieder via use-livecode 
>  wrote:
> 
> LOL... "PRINT PEEL & STICK VHS LABELS"

Not betamax? C’mon!
___
use-livecode mailing list
use-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: common code patterns

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 8:06 am, Mark Wieder via use-livecode 
>  wrote:
> 
>> I guess we could have more explicit syntax here which might be more flexible 
>> too
>> repeat for each element tElement and key tKey in tArray ordered numeric 
>> ascending
> 
> I must be channeling Mark Waddingham here... I'm worried that the syntax is 
> borderline not-xtalky. For instance, it's not obvious from looking at that 
> whether tElement or tKey is sorted numerically. By guess is that you intend 
> tKey to be sorted.

Ha… I hadn’t considered that you might want the elements sorted instead of the 
keys but of course you might… well I’m not sure I just know I’d really like to 
have a way to iterate sorted keys and elements…

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: Android Virtual Device Application Binary Interface

[Monte Goulding via use-livecode]

> On 13 Aug 2017, at 10:16 am, scott--- via use-livecode 
>  wrote:
> 
> When testing Android builds on a virtual device, is it necessary to use 
> devices created with an ARM abi?

Yes

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: common code patterns

[Monte Goulding via use-livecode]

> On 14 Aug 2017, at 6:50 am, Mark Wieder via use-livecode 
>  wrote:
> 
> I realize it's not reviewed/accepted yet (and may not be), but Monte's done 
> something impressive here:
> 
> https://github.com/livecode/livecode/pull/5781#issuecomment-322065901 
> 

Ha “(and may not be)” should really be “(and is really really unlikely to be)” 
but still it was an interesting thing to have a play with.

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: common code patterns

[Monte Goulding via use-livecode]

> On 14 Aug 2017, at 5:45 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
> P.S. There is another quote-like char which could be used for an implicitly 
> merged / escaped string literal - back-quote - `...`. So that should be 
> considered too - one option would be single-quote and double-quote delimited 
> strings are the same beyond the quote char; but back-quote delimited strings 
> do more work, i.e. de-escape and potentially interpolate. (Of course, this 
> does add *more* symbols to the language - but one thing symbols are good for 
> is readable bracketing, so maybe that's a good justification).

Haha… to quote you some 4 years ago after I suggested backtick:

> Oh, please not backtick! The character is awkward to type (its one of the 
> ones that moves around a lot on keyboard layouts) and difficult to read (and 
> always makes me think something more is going on - e.g. as in bash scripts!).

Mind you we have all written a _lot_ of markdown since then so backtick is 
probably much more palatable. I’m happy to change the PR to use backtick if 
that’s preferred and I can either drop the single quote thing or make it work 
but without escapes as an option for strings with double quotes.

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: common code patterns

[Monte Goulding via use-livecode]

> The point here is that if we *were* to use back-tick then it would be worth 
> considering making it escape capable *and* interpolate capable - i.e. there 
> would be more going on. It would certainly solve one part of the balancing 
> act in terms of what people may want to use ' and " delimited strings. (I'd 
> suggest making it syntactic sugar for 'function("...")’).

Hmm… so say merge(“ string “, resolve escapes) = ` string ` ? I’ve got to say I 
wasn’t thinking of interpolation as I thought that merge does that sufficiently 
well.
> 
> However, there are other options too - at the end of the day is 
> 'format("...")' actually too onerous on occasions you want escaping?

Yes, unless you can use it in a constant or variable declaration which would be 
unusual and a bit too special casey for me:

constant kSomething = format(“this\tis\todd”)

> P.S. We should see if we can schedule some time in the next sprint to 
> actually do that analysis properly and *then* garner feedback.

Sure if you it’s a priority. The PR is only up there because I got interested 
in something on a rainy Sunday arvo. It’s not like we haven’t got other stuff 
to do and this bike shed seems to be rather large ;-)

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: Speed of control lookup (Was Re: Parent of Target)

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 7:26 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
> I'd be happier about introducing a new id if we could solve the multiple 
> mainstack with same name issue too (or at least get a step closer to it)

Hmm… what about giving stacks a meaningful ID… stack ID is completely useless 
right now as far as I can tell. What is currently the stack ID could be just an 
internal thing to maintain the ID sequence and stacks could be assigned a read 
only session ID. I very much doubt such a change would break any code but I 
guess I could be wrong there…

Perhaps better to make these references storable would be a UUID (ducks ;-). 
Maybe if _only_ stacks had a UUID they would be more palatable?

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

common code patterns

[Monte Goulding via use-livecode]

Hi Folks

I’m looking for a few common code patterns that you find yourselves writing 
often but aren’t well suited to reusable handlers. So snippets of code or 
common ways that events are handled together in a script for a certain task.

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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 11:45 am, Mark Wieder via use-livecode 
>  wrote:
> 
> You know, if you'd post what you're trying to do it might be more possible to 
> stay on target here. For instance, I regularly have to fill an array with 
> constants in an initialization routine or use a custom property array filled 
> with constants. Is that any help? Or are you looking to make a macro 
> processor? Or a library of common ? Or something else?

A library of common  is probably the best description at the moment but 
the use case is not reusable handlers as we have other means for that.

Basically anything where you follow a common pattern to do a thing but you 
can’t abstract away so you don’t have to write the pattern any more.

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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 11:54 am, Mark Wieder via use-livecode 
>  wrote:
> 
> What would you put as a comment after the 'end if' using your proposed 
> approach? The original comment for the 'if' statement or something else? 
> Would you force the user to create comments for each 'else if' as well?

I’m not sure if I proposed anything… was just wondering out loud… but yes I 
think if a tag approach is used then

if some complicated condition then # commontag

else if some other complicated condition then  # commontag

else if some yet again complicated condition then  # commontag

else  # commontag

end if  # commontag

Now you would know no matter how much spaghetti you write or how complicated 
your conditions are which control structure each if/else if/else/end if belongs 
to.

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: common code patterns

[Monte Goulding via use-livecode]

Over on the Parent of Target thread we are discussing local var access so I 
wonder if this is a useful common pattern:

local s

command set p
   put p into s
end set

function get
   return s
end get

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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 11:38 am, Mark Wieder via use-livecode 
>  wrote:
> 
> I would actually argue against this. For me, the useful part would be
> 
> end if # some complicated condition
> 
> Otherwise, making the user come up with a comment that basically says "some 
> complicated condition" anyway, and doing all the maintentance you've 
> described above sounds like a lot of work for very little gain.

OK but:

if some complicated condition then

else if some other complicated condition then

else if some yet again complicated condition then

else

end if # what do you put here?
___
use-livecode mailing list
use-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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 10:53 am, Devin Asay via use-livecode 
>  wrote:
> 
> I’d like to see one like this for conditional structures:
> 
> if  then
>  -- do if true
> else
>  -- do if false
> end if
> 
> I always try to use the “full” form of if-then-else. It solves lots of 
> confusion when you end up with nested if-thens. I teach my students to do it 
> this way as best practice, and I think it reinforces the idea of a completely 
> formed and terminated structure.

I agree Devin

The script editor doesn’t do macro completion on return of `if` because we have 
so many possible variations of that it is near impossible to work out what the 
user wants however I know I always want `return & indent & cursor selection & 
return & end if` when I hit return and the last non comment word of the line is 
then. 

I will occasionally use the single line for things like exit repeat if I’m 
feeling lazy but it’s likely I only do this because there’s no macro completion 
here so…

Anyway, as with the macro completion of `case` -> `break` adding `if` macro 
completion only if the last token is `then` would require some special casing 
in the current code which only looks at the first token of the statement and 
only does completion with end .

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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 4:55 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> Well, you don't actually have to use the tooltip. It wouldn't interfere with 
> your current method and would enhance the editor for those who don't want the 
> clutter.

Having thought about this a bit I think the issue with the tooltip is if it is 
worked out dynamically then if you’ve done something to stuff up your control 
structures then it won’t work out the right thing anyway… when the comments are 
most useful is in exactly that scenario so perhaps comments is the way to go 
for those that wan them.

So we need:

1. an optional way to add such comments (even users that want them might not 
want them unless they are making spaghetti)
2. automagical maintenance if the comments exist and you change the condition
3. work out whether tags rather than the actual condition is what people really 
want because the condition might add too much clutter:

if some complicated condition then # I’m a makin’ spaghetti
   — spaghetti
end if # I’m a makin' spaghetti

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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 10 Aug 2017, at 6:02 pm, panagiotis merakos via use-livecode 
>  wrote:
> 
> I personally like this idea, and I find it pretty useful. And this does not
> sound too difficult to implement.
> 
> But I am not sure if everyone will like it, so if we do it, we should
> probably add a pref to turn it on/off.
> 
> The good news is that Ali has been doing some work on scriptifying the
> Prefs stack, so in the future it will be easier to add Prefs for such
> features.

I wonder whether a mouse over tooltip would work just as well. Is this 
something you want to be able to see _all_ the time or just if you get confused 
about where you are?

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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 2:54 pm, Scott Morrow via use-livecode 
>  wrote:
> 
> What about the use of mobile-only commands… needing to always wrap them in 
> something to keep the IDE from touching.
> 
> if "mobile" is in the environment then
>  mobileControlSet tObject, tProp, tValue
> end if

Yes that’s quite a common bit of code in a mobile app!

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: [ANN] Release 9.0.0 DP-8

[Monte Goulding via use-livecode]

> On 14 Jul 2017, at 7:53 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> panagiotis wrote:
> 
> > We are pleased to announce the release of LiveCode 9.0.0 DP-8.
> ...
> > - A new HTTPd script library has been added. The HTTP Server
> > library can be used to receive and respond to HTTP requests
> > in your application.
> 
> A very valuable addition.  I'm curious about what prompted that development 
> effort, and does it support HTTPS connections, or CGI?

One of my recent projects has been to create a test runner for HTML5. So all 
our tests that we run on the CI server are bundled up into a HTML5 app and run. 
In order to get the results back into LiveCode I made the simple HTTP server to 
handle callbacks that the HTML5 engine sends when it is served from localhost. 
I separated it into a script library so I could reuse it down the track in 
FileMaker for web views. I expect others will like to use it for serving 
browser widget content etc too. It is a rather simplified server script but 
it’s open source so if you need more than it offers feel free to send a PR. It 
doesn’t have a normal CGI interface. As the request comes in a callback is 
delivered to the object that started the server so your response can be 
dynamically generated.
> 
> > New experimental features:
> >
> > - [Experimental] A new "Mac Native Button" widget is added to
> > LiveCode's widget collection.
> 
> The Dictionary for this new version doesn't load on Linux this time (hangs 
> the process actually, one of the known issues), so forgive this question 
> probably answered there:
> 
> Does the syntax for that button style use "button" or "widget”?

widget
> 
> What does this do differently from the "Standard" button style?

It’s the actual native view rather than us getting details of how to draw a 
button from the OS and drawing it ourselves. It’s mainly an example but it 
would be useful for layering a button over another native view.
> 
> Does it have the same properties and message handling options we're used to 
> with buttons?

Not yet. I believe it only has mouseUp.

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: LiveCode 8, LiveCode 9, their intersection and other questions.

[Monte Goulding via use-livecode]

Yep, what Richard said. The only caveat at present is we are implementing new 
IDE features in 8.1 point releases so that we can have iterative incremental 
improvement in stable versions for our user testing.

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: [ANN] Release 9.0.0 DP-8

[Monte Goulding via use-livecode]

> On 18 Jul 2017, at 5:59 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
> I think it is worth having a preference for both highlighting and completion 
> - it serves people's individual tastes, and as long as the preference is 
> discoverable then it won't add any complexity.

OK, I’ll open a report about those
> 
> Ideally highlighting would be context aware - so outside of a string, it 
> highlights other brackets outside of strings; but when in a string it 
> highlights brackets in strings:
> 
>  put (1 "a(2" & tVar ")2" )1 after tFoo
> 
> (Numbers used to indicate matching pairs)

I think it doesn’t currently do what you are suggesting but in the case above 
it does what you want anyway ;-)
> 
> I was thinking in terms of syntactically - missing the point of in-string 
> highlighting (as HH and Mark Wieder pointed out).
> 
> Indeed, the current approach is an approximation to the ideal and adding { 
> and } to highlighting wouldn't do any harm; and would serve the use-case of 
> JSON and similar generation.
> 
> In terms of ' then, for much the same reason that would probably be useful - 
> although that might require a bit more work on the highlighting code as it 
> isn't a matched pair (@montegoulding?).

Should be the same as quote so not a big issue if it’s helpful.

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: Exposing ourselves

[Monte Goulding via use-livecode]

> On 18 Jul 2017, at 7:19 pm, Richmond Mathewson via use-livecode 
>  wrote:
> 
> "it’s currently not exposed in the IDE UI"
> 
> 1. How can we work out what features are "latent" in LiveCode but are hidden?
> 
> 2. How can we 'hack' the IDE to expose any of those features we may find 
> useful?

https://github.com/livecode/livecode-ide 

___
use-livecode mailing list
use-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: [ANN] Release 9.0.0 DP-8

[Monte Goulding via use-livecode]

> On 17 Jul 2017, at 11:36 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
> Okay, so having just read the form thread as well...
> 
> There are two things here:
> 
>  1) Bracket highlighting
> 
>  2) Bracket completion
> 
> They should both be preferences.
> 
> Secondly, both should really only function on 'real' tokens which are part of 
> script (hence why '{' isn't appropriate at this time for it to function on). 
> If you are typing a string or a comment then it shouldn't trigger completion 
> nor highlighting. This is actually quite hard to get right efficiently 
> (indeed, a lot of editors don't get this right, so I end up turning such 
> features off).


Actually it’s quite helpful within strings. Consider a string to be used with 
the merge function or just the likelihood of wanting a pair of brackets in a 
string rather than a single one. As for quotes as they are not valid within a 
string if you are typing one it’s highly likely you want two and to concatenate 
something between. For example:

put “foo baz”
— come along later and edit to
put “foo” && tBar && “baz”

There is already an autocomplete preference which the bracket completion and 
control structure completion checks but it’s currently not exposed in the IDE 
UI. Do we want fine grained control over which parts of autocompletion we want 
active? That could be confusing.

Bracket highlighting does need a color pref… I guess if this is empty it could 
turn it off entirely if people want that.

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: Bug? ResizeControl Triggers From Outside of CustomControl with Assigned Behavior

[Monte Goulding via use-livecode]

> On 17 Jul 2017, at 9:42 am, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> I can't any use case where you would want any group to trap a mouse event 
> outside its rect. 

It sounds like you want sharedBehavior on and backgroundBehavior off

If it’s a background it behaves like it’s a layer between card and stack so all 
card messages travel through it. That’s the way backgrounds work and changing 
that would break a _lot_ of code!

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: Bug 20117: new rc2 sets a backdrop, and preferences for same

[Monte Goulding via use-livecode]

> On 19 Jul 2017, at 2:10 pm, Mark Wieder via use-livecode 
>  wrote:
> 
> Nothing but a backdrop. Takes over the screen. Everything else is hidden 
> behind the gray featureless backdrop. I had to alt-tab to a terminal window 
> (what if I didn't have one already running?) in order to kill -9 livecode.
> 
> And that means that there's no way to access the menu to undo the damage. I 
> had to remove my preferences files (which incidentally grew by a couple of 
> orders of magnitude) and recreate them.
> 
> No. I don't think that's overstating things *a touch*


So you had no access to either the view menu to change the setting or the file 
menu to exit normally? That is odd and it appears you reported it a while ago 
http://quality.livecode.com/show_bug.cgi?id=17323 


Well a fix for one or the other is going to be a blocker for this release

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: Bug 20117: new rc2 sets a backdrop, and preferences for same

[Monte Goulding via use-livecode]

> On 19 Jul 2017, at 1:42 pm, Mark Wieder via use-livecode 
>  wrote:
> 
> Yep. LiveCode (any version) is now completely unusable for me.

Completely unusable might be overstating things a touch don’t you think? There 
is a menu to remove the backdrop (View > Backdrop). Looking at the PR it was 
meant to only set the backdrop if users were still in the first run mode of the 
start center. We will need to investigate why it has impacted others.

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: Ethereal Breakpoints

[Monte Goulding via use-livecode]

> On 22 Jul 2017, at 9:55 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> I'm not having any trouble with the breakpoints per se but if you edit the 
> script with the dots in place they tend to migrate. When that happens you 
> don't always notice and it acts like they aren't working.

I haven’t looked at the code that tries to keep the like paired with the 
breakpoint but my gut feeling is to do it right you would want to set some 
metadata on the line of the field and then look for it when updating the 
gutter. I’ll try and find some time to take a look into it.

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: Ethereal Breakpoints

[Monte Goulding via use-livecode]

There are some cases where breakpoints are deliberately ignored. Any 
breakpoints when there is modal stack open and in resizeStack and moveStack 
handlers. You can debug these using the remote debugger only.

Cheers

Monte

> On 25 Jul 2017, at 1:37 am, Bob Sneidar via use-livecode 
>  wrote:
> 
> With me, I place a red dot, find an error in the script, edit the script 
> neither adding nor deleting any lines, save script, red dot does not wander, 
> but also does not break code execution. It just executed past it. 
> 
> I think this started with the unicode update. I will try copying my code to a 
> text only editor then back again, then retest. 
> 
> Bob S
> 
> 
>> On Jul 21, 2017, at 16:55 , J. Landman Gay via use-livecode 
>>  wrote:
>> 
>> I'm not having any trouble with the breakpoints per se but if you edit the 
>> script with the dots in place they tend to migrate. When that happens you 
>> don't always notice and it acts like they aren't working.
>> 
>> --
>> 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


___
use-livecode mailing list
use-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: SE Gutter better scroll tracking [Bugfix-20140]

[Monte Goulding via use-livecode]

> On 24 Jul 2017, at 5:00 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> I couldn't find a bug report, but the issue that bothers me more than a 
> timing delay is how existing breakpoints migrate to a completely different 
> line after a script edit. Suppose I add a line of code at some point above a 
> red dot breakpoint. Sometimes it works, moving the red dot down one line. 
> Other times it moves the dot a random number of lines below where it should 
> be, sometimes quite far away.
> 
> Since I don't have a repeatable recipe, I haven't reported it. This has been 
> going on for a long time, it isn't a new problem. I'm in the habit now of 
> removing existing breakpoints before any edit.

I was trying to figure this out yesterday. Nearest I can tell is it gets out of 
sync when you hold down delete and delete a number of lines or hold down return 
and add a number of lines. I’m not sure if there are other situations where it 
gets out of sync. It could be that Bob’s patch actually does fix it because I 
*think* it’s related to the delay and some of the parameters of the update 
handler being out of sync with the content of the editor by the time it’s 
actually run. We just need to be careful with any script that is run for every 
edit such as this 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: SE Gutter better scroll tracking [Bugfix-20140]

[Monte Goulding via use-livecode]

Hi Bob

Have you tried this out with very very long scripts > 1 lines? The reason 
there’s an update delay on a number of things is to reduce the risk of the 
field editing performance being effected.

Cheers

Monte

> On 23 Jul 2017, at 10:23 pm, Bob Hall via use-livecode 
>  wrote:
> 
> I have a proposed fix for the gutter lagging behind the scrolling of the 
> Script Editor field. As you will see, this is a big improvement for scrolling 
> in the SE. I had been messing around with this for a couple of months now and 
> have done a lot of testing. The way the Gutter is handled I’d say needs an 
> overhaul but for now, this will help in the near term.
> 
> Changes are minor to get this working. trying it out should only be attempted 
> by more advanced users. You MUST use LC 9.0dp8 and please, make sure you’ve 
> got a copy just incase it all blows up ;-)
> 
> https://github.com/livecode/livecode-ide/compare/develop...bhall2001:bugfix-20140
> 
> I’m not going to go into how to install the changes.
> 
> If anyone does install, please report back and let me know how it works (or 
> doesn’t) for you.
> 
> Thanks in advance,
> Bob Hall
> ___
> use-livecode mailing list
> use-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: Ethereal Breakpoints

[Monte Goulding via use-livecode]

> On 25 Jul 2017, at 8:31 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> You know, I really wish it could be (even) more helpful : in particular,  
> ignoring breakpoints within handlers called from a resizeStack handler.
> 
> I keep getting caught by this - setting a breakpoint in a handler which is 
> (indirectly) called from a resizeStack, and LC  gets completely frozen and 
> needs to be Force-quit.

Could you bug report this with an example? Both traceBreak and traceError 
iterate the executionContexts checking for moveStack and resizeStack so that 
should cover any handlers called from resizeStack.

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: Ethereal Breakpoints

[Monte Goulding via use-livecode]

> On 25 Jul 2017, at 8:37 am, J. Landman Gay via use-livecode 
>  wrote:
> 
>> You can debug these using the remote debugger only.
> 
> Does that still work? It never asks me any more.

It should. If it doesn’t for you could you bug report it please.

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: Mobile Check Bandwidth Function

[Monte Goulding via use-livecode]

> On 4 Jul 2017, at 6:50 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> >> And iOS only?  What do we do for the other 80% of the world?
> >
> > Android:
> > https://developer.android.com/reference/android/net/ConnectivityManager.html
> >  
> > 
> 
> I figured there was a parallel API for Android.  I guess my question was when 
> we might see feature completion on the script access for that in LC.


Actually we have access to basically anything you want on Android now via LCB 
and now that that’s the case if we provided an API for it we would do it via 
LCB too. I’m sure Ali could wrap it pretty quickly but it might be a good idea 
for the community to take it on and give us some feedback on our docs. The 
sooner people start wrapping and sharing code for system APIs the better.
 
https://livecode.com/using-infinite-livecode-for-android-to-create-native-controls-and-wrap-os-apis/
 


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: Master M in script editor of lc8.15

[Monte Goulding via use-livecode]

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


> On 3 Jul 2017, at 2:20 pm, james--- via use-livecode 
>  wrote:
> 
> Has anyone noticed the "Master M" (where the M is actually a blue tiled M) in 
> the top area of the script editor in LC8.15?
> I have checked both the commercial and business editions and both show it.
> It is not present in LC8.14 or lower.
> It doesn't do anything, just sits there.
> 
> Perhaps an upcoming feature or perhaps a slip.
> 
> Intrigued.
> 
> 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

___
use-livecode mailing list
use-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: Master M in script editor of lc8.15

[Monte Goulding via use-livecode]

Oh, dear I think that’s a slip on my part from one of my plugins

> On 3 Jul 2017, at 2:20 pm, james--- via use-livecode 
>  wrote:
> 
> Has anyone noticed the "Master M" (where the M is actually a blue tiled M) in 
> the top area of the script editor in LC8.15?
> I have checked both the commercial and business editions and both show it.
> It is not present in LC8.14 or lower.
> It doesn't do anything, just sits there.
> 
> Perhaps an upcoming feature or perhaps a slip.
> 
> Intrigued.
> 
> 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


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