Trouble with OSA and Excel

[Robert Schaaf]

[Note: parts of this message were removed to make it a legal post.]

Hello all,

This week's agony is with rdoc-osa and Excel 2008. I'm trying to
create the documentation files, but the program hangs. I suspect a
faulty AE dictionary.

Here's the setup:

travelers-macbook-pro-17:~ traveler$ rdoc --version
RDoc V1.0.1 - 20041108
travelers-macbook-pro-17:~ traveler$ ruby --version
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]

Here's the output:

Last login: Mon Apr 27 17:10:13 on ttys000
travelers-macbook-pro-17:~ traveler$ rdoc-osa --name 'Microsoft Excel'
/Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:470: warning:
Passing no parameters to XML:arser.new is deprecated. Pass an
instance of XML:arser::Context instead.
XML:arser#string is deprecated. Use XML:arser.string instead
/Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:495: warning:
already initialized constant TRENDLINE_ADD_EXPONENTIAL
/Library/Ruby/Gems/1.8/gems/rubyosa-0.4.0/lib/rbosa.rb:495: warning:
already initialized constant FLOOR

Microsoft Excel-0-440.rb:
mmcmmmmmmmmmmmc........................mc.............m

and there it hangs.

Has anyone done this successfully? Any guidance/workaround would be
humbly appreciated.

Thanks,

Bob Schaaf

PS. I've tried this on two machines with the same result, but it
could be my particular installation.

 

[hengist podd]

Hello all,

This week's agony is with rdoc-osa and Excel 2008. I'm trying to
create the documentation files, but the program hangs. I suspect a
faulty AE dictionary.

Most application dictionaries are not 100% perfect. AppleScript only
uses the keyword-AE code mappings and ignores everything else, so any
imperfections in the parts that AppleScript doesn't use often go
unnoticed by application developers since everything works fine when
tested in AppleScript.

Other bridges that do rely on parts of dictionaries that AppleScript
ignores (e.g. RubyOSA, Scripting Bridge) are far more sensitive to such
minor imperfections, and therefore much more likely to partly or
completely break on them.

Also note that RubyOSA ceased development about 18 months ago, so it may
or may not work with more recent Ruby releases.

Your best bet would be to use rb-appscript (see my sig), which works
much more like AppleScript so is a lot less prone to compatibility
problems than RubyOSA or SB. Matt Neuburg wrote a good article a couple
years back on rb-appscript that includes an example of Excel scripting:

http://www.macdevcenter.com/pub/a/mac/2007/02/27/replacing-applescript-with-ruby.html

Documentation generation and code translation tools are at:

http://appscript.sourceforge.net/tools.html

HTH

has

 

[Robert Schaaf]

Hengist,

Thanks for the reply. I have been using appscript for the better part
of a year, but thought to switch to RubyOSA with the idea that the
whole dictionary would be pre-cached, and thus faster than resolving
the terminology on invocation. But maybe appscript does some similar
caching? I never found it slow, but wanted to optimize AppleEvents,
which are high impedance to begin with.

BTW, where in the application bundle is the dictionary (formerly the
'aete' resource) hidden? I can't find Excel's.

Bob Schaaf

 

[hengist podd]

Hengist,

Thanks for the reply. I have been using appscript for the better part
of a year, but thought to switch to RubyOSA with the idea that the
whole dictionary would be pre-cached, and thus faster than resolving
the terminology on invocation. But maybe appscript does some similar
caching? I never found it slow, but wanted to optimize AppleEvents,
which are high impedance to begin with.

Both appscript and RubyOSA parse an application dictionary the first
time you create an application object. Appscript is quicker at this as
it just constructs simple lookup tables whereas RubyOSA generates
classes, although as this is a one-off cost it's only be a factor in
short-running scripts. Appscript caches the results over the process's
lifetime, so creating additional application objects for the same
application is much faster; not sure about RubyOSA but it may well do so
too.

RubyOSA might be fractionally faster than appscript at constructing
references (it's ages since I've compared it so I can't really
remember), partly as it doesn't rely on #method_missing (which adds a
bit of overhead in appscript) and partly because it lacks a lot of the
functionality found in appscript so there's somewhat less code involved.

I'm pretty sure any difference between different bridges' performance
won't be significant, however, as the biggest overhead in application
scripting is the time it takes for the target application to resolve any
object specifiers and perform the command. As a rule of thumb,
rb-appscript is typically 30-90% as fast as AppleScript, which is about
as fast at building and sending Apple events as you can get. (Commands
that return large numbers of references aren't as fast as appscript
isn't as fast at constructing those than AppleScript)

You might get slightly faster performance from appscript by dropping
down into the AEM APIs (which skip the #method_missing stuff and use raw
AE codes), or by using RubyCocoa/MacRuby with objc-appscript and static
glues (Jordan Breeding, who you can likely find over on macruby-discuss,
has been doing this). But I doubt it will make a significant difference.
The biggest improvement will come from reducing the number of
application commands you use in the first place, e.g. by having commands
work on more than one object at a time (there's a chapter on
optimisation techniques in the appscript manual), though Excel's
scripting interface provides little opportunity for this due to the way
it's designed.

BTW, where in the application bundle is the dictionary (formerly the
'aete' resource) hidden? I can't find Excel's.

AETE resources are held in .rsrc files. Use DeRez to extract them,
although I can't think of any reason you'd want or need to.

HTH

has