JXA problem — name of application

[JMichaelTX]

@ComplexPoint

If you want to send me a forum mail, I can give you the current contents of my Quiver repository of JXA functions and their AS equivalents – should save a bit of time. Not really in publishable state, but perhaps useful day to day, and as a starting point.

Rob, I suspect that many of us, including myself, would find your Quiver repository very useful. If you don't mind sharing, I'd suggest posting a zip file in a new topic in the "macro" category.

Thanks.

[ComplexPoint]

Generous of you to think so

I’ll certainly put them somewhere at some point, but (rationally or otherwise) I hesitate right now for fear that their uncommented condition might provoke more questions than I have space for in the next few weeks.

The bulk of them are just JavaScript and AppleScript versions of standard abstractions like zip, zipWith etc. that you could find at:

http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List.html

In fact not unlike the more complete and professional library at:

http://ramdajs.com/

I would like to organise them, with at least minimal comments, into some kind of ‘parallel reader’ form where you could see AppleScript and JavaScript versions side by side.

(A lot of them, incidentally, you could already see by looking for the (reasonably numerous) Rosetta Code pages in which the AppleScript and JavaScript versions are translations of each other). See, for example:

http://rosettacode.org/wiki/Water_collected_between_towers

[ComplexPoint]

Returning to the issue of Application.name() method, I've just been looking at an El Capitan system (I'm personally working on Sierra).

While script like this evaluates correctly on both platforms:

(function () {

    var fi = Application("Finder");
    
    return fi.name();

})();

The invisibility of Application objects (and their methods) to the Safari debugger (both the standard Sierra Safari, and the current Safari Technology Preview, is new.

Here is a session, working correctly, in El Capitan 10.11.6

contrasting with the failure in Sierra

I recommend bug reports at https://bugreport.apple.com

(Safari, and Safari JS, are core projects at Apple and properly staffed, not least because they span iOS as well as macOS.

Whereas AppleScript (a whole language, with some largish historic gaps and problems, from record architecture to basic libraries) may be losing its foothold in access to Apple manpower resources, 'JXA' Automation is just a single library object (embedded in the flourishing and well-tended Safari JS interpreter).

I would guess that that makes it a better candidate for securing enough attention to keep it healthy and developing ... But you only get attention if you ask for it )

https://bugreport.apple.com

[JMichaelTX]

@ComplexPoint

contrasting with the failure in Sierra

I am curious, but I don't have macOS Sierra to test.

If you use a longer variable name for "a" and "sa", does that resolve the issue in Sierra?

For example does this work in Sierra?

'use strict';

(function run() {

var app = Application.currentApplication();
app.includeStandardAdditions = true;

var propApp = app.properties();
var nameApp = propApp["name"];

debugger;

return nameApp;

})();

[ComplexPoint]

@JMichaelTX

'use strict';

(function run() {

var app = Application.currentApplication();
app.includeStandardAdditions = true;

var propApp = app.properties();
var nameApp = propApp["name"];

debugger;

return nameApp;

})();

No, the pattern is the same – strings like .name display correctly in the Sierra Safari or STP debugger, but for Automation objects only a Symbol.toPrimitive error message:

"Error: Symbol.toPrimitive is not a valid class for application (null)"

(in lieu of a tree of their methods and properties)

[MitchellModel]

@ComplexPoint

$('~').stringByStandardizingPath.js

What is this and where does it come from? I've been using $(partial-path-string).stringByExpandingTildeInPath.

[ComplexPoint]

• Enclosing any string in $(’…’) returns a reference to an NSString

• the final .js is syntactic sugar for ObjC.unwrap()

• The full list of NSString methods is here:
  https://developer.apple.com/reference/foundation/nsstring
  https://developer.apple.com/reference/foundation/nsstring?language=objc

• stringByStandardizingPath() includes a call to stringByExpandingTildeInPath()

[JMichaelTX]

@ComplexPoint

PS, for the home path, I personally tend to write/paste:

$('~').stringByStandardizingPath.js

Thanks for sharing this cool tip/snippet.
It provides an easy solution to a common problem.
Added to my JXA snippets (now using SnippetsLab).