Starting an Applescript app from the script menu?

Scripting Forums AppleScript Studio & Xcode
#1

Hi,

I’m new to this, so I’m sorry if this a really basic question, but I can’t seem to get a grasp of how Applescript applications relate to Applescripts that one can launch from attachable applications’ script menu.

Namely, my question is, how can I stick an Applescript application created with AppleScript Studio and with a custom interface (i.e. one created with Interface Builder) into the “scripts” folder of an attachable application, and expect to be able to launch that Applescript application from the scripts menu in that attachable application and view my custom interface?

Basically, this just comes down to that I want to be able to make scripts that have a nice interface that I create with Interface Builder, but are still basic enough and dependent enough on an attachable application that I want to launch the script from the said attachable application’s script menu.

I have figured out how to create an app in AppleScript Studio that uses an interface created in Interface Builder, and it works when run on its own (i.e. double-clicking the resulting app’s icon), however when stuck in an attachable application’s script menu (in this case iTunes), no interface pops up.

Is this making sense…?

It seems very basic, but I can’t seem to find reference to it anywhere… :oops:

Thanks for any help with this,

#2

Perhaps you can use a compiled script to launch your studio app… (not very smart, but may do the job)

#3

After some thought, I’m not sure there is really any other way. It seems like an attachable app only accepts basic scripts. Not apps made from scripts. Or even script bundles.

Even so, it is interesting to note that a studio app includes a compiled AppleScript in its contents. Furthermore, an attachable app (or at least, iTunes) will dig down and display this AppleScript in its script menu. When I run this script from the script menu, as one would expect, the script’s run procedure (on run … end run) is executed. However, if I run the application from the Finder (i.e. as a normal application), the run procedure is not executed (or so it seems… at least nothing that is in the run procedure occurs when executed from the Finder). Can I use this effect to cause the studio app’s embedded compiled script to launch the studio application itself when executed from iTunes?

I’ve tried just a basic call with “run” or “launch” from within the run procedure, but it doesn’t seem to work when specifying my application. However, it works when specifying other applications (e.g. ‘launch “Calculator”’ will start up Calculator as expected). Any ideas as to why?

#4

You’re probably right. The “scripts” menu for an app is just that, a place for scripts to reside. Otherwise, it would probably be considered a plugin. But, because of itunes’ ability to read into the app and see the script, this might actually be a nice method for you to activate your app.

Of course. That’s what applescript studio is all about. You build an interface in IB, and then add functionality to it in a script.

I created a small app, named ‘myTunesApp’ and in it I put the following code…

(* When the user closes the last window, presumably the main window, the app quits itself *)
on should quit after last window closed theObject
	return true
end should quit after last window closed

(* Make sure the window is always opened when we activate it from the itunes script menu *)
on activated theObject
	show window "myTunesApp"
end activated

(* This get's run only from the script menu in itunes *)
(* Don't put anything crazy or complex in here to avoid compilation conflicts *)
on run
	try
		set myTunesApp to (((path to library folder from user domain) & "iTunes:Scripts:myTunesApp.app") as string)
		tell application myTunesApp to activate
	on error
		display dialog "Error activating "myTunesApp"!" buttons {"OK"} with icon 2
	end try
end run

As you found, the run handler is the only bit executed by itunes, while the app ignores the run handler and only uses the rest of the code. You typically want to “activate” your app, not “launch” it when you’re trying to get it to perform actions like this. ‘Launch’ has different meanings for scripts and asstudio apps. When you launch an app via a script, you’re actually telling it to try to start up WITHOUT running any of it’s activation code. Launch, to an app, is what happens only once when the app first starts up. By activating it, you tell it to run any code in it’s activate handler (assuming it’s not already active, otherwise nothing happens).

If you decide not go go with this approach, simply put your app someplace, like the “Applications” folder, and then call it like you would any other app and tell it to activate. Place a script with the following code into your scripts folder and you should be good to go. FYI, in a simple script, the run handler is implied…

set myTunesApp to "myTunesApp" --> Keep the app from activating when compiling the script
tell application myTunesApp to activate

Good luck…
j

#5

I tried using your example of the script running the application it is embedded in, and it works just fine. Cool! Thanks much, :slight_smile:

By throwing in a “LSUIElement” value of “1” into the app’s info.plist, I also got it to not pop up a new menu or an icon in the dock, thus furthering the illusion that the app’s windows are apart of iTunes. However, that makes it a little easier to lose the window if one starts shuffling windows around (since, of course, it really isn’t an iTunes window)… though it can easily be made to pop up again if one runs the script again from the scripts menu.

I’m curious, if the application window is set as “Visible at launch time” from Interface Builder, it the following code needed?

(* Make sure the window is always opened when we activate it from the itunes script menu *) 
on activated theObject 
   show window "myTunesApp" 
end activated

The window seems to pop up alright when I have that IB setting set, even if I don’t use the above code.

Anyway, this seems a kinda neat way to get custom interfaces in a script, without needing to write a full blown plugin. Do you happen to know if iTunes’ treatment of its scripts folder in this way is fairly consistent with other attachable apps?

Also, offhand, I don’t suppose you know of a resource for writing iTunes plugins? The only thing I could find was an SDK for writing an iTunes visual plugin… but nothing else. That question is rather off-topic I know, so feel free to ignore it.

Thanks again for the help!

#6

It depends on whether then window can be closed or not. If your window has no close button, you can discard that code. If it’s possible to close the window without quitting the app, then you’ll want it.

Another thing I did in my test app, which may work for you, is to add a ‘resigned active’ handler to your file’s owner. In the handler, just add “quit” as the only code. Then, when the app is running and the user clicks out of the window, the app will simply quit. This way you won’t have to deal with the window being lost behind other windows, it will simply close and the app will quit.

And sorry, I don’t know anything about itunes plugins.
j

#7

In IB, you can make your window a panel and then set it to be a utility panel. This will automatically enable “Hide on deactivate” that can’t be turned off, at least not in IB–and we don’t want it. If you attach an “awake from nib” handler to this window, however, (which you should just so you can populate any saved preferences anyway) you can disable the hide on activate with a simple “tell the_object to set hides when deactivated to false” in the “awake from nib” routine. Finally, you can add an idle handler and some properties like so:

This should keep your panel floating over iTunes and only iTunes.

Jon

[This script was automatically tagged for color coded syntax by Convert Script to Markup Code]