If there's another way, I don't know it. It's just an XML file that gets added straight to the bundle, so I don't see how that would work. -- Shane Stanley

I did just find makeScriptingObjectOfClass or whatever it is (not at my desk now), so that’s a good way to ignore readonly properties. Still, seems like something should be doing that when letting

This seems like bug, or I need to override something. I have a class: @interface Blah : NSObject @property (readonly) NSUInteger id; @end The id property is exposed to AppleScript in the Blah

What? I think you misunderstood. This is purely AppleScript communication. Bill and Shane already confirmed I'm doing the right thing. -- Steve Mills Drummer, Mac geek

How do you plan to consume it? As an array, dictionary? You can even save it out as a pList and read it off media if you wish. You can even serialize it to JSON or XML. There even is serializing

OK, thanks for the confirmation. I was hoping there was something analogous to -objectSpecifier that I wasn't finding, such as -valueDdescriptor that would be called on the key-value object found at

Oops, yes. This was on the crash in dragImageForSelection. Jens Alfke wrote on 6/5/19 20:02: -- John Brownie Mussau-Emira language, New Ireland Province, Papua New Guinea Kouvola, Finland

if I follow you correctly, that sounds about right. Cocoa scripting doesn't like simple records -- it wants custom record types. -- Shane Stanley

I can’t add much other than I recall yours was the solution I used too. Off-Topic WWDC is very close and I’d be surprised if there aren’t significant changes to the whole Scripting shambles (I

What's the best way to return data from a scriptable app when the property is a record-type that's declared in the sdef? It corresponds to an Objective-C class. I ended up adding a separate property

That’s the behavior I was getting the last time I worked on this app, a few months ago, but it’s somehow stopped working and I can’t get it to work again. Specifically, what used to work was 1.

I think that reply was meant for a different thread? —Jens

Well, some further testing revealed that this was a way to make it work. It had the side benefit of making the window update more efficiently! Still, it would be nice to know why it was crashing in

Further experimentation reveals that the problem is (as far as I can tell) due to the code that handles a click updating the window. I seem to get a race condition: if I click, hold and drag, the drag

In a similar recent scenario, I found it takes two clicks when the text field is selectable but not editable. (Well, one click and one drag, if you’re actually trying to select text.) What makes

Wild guess, but what about the “can” methods. In the headers is there any hidden secret docs hat might help?

I’ve got a view-based NSTableView that uses NSTextFields. I’d like to be able to select text in some of the columns, mostly so it can be copied to the pasteboard. If I set the “selectable”

Gary L. Wade wrote on 27/4/19 02:07: Doesn't seem to help. Yes, it's a result of various ways of setting the range correctly. I've fixed it so it looks nicer. Yes, the range is correct after calling

The bug in documentation has been reported. Try forcing layout on the text view after setting the selection; there might be some kind of delay from setting it till it’s renderable, and that might

I don't have any useful help for you, but a couple of things struck me as odd about this. First of all, you're treating textView as an optional sometimes, and force-unwrapping it elsewhere. Prefacing