#MARSEDIT APP HOW TO#

Sure enough the value for NSPrincipalClass is “MEApplication”, so why am I getting an NSApplication instance instead? And why did this suddenly start happening in recent beta test releases of the app? I happen to implement some of MarsEdit’s high level scripting support in the NSApplication subclass. It should be of class MEApplication.Īpple doesn’t encourage subclassing NSApplication, but it’s well-documented and appropriate in some circumstances. The instance returned above is of class NSApplication, which would normally be fine, except that I’ve subclassed NSApplication in my app. Nothing to be alarmed by, right? Luckily, it jumped out at me as all wrong, even though it’s the subtlest of things. I witnessed that AppleScript internally determines the object by calling something like this: (lldb) po topLevelObject]

#MARSEDIT APP HOW TO#

It made sense to discover that, in the course of determining how to handle the command, it would consult the application’s “top level object.” That is, the application object itself. Setting a breakpoint on -, I could trace the evaluation of the request from AppleScript, watching as it ultimately failed to handle the command and returned an error. I was so perplexed that I found myself digging around inside AppleScript’s own internal handling of the command. It seemed as though AppleScript were unable to reckon any properties of my app stemming directly from the application object itself. I had a real head-scratcher of a bug with MarsEdit, manifesting as a subtle failure of specific AppleScript commands to work properly in the release builds of the app.

Marsedit app