'kASAppleScriptSuite' undeclared

  • Hi Folks,

    I want to perform some script calls from my cocoa app.

    So started AppleScript with this link

    http://developer.apple.com/technotes/tn2006/tn2084.html#TNTAG8

    tried this one for passing parameters from myApp

    "Listing 2: Using NSAppleScript with a script inside the app's bundle."

    but got two 3 errors

    error: 'kASAppleScriptSuite' undeclared (first use in this function)
    error: 'kASSubroutineEvent' undeclared (first use in this function)
    error: 'keyASSubroutineName' undeclared (first use in this function)

    How about the declerations??

    Tom.
  • If you search these terms in Spotlight, you'll see that they're
    defined in ASRegistry.h, intself in the OpenScripting framework,
    which in turn is in the Carbon framework.
    Therefore you should have forgotten to inlude a framework or a header
    defining it.

    Regards.

    On Sep 28, 2007, at 8:21 AM, Aby wrote:

    > kASAppleScriptSuite
  • On Sep 28, 2007, at 2:21 AM, Aby wrote:

    > Hi Folks,
    >
    > I want to perform some script calls from my cocoa app.
    >
    > So started AppleScript with this link
    >
    > http://developer.apple.com/technotes/tn2006/tn2084.html#TNTAG8
    >
    > tried this one for passing parameters from myApp
    >
    > "Listing 2: Using NSAppleScript with a script inside the app's
    > bundle."
    >
    > but got two 3 errors
    >
    > error: 'kASAppleScriptSuite' undeclared (first use in this function)
    > error: 'kASSubroutineEvent' undeclared (first use in this function)
    > error: 'keyASSubroutineName' undeclared (first use in this function)
    >
    > How about the declerations??

    As another response said, there is a missing header to import. I was
    in your same boat and didn't know what header to import so I use this
    code which I found on some sample code on the internet. I can't speak
    to its correctness since I'm pretty inexperienced, but it does work
    for me:

    #ifndef kASAppleScriptSuite
    #define kASAppleScriptSuite 'ascr'
    #endif

    #ifndef kASSubroutineEvent
    #define kASSubroutineEvent 'psbr'
    #endif

    #ifndef keyASSubroutineName
    #define keyASSubroutineName 'snam'
    #endif
  • On Fri, 28 Sep 2007 08:21:42 -0400, Paul Bruneau
    <paul_bruneau...> said:
    > On Sep 28, 2007, at 2:21 AM, Aby wrote:
    >
    >> Hi Folks,
    >>
    >> I want to perform some script calls from my cocoa app.
    >>
    >> So started AppleScript with this link
    >>
    >> http://developer.apple.com/technotes/tn2006/tn2084.html#TNTAG8
    >>
    >> tried this one for passing parameters from myApp
    >>
    >> "Listing 2: Using NSAppleScript with a script inside the app's
    >> bundle."
    >>
    >> but got two 3 errors
    >>
    >> error: 'kASAppleScriptSuite' undeclared (first use in this function)
    >> error: 'kASSubroutineEvent' undeclared (first use in this function)
    >> error: 'keyASSubroutineName' undeclared (first use in this function)
    >>
    >> How about the declerations??
    >
    > As another response said, there is a missing header to import. I was
    > in your same boat and didn't know what header to import so I use this
    > code which I found on some sample code on the internet. I can't speak
    > to its correctness since I'm pretty inexperienced, but it does work
    > for me:
    >
    > #ifndef kASAppleScriptSuite
    > #define kASAppleScriptSuite 'ascr'
    > #endif
    >
    > #ifndef kASSubroutineEvent
    > #define kASSubroutineEvent 'psbr'
    > #endif
    >
    > #ifndef keyASSubroutineName
    > #define keyASSubroutineName 'snam'
    > #endif

    Why not just link against Carbon?

    m.
    --
    matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    A fool + a tool + an autorelease pool = cool!
    One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
    AppleScript: the Definitive Guide - Second Edition!
    <http://www.amazon.com/gp/product/0596102119>
  • On Sep 30, 2007, at 4:07 PM, Matt Neuburg wrote:

    > Why not just link against Carbon?

    Because those lines solved my problem, and I didn't need any other
    parts of Carbon, and besides I didn't know that linking against
    Carbon would solve it, and finally, I don't know how to link against
    Carbon.
  • On Sep 30, 2007, at 1:35 PM, Paul Bruneau wrote:

    > On Sep 30, 2007, at 4:07 PM, Matt Neuburg wrote:
    >
    >> Why not just link against Carbon?
    >
    > Because those lines solved my problem, and I didn't need any other
    > parts of Carbon, and besides I didn't know that linking against
    > Carbon would solve it, and finally, I don't know how to link
    > against Carbon.

    Typically, if you don't know how to do something, you'll get better
    results if you ask instead of just trying things until something
    seems to work ;)
  • On 30 Sep 2007, at 21:35, Paul Bruneau wrote:

    > On Sep 30, 2007, at 4:07 PM, Matt Neuburg wrote:
    >
    >> Why not just link against Carbon?
    >
    > Because those lines solved my problem, and I didn't need any other
    > parts of Carbon, and besides I didn't know that linking against
    > Carbon would solve it, and finally, I don't know how to link
    > against Carbon.

    FYI, you wanted

      #include <Carbon/Carbon.h>

    and to add Carbon.framework to your project (and to any targets that
    need to link with it).

    Actually, to get the constants you mention, since they're #defines,
    there's no need to link with Carbon... you just need to include its
    headers.  But that might not be true in general---in particular,
    there are many constants now that are defined as e.g. "extern
    NSString *", and you do need to link to get those.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Sep 30, 2007, at 8:16 PM, John Stiles wrote:

    > On Sep 30, 2007, at 1:35 PM, Paul Bruneau wrote:
    >
    >> On Sep 30, 2007, at 4:07 PM, Matt Neuburg wrote:
    >>
    >>> Why not just link against Carbon?
    >>
    >> Because those lines solved my problem, and I didn't need any other
    >> parts of Carbon, and besides I didn't know that linking against
    >> Carbon would solve it, and finally, I don't know how to link
    >> against Carbon.
    >
    > Typically, if you don't know how to do something, you'll get better
    > results if you ask instead of just trying things until something
    > seems to work ;)

    Well I asked Google and found that simple code and it worked, so in
    that case I don't bother the list :)

    But OK here's a question: Why aren't these important Applescript
    constants defined in Cocoa?
  • On 01/10/2007, Paul Bruneau <paul_bruneau...> wrote:
    > On Sep 30, 2007, at 8:16 PM, John Stiles wrote:
    >
    >> On Sep 30, 2007, at 1:35 PM, Paul Bruneau wrote:
    >>
    >>> On Sep 30, 2007, at 4:07 PM, Matt Neuburg wrote:
    >>>
    >>>> Why not just link against Carbon?
    >>>
    >>> Because those lines solved my problem, and I didn't need any other
    >>> parts of Carbon, and besides I didn't know that linking against
    >>> Carbon would solve it, and finally, I don't know how to link
    >>> against Carbon.
    >>
    >> Typically, if you don't know how to do something, you'll get better
    >> results if you ask instead of just trying things until something
    >> seems to work ;)
    >
    > Well I asked Google and found that simple code and it worked, so in
    > that case I don't bother the list :)
    >
    > But OK here's a question: Why aren't these important Applescript
    > constants defined in Cocoa?

    Because they're defined in Carbon? Not everything is defined in Cocoa.
    There are lots of other frameworks in OS X. If you need to use stuff
    in the headers, #include them. It's really very straightforward.

    -- Finlay
  • On Sun, 30 Sep 2007 16:35:48 -0400, Paul Bruneau
    <paul_bruneau...> said:
    > On Sep 30, 2007, at 4:07 PM, Matt Neuburg wrote:
    >
    >> Why not just link against Carbon?
    >
    > Because those lines solved my problem, and I didn't need any other
    > parts of Carbon, and besides I didn't know that linking against
    > Carbon would solve it, and finally, I don't know how to link against
    > Carbon.

    My question was what we call "rhetorical". I was not literally asking *you*
    why *you* didn't do it. I was suggesting politely (to you and to those that
    I thought were giving you rather peculiar advice) that it might be a better
    way. I was *inviting* you to consider linking against Carbon instead. A more
    brusque alternative might have been to say "It's better and more proper just
    to link against Carbon", but I was trying to be polite.

    The method that you used is actually quite dangerous, especially when using
    AppleScript; many of those literal four-character codes such as 'ascr' can
    turn out to be incorrect on an Intel machine (though I do not know whether
    that one, in particular, would turn out to be so). Linking to Carbon and
    using the global name of the constant is the Right Way, and solves that
    problem. m.

    --
    matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    A fool + a tool + an autorelease pool = cool!
    One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
    AppleScript: the Definitive Guide - Second Edition!
    <http://www.amazon.com/gp/product/0596102119>
  • On Oct 2, 2007, at 1:29 PM, Matt Neuburg wrote:

    > The method that you used is actually quite dangerous, especially
    > when using
    > AppleScript; many of those literal four-character codes such as
    > 'ascr' can
    > turn out to be incorrect on an Intel machine (though I do not know
    > whether
    > that one, in particular, would turn out to be so). Linking to
    > Carbon and
    > using the global name of the constant is the Right Way, and solves
    > that
    > problem.

    Importing the header is the right thing to do, but I think what he
    did was safe.

    In this case, linking is unnecessary because it's a compile-time
    constant, not a global variable. Apple cannot change
    kASAppleScriptSuite to a different four-char code without breaking
    every app that uses it.

    Four-char codes don't have endian problems so long as you treat them
    as numbers.

    --Michael
  • On Tue, 2 Oct 2007 15:08:24 -0400, Michael Tsai <lists...> said:
    > Four-char codes don't have endian problems so long as you treat them
    > as numbers.

    You might be using the phrase "treat them as numbers" in some way that is
    unknown to me. I can certainly attest from experience that code that treats
    four-char codes as four-char codes (i.e. a literal in single-quotes) can
    have endian problems. m.

    --
    matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
    A fool + a tool + an autorelease pool = cool!
    One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
    AppleScript: the Definitive Guide - Second Edition!
    <http://www.amazon.com/gp/product/0596102119>
  • On Oct 3, 2007, at 11:27 AM, Matt Neuburg wrote:

    >> Four-char codes don't have endian problems so long as you treat them
    >> as numbers.
    >
    > You might be using the phrase "treat them as numbers" in some way
    > that is
    > unknown to me. I can certainly attest from experience that code
    > that treats
    > four-char codes as four-char codes (i.e. a literal in single-
    > quotes) can
    > have endian problems.

    A four-char code literal is just another way to type an integer, like
    using hex notation. You can type it in your code, assign it to a
    variable, pass it as a parameter, etc. The endianness only matters if
    you try to treat it as something other than a number, e.g. if you
    stuff it into a char[] or NSData. And in those cases the issues would
    be the same whether you used kASAppleScriptSuite or 'ascr'--or, for
    that matter, NSMacOSRomanStringEncoding or 30.

    --Michael
  • On or about 10/3/07 8:51 AM, thus spake "Michael Tsai" <lists...>:

    > On Oct 3, 2007, at 11:27 AM, Matt Neuburg wrote:
    >
    >>> Four-char codes don't have endian problems so long as you treat them
    >>> as numbers.
    >>
    >> You might be using the phrase "treat them as numbers" in some way
    >> that is
    >> unknown to me. I can certainly attest from experience that code
    >> that treats
    >> four-char codes as four-char codes (i.e. a literal in single-
    >> quotes) can
    >> have endian problems.
    >
    > A four-char code literal is just another way to type an integer, like
    > using hex notation. You can type it in your code, assign it to a
    > variable, pass it as a parameter, etc. The endianness only matters if
    > you try to treat it as something other than a number, e.g. if you
    > stuff it into a char[] or NSData. And in those cases the issues would
    > be the same whether you used kASAppleScriptSuite or 'ascr'--or, for
    > that matter, NSMacOSRomanStringEncoding or 30.

    That is certainly true! I'm just saying that this is a trap lying in wait.
    Something that worked under the Old Regime might break on an Intel machine.
    Just to give an example close to my heart, the entirety of the Apple
    event-related code for Frontier (about which I once wrote a book,
    http://pages.sbcglobal.net/mattneub/frontierDef/ch00.html) lies broken and
    panting on the ground, if you try to run the universal binary as a native
    Intel app on an Intel machine. (Of course you can work around this by
    running it under Rosetta.)

    <http://sourceforge.net/tracker/index.php?func=detail&aid=1804842&gr
    oup_id=1
    20666&atid=687798
    >

    m.

    --
    matt neuburg, phd = <matt...>, http://www.tidbits.com/matt/
    pantes anthropoi tou eidenai oregontai phusei
    Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
    AppleScript: the Definitive Guide, http://tinyurl.com/2ouo3b
    Take Control of Customizing Tiger, http://tinyurl.com/33ad5s
    TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
  • On Oct 3, 2007, at 11:21 AM, Matt Neuburg wrote:

    > Just to give an example close to my heart, the entirety of the Apple
    > event-related code for Frontier (about which I once wrote a book,
    > http://pages.sbcglobal.net/mattneub/frontierDef/ch00.html) lies
    > broken and
    > panting on the ground, if you try to run the universal binary as a
    > native
    > Intel app on an Intel machine. (Of course you can work around this by
    > running it under Rosetta.)

    Matt:

    This thread was something I was watching and came to the same
    conclusion, but now I might have the tools to try to fix it.  The old
    Radio UserLand executable is part of the Frontier open source and I'd
    like to fix it for nostalgia's sake.

    Is there a Cocoa programmer on the list that would like to take a
    shot?  Contact me off list.

    Steve Kirks
    http://houseofwarwick.com/
    <warwick...>
    AIM/iChat: <srk...>
previous month september 2007 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
Go to today