• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: How to reliably target a helper app that's inside a bundle?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to reliably target a helper app that's inside a bundle?


  • Subject: Re: How to reliably target a helper app that's inside a bundle?
  • From: Nathan Vander Wilt <email@hidden>
  • Date: Mon, 19 Oct 2009 17:32:10 -0700

(sorry for the initial private response...I'll never learn...)
On Oct 19, 2009, at 3:18 PM, Stockly, Ed wrote:
My main application bundles an AppleScript script and scriptable helper
application.

My worry with doing this is that this still won't help osacompile find
>"HelperApp" during script compilation. How can I be sure that my script will
>always compile to the most current HelperApp's scripting definition? Is there
>a better way to approach this?


This is quite possibly a non-issue. The script does not need to compile at
runtime and as long as the script can find the helperApp you should be fine
with "using terms." ("Using terms" helps compile during script editing)
Unless you see a scenario where you would release an update to the helperApp
without updating the bundled script at the same time, you should be fine.


Even if the helperApp were updated; and its scripting definition changed;
and the script not updated, there still wouldn't be a 'runtime compile
error' but there could be a 'runtime execution error'.

So, if I make sure my "tell" application path is correct, there should be no risk to hard coding just the helper app name in "using terms from", so long as I compile it successfully my own machine with 'osacompile -x'?



I could get the path of my HelperApp by either passing it as an argument to
>the script, or using "path to me". (Is the latter reliable? I know in many
>contexts relying on the executable path is strongly discouraged.)


"Path to me" is probably the most reliable way to get the path to your
helper app at runtime.

My main app can easily use -[NSBundle pathForResource...] to find the helper app. From Luther's example (thanks!) it looks like it will be cleaner just to pass the helper app's path into my script instead of messing with Finder containers. But it's good to know that this is considered a safe thing to do.



global theHelperApp

It may not be a good idea to use globals in this kind of script. Once the
script has finished it will try to store the value of the global and if it's
distributed on a read-only medium you may give your users unwanted error
messages. Might be better to pass the value in a local.

Ah yes, it will be good to avoid the script modifying itself. I see script properties also have somewhat similar behaviour. In this case, passing it as a parameter is not burdensome.


thanks much,
-natevw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden
References: 
 >Re: How to reliably target a helper app that's inside a bundle? (From: "Stockly, Ed" <email@hidden>)

  • Prev by Date: Re: How to reliably target a helper app that's inside a bundle?
  • Next by Date: Re: How to reliably target a helper app that's inside a bundle?
  • Previous by thread: Re: How to reliably target a helper app that's inside a bundle?
  • Next by thread: Re: How to reliably target a helper app that's inside a bundle?
  • Index(es):
    • Date
    • Thread