Re: building an AppleScript editor app
Re: building an AppleScript editor app
- Subject: Re: building an AppleScript editor app
- From: Ken Thomases <email@hidden>
- Date: Sun, 07 Dec 2014 05:42:23 -0600
On Dec 7, 2014, at 3:46 AM, sqwarqDev <email@hidden> wrote:
> As the title suggests, I'm building an AppleScript editor (Objective-C, not Swift). I've got reasonably far replicating the abilities of the in-built Script editor and have even added a few bells and whistles. However, I'm stuck, conceptually, on one particular hump.
> will produce something like this:
Are you aware of the OSAKit framework and the OSAScriptView and OSAScriptController classes? I don't find documentation, but the headers seem relatively straightforward. From the looks of it, a lot of the functionality of Script Editor is just a thin wrapper around these classes.
>> AEDescriptor is:
>> <NSAppleEventDescriptor: 'capp'{ 'desk':'obj '{ 'form':'name', 'want':'cfol', 'seld':'utxt'("Fusion:Users:sphil:Desktop:"), ..., ....
>
> To see the output I want, just run the AppleScript code in OS X's built-in Script Editor and look at the Results pane.
>
> I can get seld's 'utxt' easily enough with the stringValue property, but I'm assuming the rest require parsing the codes from the target app's dictionary (unless someone know's a better way).
> ii. parse the AEDescriptor result for the four-letter codes
> --> (currently, my thinking here is to turn the whole result into an NSString and use an NSScanner)
That's crazy. An NSAppleEventDescriptor is already a data structure. Converting it into a string and then parsing the string into a data structure is just redundant.
What you've shown above is just the description string of the NSAppleEventDescriptor. It's not its native content.
You can query the descriptor for its -descriptorType. If it's typeAEList, then you would use -numberOfItems and -descriptorAtIndex: to iterate over the elements. Remember that -descriptorAtIndex: takes one-based indexes.
In many cases, the descriptor will be a record. The descriptor you showed above is a record. A record can have an arbitrary descriptorType. You can use AECheckIsRecord(anAEDescriptor.aeDesc) to test if it's a record. I don't see a Cocoa equivalent. The descriptorType will indicate what specific type of record it is. Here you would need to consult the scripting terminology dictionary to figure out what class it represents. However, even without knowing the class, you can enumerate the keywords using -numberOfItems and -keywordForDescriptorAtIndex: (again, one-based index). For each keyword, you can get the value descriptor using -descriptorForKeyword:. Actually, if you're iterating by index, you can also use -descriptorAtIndex: to get the value, too. An AERecord is a special type of AEList, so it can be accessed like a list.
Given that each value is a descriptor, you can apply the same techniques recursively to traverse them. Obviously, you'll eventually get to leaf nodes, which won't be lists or records. Those will have descriptorTypes of typeUnicodeText or typeSInt32 or the like.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden