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?
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"
handlerName(1,2,3)
end tell
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.
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.
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.
Hey Mark,
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"
on makeCaseUpper(sourceText)
set the sourceString to current application's NSString's stringWithString:sourceText
set the adjustedString to sourceString's uppercaseString()
return adjustedString as string
end makeCaseUpper
*)
script grandma
-- property type : "grandma"
property sGenTools : null
on sayHello()
set mGreeting to "Grandma's greeting…"
tell sGenTools to set mGreeting to makeCaseUpper(mGreeting)
onShow(mGreeting as Unicode text)
end sayHello
on onShow(mTxt)
display dialog mTxt
end onShow
end script
script mommy
property parent : grandma
property pName : "Mommy"
on talk()
onShow("How do you do? " & pName)
end talk
end script
script baby
property parent : mommy
on sayHello()
set mName to mommy's pName
tell mommy's sGenTools to set mName to makeCaseUpper(mName)
onShow(mName)
end sayHello
end script
copy LIB_gentool to grandma's sGenTools
grandma's sayHello()
baby's talk() -- How do you do?
baby's sayHello()
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"
end tell
Thnx Marc,
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.
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.
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.
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.
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…