Calling a script that is already running

I have an Automator Service which launches an applet and runs a handler within. The result is the applet running with text from the Service pasted into a text box in the applet’s dialog. It works.

But, if the applet is already running it’s in the middle of displaying that dialog and can’t respond until it has finished the dialog. So, when the applet is quitted, it’s launched again to do what the Service has requested.

I’m looking for a way of coping when the applet is already running. One idea is to test the is running property and if positive, use GUI scripting to bring the applet to the front and paste the text into the text box. But, that relies on the user allowing assistive access for the Service. I’m also not sure of how to know that the text box has the focus.

Is there a better way ?

Thanks.

It’s how modal windows works in Mac OS X and there is simply nothing you can do about. It’s an design that has been chosen on purpose.

Here’s another way, not sure what defines better. You can create a dialog using AppleScriptObjC but show it as a normal window. Applets are scriptable so you can create handlers to update the window contents which can be called by external scripts. Creating responsive UI on the fly requires a lot of code but is not difficult.

DJ, thanks, much appreciated.

I suppose by ‘better’ I mean more robust but also I like easier. The dialog is an enhanced window using Shane Stanley’s Dialog Toolkit Plus but I don’t know how to make it a normal, non-model, window.

This is another good reason to learn AppleScriptObjC.

Cheers.

Garry

Up to a point. Problems can happen when you have a UI with controls that call actions in your script because of Apple’s LIFO nature – you can interrupt whatever code is already running.

Maybe I missed something, but the reason I made my dialogs modal is because the non-modal variations kept hitting edge cases where behavior would be wrong intermittently. I could only make non-modal dialogs reliable in Xcode-based projects, not when run from standard AS applets. (I think at least one Apple sample script was withdrawn for this reason.)

You’re more than welcome!

I’m not familiar with Shane’s Dialog Toolkit Plus and I don’t want to put Shane on a spot here so I think anything about this library should be discussed with him. The name of the library is quite self explanatory that it involves only dialogs (modal windows) and not normal windows.

Of course, but the applet is called externally and it will be managed/controlled through AppleEvents so it will be interrupted by AppleScript’s own busy-wait nature. When an AppleEvent is on the main thread the application will become unresponsive and user interaction won’t affect the application.

The thing Shane mentioned and my reply is also a reason not too :wink:

I did say I’d like easier choices - so I’m going with GUI Scripting. Only downside is that it requires user to allow Assistive Access. But, that’s not major as the Automator Service is optional for the user anyway.

Many thanks to you both.

[Edit some time later]

Well, maybe it’s easier to learn ASOC. I’ve prepared the script in an Automator Service which will switch to my applet and set the value in a text box. But, I can’t get it granted Assistive Access. All workflows are greyed out in the open file dialog of the preferences pane. It seems that only applications can be granted assistive access.

So, I saved the script as a plain AS applet and as an Automator Application. But I can’t get either of those recognised as Services. I have tried killing and flushing pbs with no luck. I’ve had this trouble before. The only way I can get a script recognised as a Service is to save it as a workflow in Automator. But the Security & Privacy prefs pane doesn’t allow workflows to be granted assistive access. Catch-22.

[Edited with another idea more time later]

Well, maybe I could have an Automator Service which gets the text; launches and passes the text to an applet (to which Assistive Access has been granted) which in turn calls my applet and puts the text into the text field of the open dialog. I’ll give it a try tomorrow.

Cheers.

I’m guessing this topic is where I should ask about my problem.
I have a Xcode ASOBJc project and I. My AppleScript
I’ve added a handler that incorporates Dialog toolkit plus lib

When then handler is run the dialog window shows.
All the controls work, but once I click OK it fails.

Oh an it’s a display advanced alert

Logger window shows:
-[NSButtonCell TITLE]: unrecognized selector sent to instance 0x6080000ede00

I have placed NSLogs at points in my code
And it fails right after the dialog is done,
I.E. I’m not able to get ControlsResults variable.

I’m guessing from what I’ve been learning about modal panels
Is that my App is looking for a handler to deal with the button press
Rather than the DTKP Lib handling the event?
Guessing DTKP is supposed to get the “TITLE” of the button
I pressed and assign that to the Button variable?

Should I wrap the code inside a Tell DTKP statement?

Should I add a

My other option is to just rebuild it in interface builder
As a panel. I really should learn how to build an program
With panels anyhow.

If I go the above route. Is there anyway to include what I’ve built
With DTKP and use that as a view / accessory view and add it to the panel?
(As I’ve seen that method used in a few example codes I’ve looked at)

Thanks

I’m guessing that you have a variable called TITLE somewhere in your code, which means when AppleScript then loads the lib it’s changing its use of title() to TITLE() to match. Try changing the name of the variable in your code.

yes there is.
I will try this.

My property TITLE was buried quite deep in my script lisbrariwa
And is also a ELEMENT of the original XMLs
So I modified the DTKP script to
Xxx’s valueForKey:“title”
Xxx’s setValue:aValie forKey:“title”

While that failed to assign things it worked
For continuing in the script.

I tried piping title but it would always
Unpiped them on compiling

Leaving it in caps is just setting up more potential problems for later.