First I’ll say that I’ve searched high and low and I do have universal access on and GUI scripting enabled.
I downloaded someone else’s script to run, I did not open it in xcode or have xcode open at the time. I was warned that this code would display some errors as it was a beta and kind of rough around the edges. One of the errors it showed was the one above. After running this script I closed it.
Later I went to run some of my own scripts (without this script running or even present) and I get this error. I have never received this error before with my own scripts.
After talking with the developer of the first script we believe the original error stems from his script trying to access an element in the pref panes that does not exist (screen diming I think). However, we are at a loss for figuring out how this could have screwed up the running of other scripts.
On a whim I tried changing the NSAppleScriptEnabled property in the info.plist file of my scripts to no temporarily and then back to yes. This seemed to solve the problem, but only temporarily. After a few more runs of the script the error was back.
Any ideas would be greatly appreciated.
Model: macmini
AppleScript: latest
Browser: Firefox 1.5
Operating System: Mac OS X (10.4)
The error you’re seeing is a generic scripting error that essentially says, “The object you’re referencing does not appear to exist.” The error in itself tells us nothing, other than that you’re trying to do something with something that the something (or possibly something else) has some problem with. There is no way we can tell you what the problem is unless you post the code.
Because of the nature of this problem, it is unlikely that the error in your problematic script has messed things up for all of applescript. I’d think it more likely that you have either consiously (or unknowingly) edited a setting or configuration in your system or AS preferences that may be causing an error, or you are trying to execute some code common to all problematic scripts that triggers the same error.
You say that you toggle the “NSAppleScriptEnabled” property of your script, but only an app bundle has an info.plist file. Regardless, this has little bearing on the functionality of your app in regards to this error. This flag is only used for applications that register to be controlled by other scripts outside of your application to add applescriptability to your app. Enabling or disabling is probably not the direct cause of this problem.
Here are my recomendations…
Check your variable names. Check for typos and that you haven’t confused one object for another. This is most often the reason for this error. Your script may incorrectly identify the objects by name, or you may be referncing the title of the object rather than the actual AS name. This is particularly important when referencing items in third-party apps (like when gui-scripting), as the names and titles may or may not be the same. They are often NOT interchangable.
Make sure that any changes you’ve made to your system settings for the purposes of creating your app are reset to their original values. If your app makes changes to the system settings, it is unlikely that you’ve changed anything that could effect applescript in a global sense… other than enabling GUIscripting, as you’ve mentioned.
Make sure that any changes you’ve made to applescript and script editor are reset. If you’re messing with TIDelimiters make sure to change 'em back to {“”}.
Clean & Rebuild your project. Cleaning the active target resets all of the headers, clears any cached representations of your nib and data, and recreates the final product from scratch. This is also OFTEN the cause of problems of runtime errors for newer Xcode users, especially errors that relate to the interface.
Troubleshoot the code. You probably have an idea of what part of the code is the problem already. Try commenting out that entire part and then uncommenting it on a line-by-line basis. You may need to create some temporary code that sets values manually to keep your process flow continuous. Repeat line-by-line, or section-by-section, until you narrow it down to one specific line.
POST THE CODE. People often have the misconception that error messages secretly contain error logs or encoded details. They don’t. The error is only useful for use as a starting point, but normal backtracking and troubleshooting is still required regardless of the error… especially when it’s something as ambiguous as the error you’re getting. For all we know your code has 500 lines of code that all execute in one block and makes reference to dozens or hundreds of different objects. There’s just no way we can tell you anything concrete without seeing the code that instigates the error.