a blocking download

Andrew Kluthe andrew at rjdfarm.com
Mon Jun 14 14:47:10 CDT 2010

I made myself an update stack that checks a local text file with version
information for my program components and compares it to the text file
pulled from my update server. The entries that don't match get downloaded
with libURLDownloadToFile. 

I have am trying to have it go through one at a time and report on the
download status of each compnent with  one progress bar and a long window.

The problem I have is that when it loops through the list of files to
download, it triggers all the download handlers at once. So even if it
doesn't download all the files in sequence, the log reports that all the
downloads start before the first one finishes.

Is there a way to make my loop wait till the current component download
handler is totally done? Is this where  I need to use a "blocking" version
of a download file? Below is a mix of revlike psuedocode for clarity's sake.

on goList
get localList
get webList
put getDifferences(weblist, locallist) into downloadList
repeat for each line i in downloadList
downloadComponent( line i)
end repeat
end goList

on downloadComponent pStackName
   put "Downloading " & pStackName after fld "log"
   put empty into gDownloadedFile
   put pStackName into gDownloadedFile
   put "C:/FarmOffice/LeaseManager/" into sBasePath
   put "http://somethingHere.com/Update" into sWebPath
   libURLSetStatusCallback "showProgress", the long name of me
   hide scrollbar "download"
   libURLDownloadToFile sWebPath & pStackName, sBasePath &
end downloadComponent

Basically, I don't want the next downloadComponent hanlder to go until the
previous one has finished.

note: the callback handlers and the handler for the progress bar are
intentionally left out as they would function just fine if I could make the
loop wait on downloadComponent.

View this message in context: http://runtime-revolution.278305.n4.nabble.com/a-blocking-download-tp2254935p2254935.html
Sent from the Revolution - User mailing list archive at Nabble.com.

More information about the use-livecode mailing list