Discover other bug in Automator with the action Run AppleScript.
I was curious what kind of methods it was using and find out it use OSAScriptController.
It looks like Apple have not improve it for many years.
Now to my discover.
If you use the method isKindOfClass in AppleScript Action it will return error. The reason is
when it compiles it change the method name before it runs. On other hand if you run the workflow
it runs only once and second time it will return error.
Its means the method couldn’t be used in a script that use ASObjC.
I also try |isKindOfClass|:(current application’s NSArray’'s |class|())
The strange thing is… if I compile with the acion (run AppleScript) it change.
If I instead run the workflow without compile the action its runs once but not twice.
Quit Automator and relaunch it. I suspect you’ve compiled with the wrong capitalization at some stage. Automator uses a single component instance of AppleScript, which means once you compile using a capitalization style for a specifier, you can’t change it without relaunching.
Shane it looks like you are right… but that also mean miss-typing is not allowed in Automator.
I wonder what all developers would say if the same thing happened in Xcode.
Its truly a serious bug, almost the same when some people in early days at Apple thought it was enough to only have support for 1 undo. (memory reason) Instead of innovate a way that do no infect the memory there users could benefit of several undo to exchange the user experience.
I have never been a fan of Automator to be honest, I hope Apple will do it much better with Shortcuts in macOS 12. And this is other reason I need to get a mac that use ARM and also support future OS releases. I guess I have to admit my MacBook Pro is old
Mojave was a good release compare to others, I do not know so much about Big Sur becouse I couldn’t install it on my machine. And I only running Xcode on Catalina on extend SSD.
I guess if I get a ARM MacBook Pro this year I guess it will be Big Sur.
It’s not really a bug, and it’s not exactly Automator’s fault. The same thing used to happen in Script Editor (and Xcode, when it used to support compiling AppleScript).
It can also happen still, if, say, a library uses a different capitalization. Let’s say a user defines a variable SetName in a library — any script that uses the library will not be able to use the setName: method.
It’s just one of those AppleScript oddities that probably saved memory in days when resources were tight, and has never been corrected.
I had that experience when I used the method performClose as handler. To simulate a close experience for a window. I never solve it but in return the close button (red button top left corner
stop to work). So the only option I had was to force quit Script Editor.
use theLib : script “ScriptLibrary”
Would not theLib’s setName:(myName) load the script instead of a method.
If you set a script object to a script library I guess it wouldn’t conflict.
Is this correct thought ??
And it we later use
tell NSImage
its setName:“my string”
end tell
or
set theImage to current application’s NSImage’s alloc()'s init()
theImage’s setName:“my string”
The solution is not to quit a application to solve a pore approach or a mistake from a user.
And if that is Apple solution its a bug in my world or a bad experience for any user who like to use ASObjC in Automator. When (Apple) with Objective-C has a case sensitive approach to methods it would make sense to also be able to work in a scripting language that also support it.
Honestly, no. I’d love a solution – it can have much more serious consequences than your example – but I can think of zillions of other things in AppleScript that I’d rather time and resources be spent on. It’s a historical artefact of melding two languages with vastly different approaches. Given the reality at the time, the alternative would probably have been simply not to support ASObjC.
The background to why I think they way I do has to do with the experience I have in Project planning for industry. In some cases a machine could hang or freeze and not be able for input or continue.
In the early state of the project and testing it never show. In the process of maintain things less inputs or change from the core to not interfere or to produce more problems is important and consider.
When something become a finish product and still have some issues.
To restart something after a hang/freeze is a quick solution but it never change the perspective of the user experience and the design. The reason is it was never accepted from the design people or the manager of a project in the first place. It later become a user knowledge that everyone who use it have to know. To be able to solve a task that shouldn’t be there in the first place.
I think you’re missing the context. AppleScript didn’t change: this behavior was seen as a feature. Under the hood, all handler names were stored as all-lowercase strings, and the whole idea was that case should never matter. You didn’t restart – you just didn’t care what the case was.
It was only about 30 years later that ASObjC made case matter, and by then the die was well and truly cast. It had to be a compromise.
