In my applet, I have been avoiding the errOSAlnternalTableOverflow error by storing handlers in a few script libraries which are loaded at the start of main.scpt. To load the libraries I have:
set run_Utilities_handlers to load script path_to_Utilities
I can then call an individual handler (eg. “return_name”) with:
set the_name to run_Utilities_handlers's return_name()
I’m now getting the overflow error when running the applet in Script Debugger and can’t sensibly move more handlers into separate libraries. Would changing from load script to use script help ?
I’ve had that before with script debugger. Think it was some weird character that got typed in.
Create a new new script.
Copy and paste into empty script ,
Use one of the paste methods. Can’t remember but think one was paste with formatting or paste as raw text or something like that.
Often I’ve just declared a global property with
use myScriptLib : script “myLibName”
What version of OSX are you using?
There been. Lot of lock downs on access to the main Library Folder, where most libraries live
Many thanks. As it is an applet, I had to recreate the whole bundle: copied across all the resources; updated Bundle & Export settings etc. SD now runs the applet without that overflow error – it must have corrupted something. Marl Alldritt does warn about that.
By the way, is there any difference between the “use” and “load” methods of accessing a script library ? I use this in my applet:
set path_to_Utilities to (path_to_applet & "Contents:Resources:Scripts:Utilities.scpt") as alias
set run_Utilities_handlers to load script path_to_Utilities
Then to use a utility handler, I do this:
set screen_size to run_Utilities_handlers's get_screensize()
It does function but, I worry that it doesn’t prevent overflow errors. Maybe I should change to
use myUtilities : script "Utilities"
I can’r find any advice on whether that change would achieve anything.
‘load script’ loads a COPY of the script into the current script while ‘use script’ returns a reference to the script.
Script Debugger will display the results of ‘load script’ as a ( <<script>> ) source code which can be expanded and explored revealing properties while the results of ‘use script’ will be a ref ( script “script name” ) and the source/properties of this script are NOT viewable.
In Script Debugger, if a script loaded by ‘use script’ is modified by it’s loading script then that modification remains until the loading script is recompiled.
In Script Debugger, if a script loaded by ‘load script’ is modified by it’s loading script then that modification is reset on every run.
Libraries loading libraries:
A script loaded into script A by ‘load script’ and assigned to a variable IS NOT available to a script loading script A as a library. Regardless of how script A is loaded.
A's handlerName --> Can’t get handlerName.
.
A script loaded into script A by ‘use script’ and assigned to a variable IS available to a script loading script A as a library. Regardless of how script A is loaded.
A's handlerName --> script "handlerName".
.
I’m currently loading 596 handlers weighing 3MB from 17 libraries into a single hosting library using ‘use script’. This does not cause any errOSAInternalTableOverflow errors. While loading just two ( largest ) of these libraries into properties in a script will cause errOSAInternalTableOverflow errors.
Load up all the libs you have using load script and see if that blows up or not. If it does, I can vouch for ‘use script’ as a solution. I don’t see issues 'load script’ing all 17 libs here.
Unless you are storing libraries into properties you should have no issues loading libraries using the ‘use script’ construct. Assigning ‘use script’ loaded libraries to a variable does not embed the loaded code. The following line looks like a property assignment but it isn’t.
use lib: script SCRIPTNAME-->script SCRIPTNAME is NOT stored in the saved script
--while
property lib: script SCRIPTNAME-->script SCRIPTNAME IS stored in the saved script
--
.
Assigning the library to a property allows the script ( until edited ) to run in environments that do not contain the library. Assigning just a handler from a used or loaded lib into a property does not provide this embedding since there is no source for the handler’s inheritance. But assigning 596 handlers to properties WILL cause my host library to error.
.
IMO This is the proper way to dereference handlers so that you can directly address them without referring to their library. When constructing these references to handlers from a loaded library there’s no need to provide any argument…
set screen_size to run_Utilities_handlers's get_screensize