Bug: Scripting library generally replaces `name` key of layers with null

Automation OmniGraffle Automation
#1

Error messages returned by AppleScript and Apple’s JavaScript for Automation reveal a general bug in layer-name handling (in the scripting .sdef ? deeper down ?), which may shed light on another bug (already reported) in the layer-handling behaviour of the Copy As AppleScript command. (Uncompilable Applescript with non-syntactic string (null) replacing the expected name:)

The result of the new bug is that in JavaScript for Automation, we can not read properties from the set of graphics on a named layer in an OmniGraffle canvas.

If we begin in AppleScript, by running the following code on a canvas with 3 layers, named ‘A’, ‘B’, ‘C’:

tell application "OmniGraffle"
    tell canvas of front window
        id of graphics where name of its layer = "B"
    end tell
end tell

At first, all seems fine, and we obtain a list of ids for the graphics on the layer.

{1375, 1366, 1365, 1364, 1363, 1362, 1361, 1360, 1469, 1349, 1347, 1279}

Removing the its keyword however, leads to our first error message:

error "Can’t get name of layer." number -1728 from name of «class OGLa»

So far no big deal (just add its, for a more specific reference), but if we now translate the layer specification into the JavaScript specified by the JSA Release Notes (which works unproblematically with other parts of the OG object model):

Application("OmniGraffle").windows[0].graphics.whose({
    layer: {
       name: "B"
    }
});

We see an anomalous reduction of this reference:

Which is immediately reminiscent of the name: → (null) bug seen with attempts to copy multiple layers in the Copy As AppleScript command.

Needless to say, if we attempt to obtain a list of property values (.id() for example) from this defective layer reference, we get a further error message:

#2

Follow up experiment:

This form of reference:

Application("OmniGraffle").windows.at(0).graphics.whose({_match:[ObjectSpecifier().layer, {name: "B"}]}
);

is also immediately reduced to a name → null rewrite:

#3

Thank you for posting this here @draft8! I’ll get some bugs filed for our engineering team to investigate this!

1 Like