applescript strange error

[Michele Cremaschi]

Hi dear,

I met a strange error arising from a applescript cue - one of these
error happens sometimes, not always, and I can't figure out which are
the conditions that causes it. The strange thing is that sounds like a
syntax problem - but it isn't, the same script without any changes
compiles fine if you click the "compile" button. Attached you can find
a snapshot.
The workspace is quite complex, but it's here:
https://dl.dropboxusercontent.com/u/6974/AllaFieraDellEst%203.2%20QLab3.cues

The error happens (sometimes!), firing "Spettacolo sequenza
principale" till the cue "registrazione strofa", that's where it could
arise.

The applescript code is:

-- activate application "Syphon Recorder"
tell application "System Events"
tell process "Syphon Recorder"
-- click menu item "Start Recording" of menu 1 of menu bar item "File"
of menu bar 1
if (exists checkbox "Stop Recording" of window "Syphon Recorder") is true then
click checkbox "Stop Recording" of window "Syphon Recorder"
end if
end tell
end tell


The error is:
ERROR: expected end of line but found "" (-2741)
and it highlits the " after the word "process".


Any Idea?

regards

michele

--
_________________________________________________________________
Michele Cremaschi
http://michelecremaschi.it
ph. +39.320.2992681

[Daniel Richert]

Hi.

Im having the same:

Here is a script that has worked before, but now after updating Qlab to 3.2.1 I get

this error:

ERROR: Expected class name, etc. but found identifier. (-2741)

the script:

set userDelta to -35

repeat with eachCue in (selected of front workspace as list)

set post wait of eachCue to ((duration of eachCue) + userDelta)

set continue mode of eachCue to auto_continue

end repeat

[Rich Walsh]

I'll have a look, but I suspect you need a tell QLab block if you're running it as a separate process don't you? There was something in the release notes about that.

Rich

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[micpool]

Yes,

If you want the script to run as in the old versions just untick the run as separate process tick box.

I can't remember if this is ticked by default on old shows opened in 3.2.

If you want it to run as a separate process put it within the default Qlab tell block which is now

tell application id "com.figure53.qlab.3" to tell front workspace

end tell

Mic

[mic]

Hi,

does this change reflects somehow on my case also? 

Any applescript guru has some hints about the error  I get please?

ciao thanks

michele

[Rich Walsh]

What is your case and your error, specifically?

Rich

[mic]

hi,

the one reported in the first mail of this thread: https://groups.google.com/forum/#!topic/qlab/h7ZFBJzv0kU

regards

michele

[Rich Walsh]

Right, firstly it looks like QLab's implementation of the compiler's error reporting is currently a little buggy: for example, create a new script cue, replace the contents with just "tell" and hit Compile Script – the script stays in a monospaced font but the "Successfully compiled." message persists. Add a single return after "tell" and you get a correct error message. It's very easy to find any number of script expressions that don't compile but don't explain why not.

What's more, I can't remember right now, but didn't QLab used to compile newly entered scripts straightaway when committing the script? It's also inconsistent about reporting new scripts that can't be compiled as broken…

I don't have time to fiddle around in QLab these days, otherwise I might have spotted these earlier. I think the whole script compiling implementation needs a bit more testing I'm afraid.

Now, as to your problem: it's not related to the need to include an explicit tell block when running a script as a separate process. This is basically the same fundamental difference between writing in AppleScript Editor and old QLab: you need to tell the script where to send its commands, and in old QLab it was implicitly targeting up the inheritance chain to QLab's AppleScript runner; not true in a separate process.

Without Syphon Recorder I can't test your workspace throughly but what I suspect has happened is that the script has thrown an unhandled error at some point and broken; upon recompiling it's hit a bug. Does the Script Cue recompile in this error state just by hitting the Compile Script button? The error message makes no sense, so it does suggest a bug.

Rich

[mic]

Hi Rich,

thanks a lot.

The input you gave, that applescript error message is not always the right one, open possibilities to investigate. Anyway, when i received it:

- Syphon Recorder was open

- it was in recording state, so the button "Stop Recording" existed.

Moreover, simply clicking "compile" button brought to a correct re-compilation, without the need of any change to the script itself.

ciao

michele

[Daniel Richert]

Thanks a lot.

[Christopher Ashworth]

On Wednesday, September 17, 2014 8:16:03 AM UTC-4, Rich Walsh wrote:

Right, firstly it looks like QLab's implementation of the compiler's error reporting is currently a little buggy: for example, create a new script cue, replace the contents with just "tell" and hit Compile Script – the script stays in a monospaced font but the "Successfully compiled." message persists. Add a single return after "tell" and you get a correct error message. It's very easy to find any number of script expressions that don't compile but don't explain why not.

It looks like the reason for this is that Apple is giving us back different error status information depending on whether we compile the script for use in an external process (via /usr/bin/osacompile) or to run in the QLab process (via an NSAppleScript object). 

It's not clear to me if we should try to override that behavior and use, for example, the NSAppleScript errors to try to catch things that osacompile misses, or if it's icky and misleading to show error reports from something that isn't going to actually run the script.

[Rich Walsh]

What would happen if you used NSAppleScript to compile the scripts for the user interface and then called osacompile to prepare them for a separate thread once they've been shown to compile OK? Is there a case where osacompile can compile but NSAppleScript can't? It seems more like osacompile is (even!) less helpful than NSAppleScript for letting the user know that something hasn't worked and why.

The current implementation can give you false positives; aren't false negatives a better compromise? What's going to be most like testing in AppleScript Editor?

Some very funny things are going on: try typing "getLevel" – it compiles in blue then throws an error about an undefined variable (green) when you run it… So the compiler is using terms from QLab, but the runner isn't? Does the compiled script need to be surrounded by a "using terms from" block?

Is it necessary that errors decompile the script? This isn't what AppleScript Editor does.

I think I'd be inclined to use this form when developing scripts to be run in a separate process:

try

-- Script contents

on error theError

tell application id "com.figure53.qlab.3" to display dialog theError

end try

Rich