I have a very very very long script and I already split it up in about 5 separate parts, 1 part to talk to InDesign, another part to talk to a WebService and another one is doing the styling of a table in InDesign, and some more…
I’m loading the different parts with the use command in a main script.
so in my main script I can say tell StyleTableLibrary to doSomething()
in the StyleTableLibrary I have a property with the InDesignLibrary
so in the StyleTableLibrary handler doSomething() you can call a handler in the InDesignLibrary
Now I want to debug a handler in the StyleTableLibrary script.
So I thought to place the complete StyleTableLibrary in the main script but then ScriptDebugger hangs probably because the complete scripts becomes too long.
Is there any way to debug the StyleTableLibrary without the need to import that script in the main script?
Can somebody guide me in a correct direction?
Maybe. You can use cross-document scripting. This is where you open the StyleTableLibrary script, enable debugging, and then create a second test-harness document which invokes handlers within StyleTableLibrary:
tell document "StyleTableLibrary"
With this approach, you can debug handlers within your library in place.
Now, there are limitations to this imposed by the AppleEvent transport and AppleScript. For instance, you cannot pass object specifiers (references) to handlers. Script objects should not be sent in this way either. But if you handler parameters are scalers, lists or records it should work.
But what about inheritance? How does the Parent script menu item under the Script menu? What does this do and how to use it then?
That feature does not help us with debugging libraries. It defines a parent-child relationship which can be used for AppleScript inheritance, but in order to debug within Script Debugger, we cannot allow AppleScript to dispatch handler calls for us. We must invoke handlers explicitly within the context of the script library which is what the cross-document scripting trick accomplishes.
If you have inheritance within your script library, that is fine. However, if there is inheritance across script libraries then we are blocked.
but my library is in fact a script that is loaded
I don’t understand.
Presumably, your library has an API (a set of handlers that can be invoked). If your library is designed to be used via inheritance, then perhaps you can define a procedural API within your library that the test harness can call into.
It’s rather difficult to explain it… I’ve created a very samll setup as an example…
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
use LIB_gentool : script "testObjC.scptd" without importing
(* -- part saved as testObjC.scpt
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
set the sourceString to current application's NSString's stringWithString:sourceText
set the adjustedString to sourceString's uppercaseString()
return adjustedString as string
-- property type : "grandma"
property sGenTools : null
set mGreeting to "Grandma's greeting…"
tell sGenTools to set mGreeting to makeCaseUpper(mGreeting)
onShow(mGreeting as Unicode text)
display dialog mTxt
property parent : grandma
property pName : "Mommy"
onShow("How do you do? " & pName)
property parent : mommy
set mName to mommy's pName
tell mommy's sGenTools to set mName to makeCaseUpper(mName)
copy LIB_gentool to grandma's sGenTools
baby's talk() -- How do you do?
And then place the script grandma, mommy and baby all in separate script files that are loaded into the main script. And when I want to debug I place only that specific handler of that specific script in my main script
I cannot provide a solution for the need to copy
testObjC.scptd into variables, etc. However, if all you want to do is debug code with testObjC.scptd then you can do something such as this (opening LIB_gentool first in another Script Debugger window/tab):
tell document "testObjC.scptd"
makeCaseUpper("this is a Test") --> "THIS IS A TEST"
I was just trying to show you what the idea was.
The issue is that the scripts are long: about 1000 to 1500 lines and when I place the script inside one of the other scripts to debug SD becomes unresponsible for several minutes before showing a result or no longer responds at all. So I was looking for something easier to debug and teh idea was then to place the handler with the error in the main script with as parent that script where the handler normally resides.
I will further try to track down my issue by adding logging teh old fashioned way then
Would it be a good idea to call in Shane Stanley on this one? Does he read this thread?
I don’t have anything useful to add. Anything more than about 600-650 lines starts to ring alarm bells for me. I also tend to avoid inheritance if practical, precisely because it can be difficult to debug.
There’s a distance between what AppleScript is capable of doing and what it’s wise to ask it to do, IMO.
OK Shane, you do read every thread
When you say ‘ring alarm bells’ what do you want to say? Ugly scripting ( it’s the start of a rework of a script I made back in 2007) or way too large and you should split it up in different parts and then were back at the start.
As already said I will use the old logging solution to find the line were the errors occur and then try to do everything better in a refactered solution.
Thnx for the ideas.
I mean you’re risking problems. To be sure, I’ve seen much bigger scripts behave perfectly — but it’s a rule of thumb I’ve come to follow.
Can you then give some good advice in how to structure such a larger project in AppleScript and especially Mark’s wonderful SD app?
Any tips will be greatly appreciated
I can only tell you what I do: unless it’s impossible, I keep libraries and any loaded scripts self-contained. Once that starts to get difficult, I then generally move to hybrid Objective-C/AppleScript apps.
Good afternoon, maybe morning for you Mark,
I want to followup on this request.
What could make the debugging of a script with about 800 lines, white lines included…
whitelines excl 640 lines, of code slow?
I’m using SD 6.0.5 on a macbookpro 2,3 GHz Intel Core i7 - 16 GB 1600 MHz DDR3.
Should I avoid any special things?
Looking at the crash report you submitted yesterday, Script Debugger is failing to handle code folding in your script. Something in the text of your script is causing Script Debugger to recur infinitely. If you would like to send me the text of your script, I’ll look into the problem and develop a fix.