Re: urgent iOS internet issue (url request timeout setting?)

OK, I think I have a workaround although I’m not sure whether it is a good solution or not. If I include the line... tsNetLibUrlReuseConnection false ...in my preopenstack handler then the delay/hang seems to disappear – i.e. I get an almost immediate response if the url isn’t available. I’m

urgent iOS internet issue (url request timeout setting?)

OK – I have a bit of a serious issue on iOS where if I lose wifi connectivity the first attempt to get data from a url causes problems. I’m attempting to upload a file to Dropbox (that stuff all works fine) and I do an initial test to see whether the device is online (by trying to access a

Re: Param Naming - Object by Reference Best Practices

On Wed, May 31, 2017 at 5:17 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > I almost always pass long IDs as object references, e.g.: > > put the long ID of grc "portal-title-bkgnd" into tObj > DoSomethingWith tObj > > Complete, absolute, unambiguous, and, if

Re: Param Naming - Object by Reference Best Practices

I almost always pass long IDs as object references, e.g.: put the long ID of grc "portal-title-bkgnd" into tObj DoSomethingWith tObj Complete, absolute, unambiguous, and, if used repeatedly, cached. -- Richard Gaskin Fourth World Systems Software Design and Development for the

Re: Param Naming - Object by Reference Best Practices

On 5/31/17 4:06 PM, Sannyasin Brahmanathaswami via use-livecode wrote: One does not expect this to be improperly evaluated put "graphic portal-title-bkgnd" into pObject What do you do? And why? I suspect the engine is trying to do subtraction since it can't tell you are referring to a

Re: Param Naming - Object by Reference Best Practices

Forgot the trailing "quote" after "portal-title-bkgnd" so it would actually be put "graphic" & quote & "portal-title-bkgnd" & quote into pObject On Wed, May 31, 2017 at 3:49 PM, Mike Bonner wrote: > try.. > put "graphic" & quote & "portal-title.bkgnd" into pObject > > As it

Re: Param Naming - Object by Reference Best Practices

try.. put "graphic" & quote & "portal-title.bkgnd" into pObject As it is, you end up with pObject containg: graphic portal-title-bkgnd.. Meaning portal MINUS title MINUS bkgnd (since its unquited) and the engine fails because its confused about what to do with it. Quoting the name of the graphic

Re: HTML5 deployment: progress comes into sight

"Synchronous" means here that the callback is done in the order it appears in the list of js instructions, i.e. "synchronous to the instruction order". If you say in your js function instruction1; callback1; instruction2; callback2; then you can't control what's done first. This is

Re: HTML5 deployment: progress comes into sight

Call, send , dispatch, do script ... It is very impressive how the core team can still have all that messaging in mind while developing LC Builder. Now why not use kind of a mnemonic naming in LCB e.g. sendHandler callHandler dispatchHandler doHandler ? We could still have

Param Naming - Object by Reference Best Practices

The more libs/behaviors we use the more we are passing params that reference objects This fails put "graphic portal-title-bkgnd" into pObject setGradient pObject command setGradient pObject local tNewGradientArray # be careful when cutting and paste to and from email # tabs may get replace

Re: Livecode 9 and converting to Stack Behaviors

Lovely. Or should I say, Levure-ly! ;-) Bob S > On May 31, 2017, at 13:01 , Trevor DeVore via use-livecode > wrote: > > If you are creating a script only stack then it can't be a substack. It is > a text file with the name of the stack and the code, nothing

Re: Livecode 9 and converting to Stack Behaviors

On Wed, May 31, 2017 at 2:38 PM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Hi all. > > I have been reviewing Trevor's Youtube video on using Livecode 9 to create > behaviors much more easily. Looks cool, I'd like to start working on this. > But there was a place where

images in field: pointers or copies?

I have an image in a stack and a field that displays that image several times within its contents using imageSource. I've noticed that when I resize the image the renderings of it in the field instantly resize as well - cool. This lends me to believe that any images in fields aren't rendered

Livecode 9 and converting to Stack Behaviors

Hi all. I have been reviewing Trevor's Youtube video on using Livecode 9 to create behaviors much more easily. Looks cool, I'd like to start working on this. But there was a place where he took a substack and made it a mainstack and saved it to the disk, saying you needed to do this before

Associating additional Documents types for a Standalone

So in LiveCode's Staandalone builder, we can specify an icon for the application and a file extension and icon for a single document. How do we add more icons and associated file extensions to a standalone under OSX and Windows. For OSX, after you build the standalone, you can open the app

Re: HTML5 deployment: progress comes into sight

I have a feeling that Alejandro's stack was running a while back. Richmond. On 5/31/17 4:03 pm, Mark Waddingham via use-livecode wrote: On 2017-05-31 13:18, Richmond Mathewson via use-livecode wrote: Weel you could start with ALL SVG images made in Inkscape: monochromatic "thingies" have

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 15:43, hh via use-livecode wrote: The problem is the "one-way"-only: I can't see any way to go back, from the page to the standalone. That is a very good point. = The browser widget has jsHandlers available. = The standalone has to get the data from the page by guesses, in a

