El Capitan

In case you’ve missed them, the official release notes are here:

developer.apple.com/library/mac/releasenotes/AppleScript/RN-AppleScript/RN-10_11/RN-10_11.html

There are a few other issues worth noting.

First, it looks like the activate command is back to working like it was before Yosemite.

Second, there’s been an improvement in the progress dialog that appears when you run an applet and set the various progress properties. The problem in Yosemite was that hitting the Stop button in the dialog would stop a script immediately, with no opportunity to do any clean-up. Now it generates an error that you can trap in your script, allowing you to end things gracefully. The dialog still lays itself out in a rather lame manner, so if you have long lines you need to wrap them yourself (the left side of the dialog is pinned near the centre of the screen, but it can grow indefinitely to the right). But the change to the Stop button makes it much more usable.

Third, there’s been a fix for a bug involving AppleScriptObjC that would manifest itself in script editors when testing scripts. Sometimes an editor would crash after running a script three or four times, for no apparent reason. That no longer happens.

And fourth, there have been some updates to bring the AppleScript Language Guide more up to date. It’s still got some out-of-date stuff in it, but it’s a start.

The release notes mention that NSURLs are bridged to aliases. Actually, you can use “as” to convert them to POSIX files or aliases (the latter only if they exist, obviously), and in the case of NSURLs in dictionaries or arrays, they get converted to POSIX files when converted, not aliases.

In the scheme of things, this looks a pretty good release for AppleScript. The bug fixes cover several common aggravations, and reliable folder actions will make a nice change. The better bridging of structs may not mean much to a lot of people, but it opens up yet more capabilities for AppleScript. And the bridging of dates/NSDates and files/NSURLs will be a great convenience for AppleScriptObjC users.

The ability to install script libraries in any application bundle is also one to watch…

. except with regard to Script Editor.

  1. The text-only toolbar button bug hasn’t been addressed.
  2. The reverting-format bug hasn’t been addressed.
  3. Fonts set in the Descriptions of scripts saved before the upgrade are no longer applied. (This happened on a previous upgrade too.)
  4. Long results and messages in the lower pane are now wrapped a couple of inches short of the right margin.

At least my Autosave settings haven’t been tampered with. :slight_smile:

No 1 is not specific to SE, so I’m not sure you can call it an AS issue, and I don’t think I’ve seen any evidence implicating SE with No 2 either. No 4 is intriguing…

Well of course my apologies to SE if the bugs aren’t its fault. :wink: But it is the app in which they manifest for me.

You can see #1 in Disk Utility.app and Automator.app, too.

I guess I’m more positive for two reasons:

  • I have snippets here that would crash SE under Yosemite, and they don’t under El Capitan.

  • Autosaving has been changed to eliminate those “The document could not be saved” dialogs.

Interestingly, El Capitan’s version of Disk Utility doesn’t have a menu option for customising the toolbar. But Control-clicking the toolbar does bring up a contextual menu with that option and direct settings for the button types.

If the developers of Apple’s WWDC advice you not to update to the first iOS 9 release and certainly not to El Captain, you know there is some serious lack of confidence in their software. Certainly, as you have proven, at high level it’s very buggy.

Yes, customising is optional, and doesn’t make sense if there are only a handful of options.

Now that you’ve brought up the text-only problem again, I’ve had another look. As you know, my own app displays the same issue. It turns out it’s a result of the move to different style buttons as part the Yosemite “look” – the new-look buttons actually sit on top of existing (now blank) toolbar items. But adding such a button modifies the behavior of the text label, which belongs to the toolbar item, and is actually a menu item.

The solution is to replace it with a new menu item that calls the same method as the button, and in the case of the View menu, add a submenu of options to it. And then make sure it’s enabled/disabled at the same time as the button and toolbar item.

Which is a long-winded way of saying I’ve at least fixed it at my end…

I just finally updated to El Capitan (directly from Mavericks) and I had a script using “tell me to activate” before a “choose from list” statement. It was working correctly, and now it isn’t. It’s the frontmost window, but it does not show as active.

Should look like:

But looks like:

Looks right after I click on the dialog (only one item”a textclipping file”in the example list.)

How about some code?

When I trigger choose from list from the Scripts editor I’m unable to reproduce the described behavior.
Maybe it’s because my imagination is unable to guess what code is around the choose from list instruction.

Always from the Scripts Editor, if I trigger :

tell application "TextEdit"
	activate
	tell me to choose from list {"item 1", "item 2"}
end tell

The dialog doesn’t appear.
I must click in the Editor window to get it and only after that I get the “odd” dialog.

If I trigger - as you wrote :

tell application "TextEdit"
	activate
	tell me to activate
	choose from list {"item 1", "item 2"}
end tell

the dialog is displayed at front in the “standard” look.

If I trigger :

tell application "TextEdit"
	activate
	tell application (path to frontmost application as string) to choose from list {"item 1", "item 2"}
end tell

the dialog is also displayed at front in the “standard” look.

Yvan KOENIG running El Capitan 10.11.5 in French (VALLAURIS, France) mardi 31 mai 2016 12:13:22

Hi.

When you tell “me” to activate, the command goes to the application running the script. If you’re running a compiled script from, say, the system script menu, the application behind that’s a faceless app and can’t come to the front. That would give the effect you’re seeing.

Two possible solutions are:
Tell the current frontmost application to display the dialog:

tell application (path to frontmost application as text)
	set theChoice to (choose from list {"blah blah blah"})
end tell

Or save the script as an applet. You can still invoke it from the script menu, but its own application mechanism can be brought to the front.