If you set your authentication cookies with the "set the httpHeaders to <myHeaders>" command beforehand, you actually can use
Code: Select all
put URL("serverpath") into URL("binfile:/localpath")
type code. I wouldn't recommend it though, for a file download, especially a large one.
libURLDownloadToFile will be much more robust and you can block it by using the callback function, and/or libURLSetStatusCallback. For instance
Code: Select all
local sDownloadStatus
-- a script local variable to be available to the download handler and the callback scripts
on getDownloadFile
-- do any preparation stuff like set the httpHeaders
-- set a callback function to update the status continually
libURLSetStatusCallback "updateStatus",the long ID of me
-- start the download, and reference the callback function to be called when the download is complete
libURLDownloadToFile (theServerUrl,tDestinationPath),"downloadComplete"
wait until sStatus is "Download complete" with messages
end getDownloadFile
on updateStatus pUrl, pStatus
put pStatus into sStatus
-- since this is a continually updated status message, we might as well show it
put sStatus into field "fldStatus"
-- putting it into a field is a little crude, but if the first item of pStatus is "loading" we could use items 2 and 3 to update a progress bar instead.
end updateStatus
on downloadComplete
put "Download complete" into sStatus
put sStatus into field "fldStatus"
-- once the file is downloaded, cancel the callback function by setting it without parameters
libURLSetStatusCallback
end downloadComplete
This is a double-whammy. We can make the getDownloadFile blocking by waiting for the downloadComplete callback function to be triggered, which would, on its own, not allow for any progress feedback. We could also make it blocking by using the status callback and waiting for that to contain "downloaded" instead, and have the advantage of being able to display feedback on the download progress. Or almagamate the two, as above, so that you can show progress feedback while the file is being downloaded, and still use the downloadComplete callback (my arbitrary name) to handle the blocking. No special advantage to that (mixing the two), I just did it this way to show you different methods. You do get more information (especially if there is an error) by testing the status callback function results, so you could check for pStatus in the updateStatus handler containing "error" or "timeout" for instance and exit the download handler gracefully.
