How to activate the aimed application when displaying a cocoa alert

Hi all!

I have a philosophical question today.

Best than any explanation, could you try the script below:

use AppleScript version “2.4” – Yosemite (10.10) or later
use framework "Foundation
use framework "appKit"
use scripting additions

tell application "Mail"
activate

display alert “This first alert should be displayed in Mail.” message “The next one will be displayed in Script Debugger (ignoring the tell block in the script?).”

set myAlert to current application’s NSAlert’s alloc’s init()
tell myAlert
its setMessageText:"This Cocoa alert is displayed in Script Debugger, without activating it."
its setInformativeText:"Script Debugger’s dock icon will bounce."
its setAlertStyle:2
its addButtonWithTitle:"OK"
its runModal()
end tell
end tell

You will see that a cocoa alert is not displayed in the expected application.
They are two consequences:

  • the alert is not modal in Mail,
  • the alert’s icon is the Script Debugger one.

So… my question is in the title!
:wink:

When you run AppleScriptObjC code, it’s always running within the host application, in this case Script Debugger. You can’t target another application with it.

You’re also likely to crash Script Debugger by calling runModal() like that, because it requires the main thread. See the Threading section here:

http://latenightsw.com/applescriptobjc-in-script-debugger-6/

[quote=“ShaneStanley, post:2, topic:185”]
…crash Script Debugger…[/quote]

Yes, I’m aware of that. For now, I’m just playing.
Crashes are not so frequent.
And I will upgrade to El Capitan last month.

[quote=“ShaneStanley, post:2, topic:185”]
You can’t target another application[/quote]

This is what I thought and do not understand.
I mean: compared to old Applescript, it’s a loss.

:neutral_face:

Just to be clear: you shouldn’t run code that requires the main thread in SD, regardless of the OS version – doing so risks a crash.

Using Cocoa dialogs is a compromise. They don’t have the ability to be run in the context of an application – but they do let you do lots of other things you can’t do with display dialog and friends. Some you win, some you lose.

Hi Shane,

[quote=“ShaneStanley, post:4, topic:185”]
regardless of the OS version[/quote]
I misunderstood and thought It was a bug fixed in 10.11.

It’s my lesson of the day.
While discovering AppleScriptObjC, I’m listing the pro and cons.
I am faced with two alternatives:

  • convert all scripts (about 80) that needs enhanced dialogs, from 24u appearance osax to AppleScriptObjC and throw FastScript to the trash, reconsidering my workflow and organisation.
  • or keep my actual setup and take the risk that 24u will not be compatible with future OSes.

As you see, it’s all about philosophy and concerns.
:wink:

On the bright side, at least you have alternatives :slight_smile:

Why would you throw out FastScripts? As long as you don’t put alias in the scrips folder it’s a great app. I’m just curious what problem it caused.

I have used 24 appearance from version 1 and while they haven’t always had a working version right after a system release they’ve alway managed to get it to work with each new release.

Bill

If you had read all posts, you would know that the problem is with AppleScriptObjC.

Talking about 24u, the developers are really nice and prompt to answer your questions.
They’ve done a great job and I’m using Appearance osax every day.
But the osax itself is not really up-to-date. Some bugs are not fixed since years.
This is why I wonder if the app will be supported in the future…

:wink:

I seen your response and I decided to go back and look at Shane’s “Dialog Toolkit 2.0.2.” It is done using an ASObj-C alert but it can do a lot of interface stuff. In it’s current form it only works like a modal dialog. But it still does a lot. I spent the day working on documentation that would make “Dialog Toolkit” more accessible to scripters in general. The big advantage is it’s written ASObjective-C and all that code is visible and modifiable if some new system version comes and breaks it. It can also be enhanced by the user to add extra features. It does have a sdef in the script bundle that would have to be updated if updates are added to the library or the AS dictionary would show the old dictionary.

I’ve used “Dialog Toolkit” before and version 2 works pretty good. Shane posted the URL to download the software in the “Dialog Toolkit” section. Just put the file in the “Script Libraries” folder and it’s installed. Double click the file and and Script Debugger will load the scripting dictionary. SD remembers it after that. With this you don’t have to worry about any developer updating their software. I’ve gone though the ASObj-C code in the library line by line and figured out how it all works. I’m familiar enough with it to create the documentation and post it in the “Dialog Toolkit” section. I got a lot done on the documentation today. I hope to have this all done tomorrow.

I did join this discussion late and failed to fully read the previous posts. Great shame is upon me. I shall go stand in the corner as punishment after I finish this post : ) I’ve notice both the “keystroke” and “key code” don’t work in a script that’s used in the FastScripts menu. They do work great sending text to application processes as long as the script isn’t launched by FastScripts.

Bill