While holding the Ruby Hoedown BoF about RubyOSA and AppScript, I mentioned how I’ve never gotten a return value out of RubyOSA — which is why I used AppScript when I needed a return value.
Shoot me now.
A quick google of “rubyosa applescript return value” yielded this post to ruby-talk-google. Woops…
It’s this simple:
require 'rubygems'
require 'rbosa'
skype = OSA.app('Skype')
OSA.wait_reply = true
call = skype.send2 "call echo123"
And call is non-nil.
Admittedly, I’m somewhat at a loss as to why wait_reply is defaulted to nil…
Update 8/11/04 1609: Laurent tells me that, if the Applescript definition is correct, RubyOSA should correctly provide return values. Chalk that up as yet another bug in the Skype Applescript API. I’ll report it soon (it’s going into iGTD now…).
– Thanks, Laurent!
3 comments ↓
AppleScript ignores most of the information provided by application dictionaries, and since application developers only test their scripting interfaces with AppleScript (assuming they test at all) it’s not unusual for mistakes to slip by in those areas. RubyOSA relies very heavily on this otherwise unused information, which is why it’s particularly prone to choking on dictionary defects that don’t bother AppleScript.
Early versions of appscript that tried to rigidly enforce the dictionary also ran into compatibility problems, which is why later versions deliberately mimic AppleScript’s own behaviour as closely as possible. Basically, appscript’s currently policy is that if something works in AppleScript it should work in appscript too. It also provides various mechanisms for getting ‘under the hood’ - e.g. the lower level aem API allows you to build references and commands using raw AE codes (equivalent to using AppleScript’s raw chevron syntax) - so on the very rare occasion that you do run into a compatibility issue it should always be possible to work around it.
HTH
has
http://appscript.sourceforge.net http://rb-appscript.rubyforge.org
“Admittedly, I’m somewhat at a loss as to why wait_reply is defaulted to nil…”
FYI, I recently looked into this behaviour during a different discussion and it turns out to be a design defect in RubyOSA: if a command doesn’t return a value, then RubyOSA’s default behaviour is to send the Apple event with the kAENoWaitReply option set.
This causes two problems when sending commands that don’t return a result (not counting the additional problems caused when the application dictionary isn’t 100% accurate):
The application immediately returns control to the script without waiting for the operation to complete, which may lead to synchronisation issues in subsequent parts of the script.
If either the application or the Apple Event Manager throws an error in response to the command, it is automatically ignored instead of being reported back to the script as you’d expect.
It’s a dumb behaviour (one of various faults I’ve encountered in RubyOSA), but the author isn’t an expert on AppleScript technologies so I’m not entirely surprised. Apple event bridges are fiddly things to get completely right unless you really know what you’re doing - and even then you can still get caught out by individual applications doing weird or stupid stuff, which they frequently do. Even appscript - the Ruby version of which finally reached beta this week (yay!) - has been several years getting all the kinks thoroughly knocked out, and while I think it’s been worth it there’s been more than a few days when I’d have killed to have a nice simple COM interface for a change. :p
Anyway, feel free to include the above fault description if you want to file a RubyOSA bug report on this issue.
HTH
has
http://appscript.sourceforge.net http://rb-appscript.rubyforge.org
Thanks, Has. I’ll pass it along.
Leave a Comment