This is a chunk of script that checks the processing status of an application every so often until it finishes, at which point the rest of the script continues. It works fine when run from within the Script Editor but repeats indefinitely when the script is run as an application. Anyone have any insight?
Thanks,
WF
set C1status to ""
repeat until C1status = "processed"
delay 5
tell application "Capture One PRO"
launch
set C1status to (job state of batch job -1 of batch queue 1) as string
end tell
end repeat
Try to put a display dialog command in the script. Maybe the result different than “processed”.
set C1status to ""
repeat until C1status = "processed"
delay 5
tell application "Capture One PRO"
launch
set C1status to (job state of batch job -1 of batch queue 1) as string
display dialog C1status as text
end tell
end repeat
Thanks, but I already made sure of that. The issue is definitely running the script as a stand-alone app vs. running it from the script editor. Does anyone know why the behavior changes?
repeat
delay 5
tell application "Capture One PRO" to ¬
if ((get job state of batch job -1 of batch queue 1) as string) is "processed" then ¬
exit repeat
end repeat
I don’t have Capture One PRO. Is the value of a ‘job state’ actually text, or a keyword defined by the application? If it’s the latter, it may be that, in Script Editor, the script can coerce the keyword processed to the string “processed” because Script Editor has access to the decompiler. A script saved as an application though, will only see the compiled code behind the keyword, and won’t be able to coerce that to the text that your repeat is expecting.
In other words: does this work?
set C1status to ""
repeat until C1status = processed -- No quotes.
delay 5
tell application "Capture One PRO"
launch
set C1status to (job state of batch job -1 of batch queue 1) -- No coercion.
end tell
end repeat
set C1status to ""
tell application "Capture One PRO"
launch
repeat until C1status = processed -- No quotes.
delay 5
set C1status to (job state of batch job -1 of batch queue 1) -- No coercion.
end repeat
end tell
Or (if you don’t need at all the var C1status later in your script):
tell application "Capture One PRO"
launch
repeat
delay 5
if (job state of batch job -1 of batch queue 1) is processed then exit repeat
end repeat
end tell
Thanks for the replies. It appears Bachman and everyone else were on the right track after all. After fiddling around with it more, I realized that that Capture One Pro returns “processed” to the script when running in the Script Editor and “«constant ****Sprd»” to the script when run as a stand-alone app. The scripting support in Capture One Pro is pretty minimal and buggy, but in this case it looks like the Script Editor is doing some kind of translation behind the scenes. Anyone know how to do this manually? It’s more of a curiosity at this point, as I have the script working. I now check to see if the status is “«constant ****Sprd»”
Ah yes. Launch just once, then repeat. I didn’t even look at that!
There’s also this:
tell application "Capture One PRO"
launch
repeat until (job state of batch job -1 of batch queue 1) = processed -- No quotes round 'processed'.
delay 5
end repeat
end tell
Although possibly a ‘get’ might be necessary:
tell application "Capture One PRO"
launch
repeat until (get job state of batch job -1 of batch queue 1) = processed -- No quotes.
delay 5
end repeat
end tell
Capture One Pro undoubtedly returns the same thing to the script in both cases: ie. the compiled token for its ‘processed’ keyword. It’s the ‘as string’ coercion in your original script that returns either the string “processed” or the string “«constant ****Sprd»”.
The point of my earlier post was that if testing the ‘job state’ returns a constant, you should test for that constant in your script (as in the scripts above, using the keyword for that constant) and not try to coerce it unnecessarily to string. That way the script should work in both Script Editor and by itself. Did you try that?
Appart from that, the real point was including the “processed” keyword (no quotes ;)) inside the tell block, so it could be understood by the compiler. But this exercice of quote-quoting-quoted-stuff is yet so long. Finally, you found and solved the issue.
OT, seems that the Script Editor is able to coerce-to-string certain keywords in certain contexts (targetted apps in the current tell block?), something which I would consider a bug, as well as any hidden and undocumented coercion. IIRC, I think I remember this behaviour in the past (OS 9 and back?), something I just fixed and ignored forever (?)
It’s been around for a while. You notice the difference results with application classes and constants:
tell application "Finder"
display dialog (folder as string)
end tell
--> In Script Editor: "folder"
--> Otherwise: "«class cfol»"
But keywords for AppleScript’s own classes are successfully coerced however a script is run, presumably since the script has its own copy of AppleScript.
Error messages behave similarly:
tell application "Finder"
set fred to folder "non-existent folder" of desktop
end tell
--> In Script Editor: Finder got an error: Can't get folder "non-existent folder" of desktop.
--> Otherwise: Can't get «class cfol» "non-existent folder" of «class desk» of application "Finder".
Well, thanks a lot everyone. This one little issue has been a good learning experience for me. Everything does work as expected if I put the whole bit of code inside the Capture One tell block. Of course, the variable C1status = processed (no quotes) isn’t then usable outside of the tell block. Thanks again!
