first, I am a beginner with apple and mac os.
I have wrote a script for 10.6 to use the spellchecker within my Java-Program:
tell application "Automator Runner"
set mySpellChecker to call method "sharedSpellChecker" of class "NSSpellChecker"
set foundLanguages to call method "availableLanguages" of mySpellChecker
end tell
which works nice under 10.6
But now under 10.7.2 even under the applescript console an error occurs at:
tell application "Automator Runner"
set mySpellChecker to call **method** "sharedSpellChecker" of class "NSSpellChecker"
set foundWords to call method "availableLanguages" of mySpellChecker
end tell
** Expected end of line but found identifier.
Can anyone please give me a hint, what has changed from 10.6 to 10.7. In the Changelog I cant find either an AppleScript change or a change with the spellchecker API. Also other scripts from the web using the "to call method ..." fails with the same error.
Yes, it seems that "call method" commands do not work any more in 10.7. Apple has been phasing this out with 10.6 and finally did away with it fully in 10.7. They have replaced this way of accessing objective-c methods with AppleScriptObjC language. As such they made an addition to applescript in 10.7. You can now write AppleScriptObjC code directly in AppleScript Editor. Under 10.6 you could only use it through Xcode. So we lost something but we gained something too. We can debate which way was better but Apple feels AppleScriptObjC is the way forward.
Related
Previously to the Yosemite update, I used this Applescript to control my Spotify.
Everything worked as a charm when I ran /usr/bin/osascript /Users/jdrummond/SpotifyControl.scpt play/pause.
Now that I have updated my OSX to Yosemite, I keep getting this when I run the same command:
/Users/jdrummond/SpotifyControl2.scpt:1217:1222: script error: Expected end of line, etc. but found identifier. (-2741)
So I tried to create a simple Applescript to interact with Spotify:
using terms from application "Spotify"
tell application "Spotify" to play
end using terms from
But I'm also getting an error:
What am I doing wrong and how to interact with Spotify on Yosemite? Anything changed?
This issue was reported to Spotify and will be fixed in the next update to the desktop client (I'm a developer there and can verify that it has been fixed).
Currently, the following simple script is working for me on OS X 10.9.5, Spotify 1.0.3.101.gbfa97dfe
tell application "Spotify"
playpause
end tell
I saved it as an app in other to use with my Microsoft Keyboard, so that the play/pause button launches the simple app that plays/pauses.
Spotify destroyed the ability to use AppleScript very recently with their latest idiotic update. It's not Yosemite, it's Spotify.
I have not been able to get my NSPopover to detach to a window in my own projects, so to simplify I tried the Apple sample.
I downloaded a fresh copy of the Apple sample project: http://developer.apple.com/library/mac/samplecode/Popover/Introduction/Intro.html
It behaves the same, which is to say I can't drag the window to detach it either.
The project seems to provide all the correct windows and controllers and implements the detachableWindowForPopover: delegate method. However the method is never called.
Does anyone know the secret to detachable NSPopovers?
Found the answer while typing the question…
Mac OS X 10.10 Yosemite has a new delegate method:
(BOOL)popoverShouldDetach:(NSPopover *)popover
The default behavior on Yosemite is NO (should not detach). So delegates must implement this method in order for windows to be detachable. The sample project does not implement this method, so when compiled on Yosemite it will not detach (and also produces several deprecation warnings -- maybe I should have taken that hint that it needs an update).
Adding:
- (BOOL)popoverShouldDetach:(NSPopover *)popover {
return YES;
}
To MyWindowController.m fixes the problem.
I want to add an applescript dictionary to my project, but I need to manage AppleEvents to create Methods, classes and events. How I can manage the AppleEvent codes in xcode.
Note:
I don't have the AppDelegate class in the project and I have Mac OS X Leopard and XCode 3.2.
It isn't possible.
Now I'm using Xojo, that can do this.
Then, in the compiled app, I add an SDEF file and I set Scriptable property (in info.plist) to true.
So I've used Dave Delong's brilliant code here to intercept keystrokes in OS X without my app needing to be in focus, unfortunately my app crashes when I try to sandbox it with the message 'deny hid-control' in the console.
A little bit of digging turns up that as of a year ago this wasn't possible, but has anything changed since then? Or does this mean that my app can't go in the Mac App Store since it's dependent on being able to intercept keystrokes? Is there an entitlement that I'm just missing out on here?
I create a window in a helper tool that runs in the background (it's not an app bundle with a .nib and Info.plist, but a plain executable). When -makeKeyAndOrderFront: is called, the window is displayed but it does not "pop" out like an active window.
Can this be fixed?
Regards,
Erik
You should wrap the helper tool as a regular .app bundle with at least Info.plist. Then the problem goes away. A GUI app in OS X needs to have an Info.plist to receive events correctly.
The way a GUI app misbehaved if not in an app bundle has never been clear to me. If I remember correctly, it changed over time, depending on OS X's versions. I think it behaved worse in previous versions of OS X. For example, the window is shown but I couldn't click any UI inside it.
Many people who compiled a program in a cross-platform toolkit faced this problem, see e.g. this discussion here in the WxWidgets wiki. Apparently, OS X doesn't mark a program not within an .app bundle as a foreground-able app, which causes your problem. You can use TransformProcessType from your binary not inside an .app bundle to make a foreground-able app to solve your problem, but that's not a documented/intended usage of this function.
So, just wrap it in an .app bundle.
Update:
This "foreground-able-ness" is controlled by the activationPolicy of an app, see this doc on NSApplication. Found the info on this post on Cocoa with love.