Scripting Bridge: the Excel case

  • I'm trying to send AppleEvent to Excel using Scripting Bridge. I
    generated the Excel.h header like this:

      sdef /Applications/Microsoft\ Office\ 2004/Microsoft\ Excel | sdp -
    fh --basename Excel

    ... and I imported it in the relevant .m file, where I create the app
    stub like this:

      NSURL *appURL = [NSURL fileURLWithPath:@"/Applications/Microsoft
    Office 2004/Microsoft Excel"];
      ExcelApplication *excel = [SBApplication applicationWithURL:appURL];

    Unfortunately, I get compile-time warnings and a lot of syntax errors
    with the big (unmodified) header file:

      warning: multi-character character constant
      error: syntax error at 'OTHER' token
      -->  ExcelE151SheetTypeExcel4IntlMacroSheet = '\0\0\002'',
    ...
      error: 'ExcelE204PasteFormats' undeclared here
      -->     ExcelE204PasteFormats = '\002[\357\346',

    I am surprised to see characters such as ' and [ in the escape
    sequences generated by sdp. Am I missing something here? What am I
    doing wrong? Is Excel simply not ScriptingBridge-savvy?

    TIA,
    J.P.
  • J.P.Pellet wrote:

    > I'm trying to send AppleEvent to Excel using Scripting Bridge. I
    > generated the Excel.h header like this:
    > [...]
    > Unfortunately, I get compile-time warnings and a lot of syntax errors
    > with the big (unmodified) header file:
    >
    > warning: multi-character character constant
    > error: syntax error at 'OTHER' token
    > -->  ExcelE151SheetTypeExcel4IntlMacroSheet = '\0\0\002'',
    > [...]
    > I am surprised to see characters such as ' and [ in the escape
    > sequences generated by sdp. Am I missing something here?

    Forgetting to escape the single-quote character is a bug in sdp; file
    a report. In the meantime, you'll have to fix any dodgy OSTypes in the
    header file by hand.

    > Is Excel simply not ScriptingBridge-savvy?

    While not directly related to the above bug, which is entirely sdp's
    fault, a general criticism I'd make of Scripting Bridge is that it
    isn't terribly AppleScript-savvy. Application developers have spent
    the last fifteen years designing and testing their scripting
    interfaces against the AppleScript language, which has its own
    particular way of doing things, based on the not unreasonable
    assumption that if something works with AppleScript then it's okay.
    Now Scripting Bridge comes along with its own ideas and assumptions
    about how application scripting should work, which may or may not bear
    any resemblance to the way scriptable applications actually behave in
    the real world.

    There's a smug aphorism in there somewhere about those who fail to
    learn from history, etc, but the main point is that you can expect
    Scripting Bridge to not work as well as AppleScript with some
    applications, and possibly fail completely with some others. Carbon
    applications are more likely to be affected by this than Cocoa ones
    (since some of SB's inbuilt assumptions are based on Cocoa Scripting
    behaviours), although the latter aren't exempt either. Application
    scripting can be a messy, frustrating and chronically under-documented
    business, but it is what it is and if you want to get things done it's
    something that you and the various Apple event bridges just have to
    deal with.

    Anyway, if you want to try an alternative to Scripting Bridge, objc-
    appscript is coming along nicely:

    http://appscript.sourceforge.net/objc-appscript.html

    e.g. To make an Excel glue:

    osaglue -o EXGlue -p EX Microsoft\ Excel

    (I'd offer some sample code too, only I don't have a copy of Office
    2004 to play with, unfortunately.)

    It's still officially alphaware so the usual caveats apply (and if you
    do have any problems, report them and I'll sort it out asap), but the
    core functionality is done and I'm mostly just testing and polishing.
    It's based on the very mature, proven Python appscript bridge which is
    designed to mimic the way that AppleScript does things in order to
    provide the same level of compatibility with even the most quirky,
    buggy or downright bizarre scriptable applications.

    HTH, and if you've any queries about appscript just drop us a mail.

    has
    --
    http://appscript.sourceforge.net
    http://rb-appscript.rubyforge.org
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today