Re: HTML5 deployment: progress comes into sight

A callback is not synchronous, his point was that it would be nice to communicate synchronously between LC and JS, rather than use complex callback chains. I agree with him, but I don't think there is a universal way to do that, just because some things in JavaScript, like rendering an image

Re: HTML5 deployment: progress comes into sight

@BR wrote: ... "What's very difficult, as you write in detail, are "callbacks" for _synchronous_communication..." Callback functions? In my mind, a "callback" is always asynchronous -? Let us say in Javascript - passing the function name and parameters of Javascript through LCS/LCB and then

Re: HTML5 deployment: progress comes into sight

> > hh wrote: > > Part [1], the current thread, will hopefully allow for example to have > > the "sample > > stacks" imageToolKit or the recent SVGplay-stacks in a HTML5 > > standalone. The speed > > results will be very interesting. > > Mark W. wrote: > If you have pure JS libraries you want to

Re: Using callbacks within LC and JS

Yah - setting up threads that include JS event listeners was a big pain for Augmented Earth - I have no suggestions for simplifying that part. That bit of complexity seems unavoidable to me. Sent from my iPhone > On May 31, 2017, at 9:15 AM, hh via use-livecode >

Re: Using callbacks within LC and JS

Sadly this is only valid if the js jobs you do are non-threaded and do not use workers, rather than being a matter of logic. But the speed gain by using javascript in the browser is often only due to multi-threading. We don't have always control about all parts of a js library. We can't "split"

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 14:30, Jonathan Lynch via use-livecode wrote: Would it be possible to create a widget that links to an Inkscape library that processes svg data and sends it back to the widget to be displayed the way PNG is displayed? No - two issues: 1) Inkscape is an application - not a C

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 13:18, Richmond Mathewson via use-livecode wrote: Weel you could start with ALL SVG images made in Inkscape: monochromatic "thingies" have limited use. Or how about we start with the *standard* profiles for SVG and work up from there: https://www.w3.org/TR/SVGTiny12/ i.e.

Re: HTML5 deployment: progress comes into sight

Would it be possible to create a widget that links to an Inkscape library that processes svg data and sends it back to the widget to be displayed the way PNG is displayed? Sent from my iPhone > On May 31, 2017, at 7:18 AM, Richmond Mathewson via use-livecode >

Re: HTML5 deployment: progress comes into sight

Weel you could start with ALL SVG images made in Inkscape: monochromatic "thingies" have limited use. Richmond. On 5/31/17 11:48 am, Mark Waddingham via use-livecode wrote: On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote: A native svg object that accurately displays all svg files

Using callbacks within LC and JS

This is in response to a different thread, but worth discussing on its own. I just wanted to explain my view on why callbacks are not as horrible as they seem at first, if one structures the script logically. The below code explains: On LCcontrolScript pcommand,pdata If pcommand = empty then

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 10:38, Jonathan Lynch via use-livecode wrote: A native svg object that accurately displays all svg files is essential. I strongly support Mark's point on that issue. This is not reinventing the wheel - it's attaching the already invented wheel to the wagon. Heh - well more

Re: HTML5 deployment: progress comes into sight

A native svg object that accurately displays all svg files is essential. I strongly support Mark's point on that issue. This is not reinventing the wheel - it's attaching the already invented wheel to the wagon. Sent from my iPhone > On May 31, 2017, at 4:26 AM, Mark Waddingham via

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 04:31, Sannyasin Brahmanathaswami via use-livecode wrote: Does this relate at all to " LCB to bind to JavaScript APIs" ? Directly? No - they are two distinct things. However, running JavaScript (via LCB) in the HTML5 engine is equivalent to running JavaScript (via LCB) in a

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 09:01, Dan Brown via use-livecode wrote: I'll also add that for all the wonderful possibilities that LCB brings there is a very real danger that countless hours will be spent using it to re-invent the wheel. That is true of every language ever implemented ;) However, one of

Re: HTML5 deployment: progress comes into sight

On 2017-05-31 09:02, hh via use-livecode wrote: If I understand correctly Mark speaks currently about [1] using a browser widget within the _HTML5 deployment_ (emscripten). Heh - not in this case - however, it is an interesting idea. With the 'do as javascript' functionality, scripts could

Re: HTML5 deployment: progress comes into sight

The browser widget is essentially kind of a GUI to libbrowser, cleverly made. @Dan Using all these js libraries is already possible (where the inherent HTML5 of the widget allows that -- different by platform), just do it. Examples of going that way are among the most recent 10 of "Sample

Re: HTML5 deployment: progress comes into sight

I'll also add that for all the wonderful possibilities that LCB brings there is a very real danger that countless hours will be spent using it to re-invent the wheel. Take for instance the displaying of svg's. This is a solved problem in the browser and has been for a long time but in native