Hi Dominik!
Thanks for the response. The “do shell script” is not the problem. I’ve already got the process running in the background outputing to a text file. I then read from the growing text file in a loop (inside the drop handler) so I can display the output (% completion information) periodically in a text view.
I’ve narrowed down the problem to the loop in the drop handler. If, for example, I run the following with a window (“main”), a box (“dropBox”) to drop the files in, and a text view (“tv”):
on awake from nib theObject
tell theObject to register drag types {"file names"}
end awake from nib
on drop theObject drag info dragInfo
set preferred type of pasteboard of dragInfo to "file names"
repeat with i from 1 to 30
delay 1
set contents of text view "tv" of scroll view "tv" of the window of theObject to i as string
end repeat
return true
end drop
the script itself works fine, displaying a counter in the text view for 30 seconds, but the finder freezes right after th drop even though I can access other running applications. After about 20 seconds, the file icons that I dropped onto theObject snap back to their finder locations and the finder works again. It’s as if the drop handler won’t release the files until it’s done or some timeout is exceeded.
I’ve tried putting the loop in the “on conclude drop” handler but I get the same response. I’ve used “ignore application resonses” which was suggested in a previous thread I found in my searches, but again no luck. I tried a demo application from John8’s website (“Dropper”) and it behaved the same way when I dropped a folder with a lot of files in it. I’d be curious if others get the same delay.
Obviously the above example isn’t realistic, but one of the benfits of “drag and drop” is the ease of handling multiple files, and these would typically be processed in a repeat loop. The solution would seem to be to put the loop somewhere else, maybe an idle handler, which to be honest I haven’t had much experience with. This seems like an akward work around, however. Perhaps the “timeout” before the files snap back to the finder can somehow be changed.
Hopefully I’m not being dense here and missing something obvious, but any feedback or ideas would be appreciated.
-Mike
P.S. Just to share so I’m not always leeching at this site, here is an alternative method to determine if a background process from a “do shell script” is running. Maybe this will be usefull to someone (unless of course someone finds a problem with the code). It uses the unix command “ps -p pid” where pid is a process id. If the process is running, the command returns a small table with the pid in it. If the process is not running, then the retruned table is empty.
This starts the process in the background, writes output to a temporary file, and saves the process id of the process.
set procID to do shell script "your process " &> " & "tempfile" & " & echo $!"
the this checks to see if the process id is in the table returned as text by the “ps -p pid” command. Use it to check periodically if the background process is still running.
on processRunning(processID)
set checkID to do shell script "ps -p " & processID
if (offset of processID in checkID) is equal to 0 then
return false
else
return true
end if
end processRunning