GUI (Not Responding)


I’ve noticed that my ASStudio apps usually go into an unresponsive state while working. Very inconvenient during long tasks like erasing a disc or converting iTunes tracks. It there anyway around this?

Basically when my app is doing work like a “do shell script” or converting tracks in iTunes, my app won’t become active and won’t respond to clicks. I can however move my windows around. Is this a shortcoming of an AS app or am I forgetting a step?


This is normal behavior for a task-based application, and is not something that should be “worked around”. Im most cases, the user should click the ‘Go’ button, wait for it to do it’s thing, and then recieve confirmation that it is done. This is especially the case in an applescript studio project. ASStudio apps have no easy mechanism for multi-threading, so all of your computing goes into one main thread. Applescript studio apps work linearly… i.e top to bottom. If you put something in the middle that takes a while, there’s often no good way to get around waiting for the action to stop before you continue.

Of course, there are always exceptions to any rule, but that all depends on what exactly your app is doing. While it seems that your app is doing it by default, I would actually take it a step further, and recommend that you disable your ui (at least the button that starts the process) while a task is running. If for some reason the user becomes able to click the button again (perhaps driven by confusion or frustration that they have to wait) you certainly don’t want them to start ANOTHER run of the code. Perhaps it would be best to start a progress indicator spinning and splash up a little message saying “please wait” to remind you and all your buddies to kick back and wait 'til it’s finished.

I’d take this default behavior as a sign that you don’t want to push your luck. As long as the execution of the code happens and ends correctly, I wouldn’t mess with it. Just be patient, and maybe provide a mechanism for your other users to know that they should do the same.


As a follow-on to the previous question, is it possible to use an XCode application to activate an external applescript to do the required task (e.g. convert track in iTunes), and still allow the user to interact with the primary XCode application? (I’m on a PC at the moment, so can’t check it out, but could this be a useful solution?)
Yours enquiringly,

When I said “there are always exceptions to any rule, but that all depends on what exactly your app is doing” I was getting at this concept. If you wanted to, you could “multi-thread” your applescript studio app by:

  • Send your actions to other applications (such as itunes) and let them handle your tasks on their thread
  • Write other ASS apps that handle specific tasks and run them as your secondary “threads”
  • Write secondary applescripts that you can execute

When you do stuff like this, you create another new set of problems to consider. Controlling other apps can sometimes be a complex, or at least painful. You also don’t always have a good way to test an external app’s state. If an app is already performing an action, you don’t want to send it more actions as it may not handle them in the way you’d hope. Same with scripts. Once the script is running, it will need to do it’s thing before you can tell it to run again.

I have written a few ASS applications that each had their own custom “mutithreading” or queueing mechanism. It gets pretty complicated, and ultimately I’ve abandoned nearly all of them. As I said previously, it’s usually best in applescript studio to just work with things in a task based way. Do one thing, wait for it to get done, then move on to the next. If you’re doing things that are so complex that you NEED multithreading/multitasking capabilities, you’ve probably outgrown applescript studio and should consider learning a technology that has this ability built-in. Inventing a hack in ASS because you don’t want to learn obj-c and do it right can lead to your frustration and ultimately may make your system unstable and unpredictable. If it’s a commercial app, I’m not sure that I’d want some thrown-together mishmosh of an app that used these techniques in place of doing things right using separate threads in obj-c.

Just my 2 cents… :cool: