Scripting additions being used from libraries

[McUsrII]

If I use ScriptingAdditions in a library, and in the calling script, then the path command will fail in the calling script.

Here is the example: the calling script

use AppleScript version "2.3"
use scripting additions
use aeq : script "ase_editor_qual"

set edname to aeq's qualifyASE()


tell application id edname -- "com.latenightsw.ScriptDebugger"
	set tp to path of document 2
end tell

Here is the library:

use AppleScript version "2.3"
use scripting additions
property ed_names : {"AppleScript Editor", "Script Debugger"}
property ed_ides : {"com.apple.ScriptEditor2", "com.latenightsw.ScriptDebugger"}

on qualifyASE()
	
	local editorProbe, found
	set {editorProbe, found} to ¬
		{name of ¬
			application (path to frontmost application as text), ¬
			false}
	repeat with i from 1 to count ed_names
		if editorProbe begins with item i of ed_names then
			set {editorProbe, found} to {item i of ed_ides, true}
			exit repeat
		end if
	end repeat
	if found then
		return editorProbe as string
	else
		return missing value
	end if
end qualifyASE

When the code is put in the correct place, and called (the library) then the the path in the calling script will generate a run time error. (Both from within AppleScript Editor, and Script Debugger 4.5).

Now, if you remove the call to scripting additions in the calling script, then it will work. I think loading scripting additions twice generates some kind of conflict. It is an easy workaround, but slightly awkward.

I wonder if there is a better workaround.

[McUsrII]

Hello.

Reworking this a little, as it is awkward not to use scripting additions from the calling script, I worked around it by removing scripting additions in the library script, and replacing path to frontmost application as text with name of current application. (Which is not a part of scripting additons.)

I am not sure if this will be that easy in every circumstance, but it is a way to live with it at least.

[McUsrII]

Hello.

It still broke, even when every scripting addition use clauses were removed from libraries, I need to have scripting additions in the main script, because I need the handlers that are incorporated in them.

This turned out to fix my problem (the using terms from). I don’t understand the problem, but it looks to me like the path to from within an application tell block, which isn’t a real application tell block, seems to be "shadowed/overridden in this case. Due to Scripting additions.

use AppleScript version "2.3"
use scripting additions
use aeq : script "ase_editor_qual"

set edname to aeq's qualifyASE()
using terms from application "AppleScript Editor"
	tell application id edname
		set mpath to path of document 2
	end tell
end using terms from

[kel1]

Hi McUsr,

I’m not sure what you’re writing about, but what if you place pipes around |path| or something else.

gl,
kel

[McUsrII]

Thanks kel.

Pipes didn’t make the issue go away. At least not how I tried to use it. So I am stuck with a using terminology block for now.

Edit

What I was writing about, was the path of document 1, from each of the editors I currently use for writing AppleScript, Applescript Editor, and Script Debugger, throwing an error, when I use scripting additions in the script.

I have a library to determine which editor, and return the bundle identifier, (for Script Debugger), the reason for doing it this way, is so that the script continues to work with different versions of Script Debugger.

I still don’t fully understand why it doesn’t work correctly when I use the application id, but using terms from AppleScript Editor will always work, since AppleScript Editor is always there.

The whole thing, is to establish “script editor agnosticity”, so that I can “write once, run everywhere”!

[Shane_Stanley]

@McUsrII

I don’t understand the problem, but it looks to me like the path to from within an application tell block, which isn’t a real application tell block, seems to be "shadowed/overridden in this case. Due to Scripting additions.

You’re misunderstanding how scripts work with the use command; it has nothing to do with libraries, and it’s only indirectly related to scripting additions.

You need to be explicit on where terminology comes from, with either a use statement, a real tell block, or a using terms from block.

[McUsrII]

@Shane Stanley

@McUsrII

I don’t understand the problem, but it looks to me like the path to from within an application tell block, which isn’t a real application tell block, seems to be "shadowed/overridden in this case. Due to Scripting additions.

You’re misunderstanding how scripts work with the use command; it has nothing to do with libraries, and it’s only indirectly related to scripting additions.

You need to be explicit on where terminology comes from, with either a use statement, a real tell block, or a using terms from block.

