more problems with ftp

Alex Tweedly alex at
Sun Sep 12 17:07:44 EDT 2004

At 21:54 12/09/2004 +0200, Klaus Major wrote:

>Hi rand,
>>  Hi, all. I really appreciate the feedback you guys gave me on my ftp
>>problem -- I was trying to download a series of files and I needed to know
>>how to use the libURLDownloadToFile command properly. My problem was that
>>files weren't downloading proprerly, and I figured it was because I was
>>using a "blocking" strategy with a looping "put" command. But I continue to
>>have problems and I'm hoping someone can give me a clue. Here's the problem:
>>  Following similar suggestions from Sarah Reichelt and Andre Garzia, I
>>created special handlers that use the libURLDownloadToFile command, like so:
>>  Then I have a handler
>>on downloadDone
>>  --
>>end downloadDone
>>  which checks to see if the download queue is empty, and if so, quits. The
>>problem is that on downloadDone never seems to get called.
>Please make sure that BOTH handlers, the one that calls the 
>AND "DownloadDone" are in the SAME script!

I'm bothered when you say "checks to see if the download queue is empty, 
and if so, quits".

The downloadDone handler will be called when each file has completed 
downloading (i.e. once per call to libURLDownloadToFile, so it needs to 
exit each time.

>>There must be an
>>error in downloading the first file, which has the correct name in the local
>>directory, but is empty.
>>  well, there is a stunning array of potential problems, i am realizing. but
>>when i do a test for an error message on download, i get:
>>"error, url is currently loading"
>>  what is this about, since the handler that called that url should be long
>>done? is there a way to wipe the ftp slate clean?

libURLResetAll should do it.

Here's a snippet of code that downloads and displays photos; the photos are 
downloaded into a local disk-based cache, and displayed from there; the 
rest of the code is downright confusing, so this is just the business part 
of it ....
btw - I have very high expectation that these transfers will succeed, 
because the photo names are generated automatically, so it's very unlikely 
there will be failures, therefore there's not as much error checking as 
would normally be desirable.

This comes at the very end of the handler "display_photo"

   put "d:/filecache/"&thisPhotoName into cacheName
   libURLSetStatusCallback "downloadStatus", the long ID of me
   libURLDownloadToFile fname, cacheName, "downloadComplete"

end display_photo

on downloadComplete
   get the URLStatus of remoteName
   if it <> "downloaded" then
     set the visible of field "MyField"  to true
     put "download status is" && it && "for" && remoteName && "into" && 
thisPhotoName & cr after msg
   end if
   set the visible of field "MyField"  to false
   put URL ("binfile:d:/filecache/"&thisPhotoName) into image "MyImage"
   put empty into thisPhotoName
   go stack "Photo Viewer Window"
end downloadComplete

on downloadStatus
   get the URLStatus of remoteName
   if it <> "downloaded" then
     set the visible of field "MyField"  to true
     put "Downloading:" && thisPhotoName && the URLStatus of remoteName 
into field "MyField"
   end if
end downloadStatus

hope this helps,
-- Alex Tweedly.

More information about the use-livecode mailing list