From charles at techstrategies.com.au Thu Jun 1 05:47:19 2017 From: charles at techstrategies.com.au (Charles Warwick) Date: Thu, 1 Jun 2017 19:47:19 +1000 Subject: urgent iOS internet issue (url request timeout setting?) In-Reply-To: <532779C8-D70D-4C02-9844-A56606961CDF@unimelb.edu.au> References: <85496682-C456-4143-9127-28337E28CB02@unimelb.edu.au> <3B53EC48-B345-484E-B50D-DB580FF8266E@unimelb.edu.au> <532779C8-D70D-4C02-9844-A56606961CDF@unimelb.edu.au> Message-ID: <2c71f8fe-2a5d-c19a-8d7b-ee0fe9afaa89@techstrategies.com.au> Hi Terry, I think this is the same issue as has been reported here that I am looking into: http://quality.livecode.com/show_bug.cgi?id=19656 At this point in time, issuing "tsNetLibUrlReuseConnection false" is the best solution, as this will stop tsNet from trying to re-use an existing open connection to a server. If you are using tsNet functions directly, the equivalent option can be set by using tSettings["no_reuse"] to true and passing that to the function. For example: local tHeaders, tRecvHeaders, tResult, tBytes, tSettings put true into tSettings["no_reuse"] put tsNetGetSync("http://www.livecode.com", tHeaders, tRecvHeaders, tResult, tBytes, tSettings) into tData Best Regards, Charles On 1/06/2017 1:24 PM, Terry Judd via use-livecode wrote: > 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 not at all sure what this achieves but it seems that a new connection that can?t connect doesn?t experience the same problem as an existing connection that was previously successful. > > Anyway, panic averted for now but any insights into the best way to deal with this stuff would be appreciated. > > Terry... > > > > On 1/06/2017 11:44 am, "use-livecode on behalf of Terry Judd via use-livecode" wrote: > > 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 url). If it is I proceed with the upload, if not I just save a local copy of the file. Anyway, the first time I do the test the request seems to take forever (minutes?) ? which I don?t have (I need the request to be completed within a few seconds). The second time around is ok though. > > Any ideas on how I prevent this initial ?hang?. Is it possible to set a shorter timeout or something? > > Terry... > _______________________________________________ > use-livecode mailing list > use-livecode at 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 at lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode From mark at livecode.com Thu Jun 1 06:27:43 2017 From: mark at livecode.com (Mark Waddingham) Date: Thu, 01 Jun 2017 12:27:43 +0200 Subject: HTML5 deployment: progress comes into sight In-Reply-To: References: Message-ID: <9fa1f4e86ce1db10e4bd15a6f95cd3d9@livecode.com> On 2017-05-31 23:13, hh via use-livecode wrote: > 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. The problem here is what syntax to use in LCS to 'call into a widget' - widget's need to be able to expose public handlers which can be called from LiveCode Script (not just properties and events). > Now why not use kind of a mnemonic naming in LCB e.g. > > sendHandler > callHandler > dispatchHandler > doHandler ? The problem is that all the keywords (naturally) associated with 'calling' something in another context are already taken (i.e. send, call, dispatch, do) and their context is the script of the object. So: call "foo" in widget 1 Means send the message 'foo' to the *LiveCode Script* side of the widget - it is not entirely clear how that could work to mean 'call the handler 'foo' exported by the widget's implementation'. I've pondered 'invoke' as a new keyword - but I'm not sure how much I like that, but it would 'fill the gap'. The other way to slice and dice things is to make it so that any handlers you want to export to act on the widget internally are added as 'library handlers'. e.g. widget foo public handler CopySpecial() returns nothing ... do magic stuff ... end handler end widget Would export fooCopySpecial() as a function accessible from LCS where you can do: fooCopySpecial(the long id of widget 1, ...) Or similar. This is closer to how the engine does syntax - which are all non-object based functions in C++, which then dispatch to the object. e.g. copy widget 1 Ends up calling a C++ function: MCInterfaceExecCopyControl(ctxt, ptr-to-widget-1) Which then does: ptr-to-widget-1->copy() > We could still have > > do