I noticed that I had to be exlipict, and that no terminology is loaded, or seemed to be loaded with an tell application id statement.

[Shane_Stanley]

@McUsrII

no terminology is loaded, or seemed to be loaded with an tell application id statement.

With a proper one, or with one where you used a variable for the id?

[McUsrII]

@Shane Stanley

@McUsrII

no terminology is loaded, or seemed to be loaded with an tell application id statement.

With a proper one, or with one where you used a variable for the id?

It wasn’t “proper” in the sense that it was a literal, it was in a variable - of type string. Now, creator type seems to work fairly well, and there isn’t a word about deprecated in the dictionary of System Events.

[Shane_Stanley]

@McUsrII

It wasn’t “proper” in the sense that it was a literal, it was in a variable

You can’t do that. Terminology needs to be loaded at compile time, to enable compiling – that’s the whole point. But variables aren’t resolved until run time – at compile time they are meaningless, so you can’t use them in tell statements.

You used to be able to get away with it in some cases by relying on the fact that the search for terminology silently dropped back to scripting addition terminology, but you cannot any more. Now, if it drops back to the scripting addition terminology, it uses the scripting addition command.

[McUsrII]

@Shane Stanley

@McUsrII

It wasn’t “proper” in the sense that it was a literal, it was in a variable

You can’t do that. Terminology needs to be loaded at compile time, to enable compiling – that’s the whole point. But variables aren’t resolved until run time – at compile time they are meaningless, so you can’t use them in tell statements.

You used to be able to get away with it in some cases by relying on the fact that the search for terminology silently dropped back to scripting addition terminology, but you cannot any more. Now, if it drops back to the scripting addition terminology, it uses the scripting addition command.

I like it when I get away with stuff.

Well I guess I’ll end up with a whole lot of terminology blocks then, but the fact is, that with creator types. I actually found that I hade to use creator type, inside a using terms from block, but I may have fumbled, though I think I didn’t.

[DJ_Bazzie_Wazzie]

@Shane Stanley

You used to be able to get away with it in some cases by relying on the fact that the search for terminology silently dropped back to scripting addition terminology, but you cannot any more. Now, if it drops back to the scripting addition terminology, it uses the scripting addition command.

Now you can use:

using terms from  scripting additions
   --insert codehere
end using terms from

[Shane_Stanley]

@DJ Bazzie Wazzie

Now you can use:

using terms from  scripting additions
   --insert codehere
end using terms from

Right. The important change is that before this, if you used a term defined by both an app and a scripting addition in a tell block, the app’s definition would be used. With use statements, you get a message telling you it the term ambiguous, and you have to disambiguate it before it will successfully compile (perhaps with “using terms from”).

[Shane_Stanley]

@McUsrII

I like it when I get away with stuff.

That’s fine. But when it stops working, like here, you can’t just say “the path command will fail”. It’s the hack that’s failing.

[DJ_Bazzie_Wazzie]

@Shane Stanley

@DJ Bazzie Wazzie

Now you can use:

using terms from  scripting additions
   --insert codehere
end using terms from

Right. The important change is that before this, if you used a term defined by both an app and a scripting addition in a tell block, the app’s definition would be used. With use statements, you get a message telling you it the term ambiguous, and you have to disambiguate it before it will successfully compile (perhaps with “using terms from”).

Another great side effect of that ambiguous term is that for (most) scripting addition commands you no longer needed to run outside an tell application block. Commands from scripting addition doesn’t need to be used in current application block only if your using ‘use scripting additions’ because all the scripting addition commands will be automatically compiled to run in the current application context later.

[McUsrII]

Hello.

Yes, I noticed that when I was informed about what happened, because I was earlier living in blissfull ignorance, that it was forgiveness of Applescript that made the code work. -But, I did find a work around that proved to be the correct one.

@DJ Bazzie Wazzie.
The moment I look at the document from where I have my understanding from, I’ll drop you a link, right in this thread. And they actually may have changed it of course, but at least how I described was how it used to work.

As for creator type, yes, they are old, but today, using a creator type proved to work better for me than a bundle identifier. Some of the trouble may of course have originated in that I scripted Script Editors, from within Script Editors. I don’t exclude that possibility at least.