libURL gone mad

[Charles Warwick]

Hi Richard,

I am keen to see as many of these issues resolved as possible, so please 
let me know if you have any more details for requests that don't seem to 
ever complete or error.

By the sounds of it, you are using a commercial version of LC that 
includes tsNet and its libUrl wrapper.

There are a number of fixes for tsNet that will be coming out in 8.1RC2 
when it is released (they did not quite make it into RC1).

In particular, the "tsneterr: Sync request already in progress" should 
only be seen if you are calling the tsNet handlers directly, not if you 
are using libUrl.  In RC2, you will only ever see the standard "Previous 
request not yet completed" error if you are using libUrl commands.

It also has some improved request handling that will hopefully resolve 
some of issues with requests not completing properly.

And in answer to your main question there.... this release will also 
include a new function tsNetIsSyncBlocked() that will do exactly what 
you want.

This function will return true if an existing synchronous network 
request is in progress (libUrl commands like post x to url y, put url x 
into y, etc...) that will prevent another synchronous request from being 
initiated (async or non-blocking requests can still be made).  Note that 
in the LC Business edition, multiple requests can be sent at the same 
time, so this will always return false.

So, to rewrite the handler you have below, you will be able to simply do:

on mouseUp
     if tsNetIsSyncBlocked() is true then
         beep
     else
         get url tURL
         if the result is empty then
             put it into image 1
         else
             answer the result
         end if
     end if
end mouseUp

Regards,

Charles


On 2/09/2016 8:18 am, Richard Gaskin wrote:
> My quest today began with a seemingly simple question:
>
> If I have a button that gets data from a URL via libURL, how do I 
> prevent a second request if the user double-clicks?
>
> In this case we have too many entry points to disable and re-enable 
> the controls that trigger URL access for that to be a practical 
> option. Besides, occasionally libURL neither completes a URL request 
> nor provides an error for it, so relying on disabling a control risks 
> getting into a state where the control is disabled with no way to know 
> to re-enable it.
>
> In brief, sometimes GET or POST with libURL returns with no data in 
> either "it" or "the result".
>
> And looking through the forum and list archives, it seems I'm far from 
> alone in this experience.
>
> Then today I was working on this code in v8.1, when I encountered this 
> new error message:
>
>   tsneterr: Sync request already in progress
>
> Hmmm...so now we need to rewrite the error handling for our URL code 
> to account for new strings?  Good to know.
>
> So....
>
> Does anyone here have a handler which reliably accesses a URL while 
> preventing re-entrant attempts until the first one completes?
>
> The example Dave Cragg offers on his web site is:
>
>  global gUrlBlocking
>  on mouseUp
>       put "http://www.xxxxxx.com/images/mykids1.jpg" into tUrl
>       if gUrlBlocking is true then
>         beep
>       else
>         put true into gUrlBlocking
>         get url tUrl
>         put false into gUrlBlocking
>         if the result is empty then
>           put it into image 1
>         else
>           answer the result
>         end if
>       end if
>   end mouseUp
> http://www.lacscentre.com/liburl/liburldoc.html#post
>
> ...but in practice I find libURL occasionally doesn't complete a 
> request, nor provides any way of letting me know that, so gUrlBlocking 
> never get cleared.
>
> Who among us mortals has found a way to adequately handle 
> error-checking in libURL with reliable consistency?
>
> I imagine I'm missing something simple here.  Hoping that's the case, 
> anyway.
>
> Fingers crossed....looking forward to any reasonable tips for reliable 
> URL access....
>