There is an ambiguity in the type of OO checkboxes (row state checkboxes have a different type from user column checkboxes) which may be the source of a bug in the JavaScript for Applications interface to OO.
though the same form works with all other row properties, and this desugared version, which refers to the same property and value, and is in principle identical, succeeds:
I ran this by the developer who designed our scripting implementation in OmniOutliner. Here are his notes:
Not sure I’m exactly getting the jist of the question, but a couple notes…
value can’t return a state enum (as I recall) since those are four-character codes. We currently have the return type on those methods as FourCharCode. We might be able to use NSNumber, but this would cause confusion in number columns since in both cases we need to return a number object and the system can’t tell if you mean the enum or an actual number. I don’t recall if there were other issues the last time I looked at this (originally I wanted to just have value and do the type based on the column).
Cells in checkbox columns can be accessed with state too and will return the enum.
On the -1700 case, though, it sounds like JXA is smashing strings through w/o converting them to the enum in whose clauses? This seems like a JXA bug… we get an AppleEvent with a string in it instead:
In the text case, the error originates when -coerceToDescriptorType: is called with typeAERecord on the offending text and it returns -[NSScriptEnumerationDescription errorExpectedTypeDescriptor] — so this all happens down at the descriptor level before any of our code is invoked at all.
So… as far as I can see, we can’t change our sdef for value and they can’t use state on row. It seems like JXA needs to do proper type mapping for ‘whose’ specifier elements …
I’m not sure how actively Apple is fixing issues with JXA, but in an ideal world it seems like that would be the best place to fix this problem.