I've a problem where sdp does only generate an empty header file for
an intact sdef (validated XML, works fine with AppleScript).
Running a
cat RemoteBuddy.sdef | sdp -fh --basename "RemoteBuddy"
will give me an empty RemoteBuddy.h (both attached).
Any help or insight into why I get not a single line of usable code
is very much appreciated.
sdp -fh and Scripting Bridge in general make all sorts of unwarranted
assumptions about how applications should work instead of paying
attention to how they _do_ work and supporting them accordingly. (See
various other discussions past, present and no doubt yet to come
regarding some of SB's other entertaining shortcomings.)
Therefore, I'm guessing that sdp assumes application dictionaries will
always include an 'application' class, which Script Buddy's doesn't.
Not defining an 'application' class is entirely legitimate, btw, and
is perfectly reasonable in applications that only need to provide a
procedural Apple event API. This is a pretty basic mistake to make and
I'm rather surprised that sdp's author didn't realise that this was a
possibility and have sdp insert a default 'application' class
automatically when one isn't found in the sdef.
Anyway, you might want to file a bug report on sdp, and in the
meantime, I expect you can work around the problem by inserting your
own 'application' class entry into the exported sdef before passing it
to sdp.
Alternatively, you could use appscript instead, which unlike Scripting
Bridge is deliberately designed to mimic the way the AppleScript and
the Apple Event Manager operate in order to provide a full range of
Apple event functionality and a level of real-world application
compatibility that's as close to AppleScript's as possible. While the
ObjC version isn't even finished yet, because its design is based on
the very mature, proven Python appscript bridge it's already very
usable and rather more polished looking than Scripting Bridge is. See:
