Load URL doesn't send message

[Jim Bufalini]

I hadn't monitored this list for a couple of days, and just now came across
this thread. I am having a similar problem with libURLDownloadToFile. In my
case, there are 873 files being FTP downloaded. The problem is, in all but
about 10 cases, my handler does receive the message. But, it never gets all
873. The closest I've gotten is 872 out of 873 by increasing a wait from 0
to 500 milliseconds, in the handler itself, which slows the process down
even more than it already is! The missing messages seem to occur after half
way through.

At first I didn't know if the files were not being downloaded, or I just
wasn't getting the message. It turns out the files are downloaded, just a
missing message.

Also, a couple of other things. The correct return code is "downloaded" not
"cached" as the documentation indicates. There is never a return code of
"cached." The only other return code I've seen is an occasional "error" but
it appears there is a retry on these. Also there is apparently no need for
an unload URL tURL, as the cachedURLs is always empty.

The pertinent parts of the code are:

This queues the 873 files for download

 libURLSetFTPStopTime 30
    <initialize progress window stack progress bar>
    wait 0 milliseconds
    -----
    repeat with i = 1 to the number of lines of tFileList
      put line i of tFileList into tWebFile
      put tWebfile into tLocFile
      replace tFtpRootDir with tLocDir in tLocFile
      -----
      <update progress window stack progrogress bar>
      wait 0 milliseconds
      -----
      libURLDownloadToFile tWebFile,tLocFile,tResult
    end repeat
    <reset progress window stack progress bar to 0>
    wait 0 milliseconds


on tResult tURL, tURLStatus
  wait 0 milliseconds

  Switch tURLStatus
  case "cached"
    # This never happens
    Answer "Got a cached return code!" && tUrl && tURLStatus
    breakpoint
  case "downloaded"
    <increment progress bar>
    -----
    #Test code
    put tURL && " - " && tURLStatus & "(" & the uProgress of stack
"winProgress" && \
        "of" && the number of lines of tFileList & ")" & CR
    put tURL && " - " && tURLStatus & "(" & the uProgress of stack
"winProgress" && \
        "of" && the number of lines of tFileList & ")" & CR after testUrls
    #End test code
    -----
    get the itemDelimiter
    set the itemDelimiter to "@"
    put the last item of tURL into tFileNm
    replace the last item of tFtpRootDir with "" in tFileNm
    set the itemDelimiter to it -- put back whatever delimiter was there
    set the uFeedBack of stack "winProgress" to "Downloaded:"  && \
        "(" & the uProgress of stack "winProgress" && \
        "of" && the number of lines of tFileList & ")" && CR & LF & tFileNm
    -----
    -- unload URL tURL -- don't need
    -----
    if the uProgress of stack "winProgress" = the number of lines of
tFileList  then
      answer "Done! The web site files have been downloaded."
    end if
    break

  default
    /*
    don't need - only get a occasion "error" code and it retries
    */
    break
  end Switch

end tResult

Jim

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com
> [mailto:use-revolution-bounces at lists.runrev.com]On Behalf Of Dave Cragg
> Sent: Friday, July 29, 2005 1:32 AM
> To: How to use Revolution
> Subject: Re: Load URL doesn't send message
>
>
>
> On 29 Jul 2005, at 09:37, Dave Cragg wrote:
>
>
> >
> > The things that could cause the message not to be sent that I can
> > think of:
> >
> > An "unload url" or clearing of  the pendingMessages after the
> > message has been sent but before it is handled. The likely place
> > for this kind of thing would be in the status callback handler.
> > After a succesful load, the final  callback message gets sent just
> > before the "load message", both sent in 0 milliseconds. So if your
> > callback handler does one of these things when the status is
> > "downloaded", the message won't get sent.
> >
> > So I'd look at the callback handler first.
> >
>
> Another area to look at in your script would be just after the load
> call. Anything there that might stop background scripts running (a
> runaway repeat or a wait) or that might clear the pendingMessages or
> unload the url could be an issue.
>
> Cheers
> Dave
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>