> Once you figure out how to get your Blob on the pasteboard when your app is not running, it should be downhill thereafter.My app will always be running, as they'll be dragging a UI element to the Finder.

> I’m sure you can figure how to combine the aforementioned methods with AEM’s AEFlattenDesc/AEUnflattenDesc procedures yourself.Thanks for the tip!> Oh, and as far as launching apps goes, you need to use LaunchServices for that (either what’s left of the old C LaunchServices API, or AppKit’s NSWorkspace).Did eventually find the NSWorkspace API call. Managed to have some success creating AE's with NSAppleEventDescriptor today, including building object specifiers, so it should be all hunky dory from now one. :-/

Thank you! That works. It's amazing how much simpler your code is than mine, and how much more familiar I need to be with the APIs to do things correctly. It's interesting how, in some situations, you don't really need to create Swift Pointer instances to work with C APIs.After posting this discussion I got to thinking about using the AE C APIs. I want to store these event descriptions to disk, and thought it would be better to serialize the AEDesc data structure than the NSAppleEventDescriptors, then I discovered that you can get and set the AEDesc on a NSAppleEventDescriptor.Working with pointers, even from Swift is going to increase the potential for bugs and intruduce needless complexity so I will take your advice and work with NSAppleDescriptor from now on.Thanks Eskimo!

Thanks for clearing that up for me. Once I learnt the AEM data structures and had a read through a lot of Inside Macintosh: Interapp Communication, it seems quite easy to follow. Any idea where the Text Suite's script definition files are located on macOS? I've found ScriptingAddtions, DatabaseEvents etc, but can't seem to find the Text Suite.

This subprocess issue is one I was thinking about recently. I see there are security issues regarding IPC and just haven't had the time to look into it yet. An app has to request temporary entitlements or specify exactly which apps it wan't to communicate with. But I guess those entitlements would extend to subprocesses. If anything it would prevent the main app process from crashing and allow you to save face albeit only slightly if an AE IPC process crashed.

>One good thing about Apple’s CS docs if memory serves: it’s the once place where they do talk about one-to-one and one-to-many relationships, which is the key to understanding how an Apple Event Object Model really works.I'm actually glad I read the higher-level Cocoa docs first. It's actually very easy to understand the design.> As far as studying other code, the only other AE bridge of worth is Frontier’s, but I don’t think you’ll glean much from that as it’s ancient, ancient CI was reading an article on AE from 1992 and all the example code was written in Pascal :-OThanks for the SourceForge link. I'll only message you if I get really stuck. Plus I've still got to read the AE Programming Guide this weekend and go through your project, so you probably won't hear from me for a while.

Also, thanks for sharing your work on SwiftAutomation. For me it's invaluable as I haven't found any other code yet. I've had a cursory glance over your documentation and some of the code. I see what you mean by 20 years of hard experience going into the code. The example that interests me the most is the creation of NSAppleEventDescriptions and their collaboration with AEM. It looks like I'll have to fire off events based off the sdef data. Do you have an email or website submission form I can get you on if I have any questions? :-)

Thanks very much for your help. I know I'm on the correct track now.

"I think you’re getting confused by the KVC data found in .sdef files. That data is not provided for clients’ use; it’s purely for use by the CocoaScripting framework upon which Cocoa-based apps implement their AE support."I realize this 100%. I'm really not confused about sdef files or the data therein. I've read the Cocoa Scripting Guide and the Scripting Bridge Programming Guide for Cocoa. So I know why sdefs exist and what the data therein describes. I think the mistake I've made is in assuming that every app has to provide cocoa keys in their sdef, but they don't. So just because an app has a scripting defintion doesn't mean you can access it via cocoa unless use use the sdp tool and link the generated header in. Which is not going to help me. If you want to send Apple events to a running app that has Apple Script support, can I do this using the AE code information in the sdef file and creating my own events? I haven't read the Apple Event Programming Guide yet. Just wondering how far I'd get with this approach.

"In AppleScript’s world, there are hundreds of apps with wildly different structure and commands, and little consistency in behavior." That's quite true regardless if which language you are using, otherwise all apps would be identical. From a user perspective, I think the main problem with AppleScript is the built-in natural language syntax grammar.

Thanks for the advice. I'll have to experiment a bit and see what is going to be a good fit for what I'm designing.If I went the Apple event route, would it be easier to figure out at runtime what events an app responds to or would I have to parse the sdef in the app's bundle? Parsing the sdef is not really an issue for me, I've already designed a Core Data model from the SDEF.dtd, but, if as you say, there is no other way to get this info for a running app, then I'll have to parse it. That way, I'm guessing I'd make use of the AE codes in the sdef and not the <cocoa> element KVC-compliant key mappings, and use those with the Carbon framework?My macOS app is obviously written in Swift and (Objective-C where necessary), so I just assumed Sripting Bridge would reduce the amount type coersion I've had to get involved in etc. Is not going to be quite difficult to handle type coersion and getting the AE data to play nicely with a Swift GUI? I haven't read the legacy document, Apple Events Programming Guide (2007) yet. Is it still fairly accurate?Is it not possible to use a support ticket to get some private feedback from you? I simply can't publically divulge some of the design details of my app. It's just frustrating because if I could tell you privately exactly what I'm trying to achieve, it may have a bearing on your opinion.

Hi Quinn,> "I presume you’re using KVC as a shortcut for key-value-coding"Yes! Sorry for not being particularly clear. What I mean by "KVC definitions" is the KVC-compliant keys in the sdef file. All I really want to do is use those keys to access the SBApplication attributes and elements just like any other KVC code would. I don't have a need for working directly with Apple Events. It's the Scripting Bridge that really interests me.So the question is, is it possible to query a system framework at runtime to get these KVC keys that are described in a running app's sdef file?

Thanks for pointing out that Carbon API. :-) I've not delved that deeply into AppleScript yet. Perhaps you can point me in the right direction as I start this project idea I have, or I may just be barking up the wrong trees.The idea is to get hold of the KVC definitions for the AS object graphs from a list of running applications and call them using KVC. While I can slurp up a sdef file and stick it into Core Data and run my command builder off those reference definitions, I was hoping to be able to get the AppleScript KVC keys at runtime via an Apple framework. Do you know if this is possible, and if so how? I was hoping to simply use the Scripting Bridge to query SBApplications using the cocoa keys in the sdef.> I believe the droid you’re looking for here is OSACopyScriptingDefinitionFromURL. As far as I can tell this will issue the kGetAETE event to the app if required.What is the consequence of that? Would that then ensure I'd be able to query the system for KVC keys somehow, or will it simply load the sdef XML into CFData?