Thanks. After much digging around, I realized that the standard suite
was not getting included in the sdef. It looks like that kept the sdp
tool from generating anything at all.
Of course, had sdp generated *some* sort of error message, I would
have been saved hours of effort trying to understand the tool and what
does and does not work.
sdp seems pretty "fragile" as it fails against the current iTunes.app
(but actually DOES give me an unknown type name "tdta" error). It
seems to choke on:
which I believe I got from one of Apple's samples.
And gives virtually no errors so you can make use of the tool and when
does, the errors are so cryptic to not be useful. It's a very
frustrating experience.
I'll take a look at appscript and see if it can meet my specific
needs. It is sad because SB offers a lot of promise but because the
developer tools still aren't ready for prime time, it's probably
significantly underutilized.
I guess it's time to write up some more bugs, although *that* too is
becoming an exercise in futility as so many get marked dupe. Really
need some kind of "me too" that would be quicker than the current
approach.
Mark Munz
On Fri, Feb 20, 2009 at 10:31 AM, has wrote:
> Mark Munz wrote:
>
>> I'm not getting any useful results when I try to generate Scripting
>> Bridge headers.
>> [...]
>> The sdef file seems to be valid enough to allow me to actually script
>> the application via AppleScript w/o issue.
>>
>> Anyone else run into this type of problem? Or how to get some
>> indication as to the source of the problem that sdp is having with the
>> sdef file?
>
>
> Can't really comment on your own particular problem without seeing the
> sdef/sdp commands you're running, though as a general point sdef, sdp and
> Scripting Bridge are all prone to various compatibility problems (some
> caused by bugs, some due to their design) with applications that work fine
> from AppleScript. I've previously found sdp to produce buggy headers for
> Word and Excel headers, and fail completely on InDesign, and it's pretty
> much guaranteed to produce flawed headers for any application whose
> dictionary isn't 100% perfectly formed. By comparison, AppleScript is very
> forgiving of dictionary imperfections, and that and the lack of formal
> validation tools from Apple mean that minor flaws are not common in
> application dictionaries as they don't show up when tested against
> AppleScript.
>
> You might also want to take a look at objc-appscript (see my sig). Unlike
> SB, appscript's behaviour is much closer to that of native Apple events and
> AppleScript and tries to be "quirk-for-quirk compatible" as much as
> possible. While it's still not completely immune to compatibility issues
> with some particularly funky applications, problems are pretty rare these
> days and there are generally compatibility options and other ways of working
> around them when they do occur. You also get feature parity with AppleScript
> plus extra benefits such as being able to send events on background threads,
> better tool support and documentation (ASTranslate is particularly useful
> when you're starting out), and an API that doesn't obfuscate everything it
> does.
>
> HTH
>
> has
> --
> Control AppleScriptable applications from Python, Ruby and ObjC:
> http://appscript.sourceforge.net
>
>
--
Mark Munz
unmarked software
http://www.unmarked.com/
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
