I’m new here on the forum, but I couldn’t find the answer until so far. So if I missed something, please say so
I’m working on a Script Library to connect to our Postgresql database (I plan to make it available on github, when it’s ready). But I can’t seem to debug the library.
I’ve tried from a script that’s using the Script Library to specify the library (which I already loaded in the Scripting Debugger editor) as Parent (via menu: Script > Parent Script), but the debugger didn’t stop at the breakpoint.
Unfortunately, Script Debugger cannot debug across source files. In order to debug your library, you’ll have to create tests for your handlers within the library its self.
You can invoke handlers within your library from another script via Script Debugger’s scripting interface. For example, lets imagine you have a library called “MyLib” containing code like this:
on testing(theName)
return "Hello " & theName
end
You can then enable debugging and set a breakpoint on the return "Hello " & theName statement.
Next, from another document, you can invoke the testing handler like this:
tell document "MyLib"
testing("Mark")
end
I recognize this is a less than perfect situation, but these limitations are the results of technical constraints placed on us by the AppleScript runtime environment.
Many more than you might imagine. In fact, many users don’t understand the meaning of extensions (for instance they consider .applescript and .scpt to be equivalent).
That’s interesting. .applescript files always have to be compiled when opened and .scpt file don’t have to be compiled, the two files are different sizes even with the same AppleScript code. If you don’t use ScriptDebugger the script editor often launches applications opening .scpt files while .applescript never do that. I would think the way they behave differently would suggest they are not the same even if someone didn’t understand what the difference was.
But what about Script Debugger users? Don’t you think, expect, that most of them are more sophisticated, file aware, than the average Mac user?
Maybe I’m wrong, I don’t have any hard data, but my guess is that most Script Debugger users are very aware of file extensions, and would never hide them. SD itself is designed to handle multiple extensions.
I guess my real point is that if you are going to provide an example of how to debug script libraries, that it would be best to state any assumptions that you are making, like you did in the above example. Debugging script libraries is already a challenge, as you noted, without having to deal with unknown issues like file extensions.
Maybe someone should write a blog about best practices for debugging script libraries.
You say that as if the the two things are mutually exclusive, but I don’t think that’s the case.
IAC, here’s a simple solution:
tell application id "com.latenightsw.ScriptDebugger6" -- Script Debugger.app
set theName to (choose from list (get name of documents) with prompt "Choose an open library to target")
if class of theName is list then set contents of selection of document 1 to "tell document \"" & item 1 of theName & "\""
end tell
By and large, you are correct, Script Debugger users are more aware of these issues. However, I have dealt with users who strongly believe that they can change file extensions at will and Script Debugger should just work even when the file extension lies. This is why you can save a .scpt file, change it’s extension to .applescript in the Finder, and Script Debugger will open the file correctly. Script Debugger mostly ignores the extension and sniffs the contents of the file to figure out what it’s dealing with.
As I said above, file extensions are lost on many people. In many ways it was simpler in the old days of file type and creator codes because there the UI for changing them was obscure and more restrictive.
I did say it was a guess. But it is irrelevant to my point about assumptions.
A solution? Perhaps. Simple? Not so much.
Simple would be SD6 providing a document picker like it does an app picker, when I type:
tell document ""
Hey guys, my only real point is to state your assumptions. Is that so terrible?
It seems like I’m getting a lot of pushback against something that I am trying to help SD be presented in a better light. If you don’t agree with my suggestion, then fine.
But you should know that I wasted a lot of time trying to follow Mark’s example of debugging a script library. Do you really want SD users to experience the same frustration?
And, instead of saying, “OK, we’ll add the need to include extensions…”, you are giving me these rebuttals, wasting even more of my time. If you don’t understand the point by now, then I"ll not reply further.
I’m positive this is demonstrated in one of the tutorial videos, (something about “it allows you to basically do unit testing”), but having just scrubbed through them I can’t seem to find which one.
If you can find it, perhaps it’d be worth linking to in this thread.
No, but I think you’re missing something. When you turn on Show all filename extensions in the Finder, it actually affects more than the Finder. It affects the file names that appear in the title bar of documents, and it also therefore affects what AppleScript regards as the name of a document.
So the correct answer is to use the name of the document, just as it is when scripting any application. If the window displays an extension, you include it, otherwise you don’t.
There’s nothing unique to Script Debugger about this; it’s the same for all applications. Try turning off extension display and address a document with a hidden extension in any app, and you will see it fail if you include the extension, and vice-versa.
The confusion probably stems from the fact that the rules for script libraries and applications are different. But in this case it’s standard AppleScript document scripting, and therefore the standard rules apply.
Unfortunately AppleScript hasn’t helped matters by telling you that the document doesn’t understand the “testing” message, when the real error is that you have addressed a document that doesn’t exist. You should log a bug with Apple about that.
So yes, there’s an assumption that the user understands how AppleScript treats document names, and if you’ve always had extensions showing and never shared scripts with users who don’t, you may never have come across this point.
No worries about the restrictions. I’m very glad there is a way to debug! Your suggestion worked, except I also need to include the extention of the file. So this is what worked:
tell document "My Library.scptd"
set padded_name to lpad("Doekman", 10, "_")
end tell
I am interested in unit testing, so if there is anything in a video (or something else) about that please let me know.
I actually have obtained from its author an AppleScript framework called ASUnit that I’ve been working to modify and further document. I keep putting off posting it, because I was trying to get past one limitation I encountered, and I have put my time into other things lately, but this might be a good time for me to finish up.
