Sending an apple event from C (not iPhone)

Question

I'm trying to send an "open documents" event. It's giving me a -50 error (incorrect parameter) so I think it's in the aeDirDesc that gets added as the parameter, but I can't seem to find enough documentation to see what's wrong. Here's my code which is altered from a (working) chunk of code which tells finder to open an app.
Sorry about the large code fragment...
<pre>
OSErr errT;
OSType desc;
AEDesc progAddr, aeDirDesc;
char preview[PATHLEN];
uchar previewU[PATHLEN];
uchar doc[PATHLEN];
AppleEvent someAE;
FSSpec fspT, fspP;
AliasHandle DirAlias = NULL;
AEDesc fileList;
strcpy(preview,"file://Applications/Safari.app");
pstrcpy(previewU, "\pMacintosh HD:Applications:Safari.app");
pstrcpy(doc, "\pMacintosh HD:tmp:dockeepimages:Page-001");
errT = FSMakeFSSpec(0,0,doc, &fspT);
errT = FSMakeFSSpec(0,0,previewU, &fspP);
SendOpenToFinder(&fspP);
errT = NewAlias(nil, &fspT, &DirAlias);
HLock((Handle)DirAlias);
errT = AECreateDesc(typeAlias, (Ptr)*DirAlias,
GetHandleSize((Handle)DirAlias), &aeDirDesc);
HUnlock((Handle)DirAlias);
errT = AECreateDesc(typeApplicationURL, preview, strlen(preview) +1,
&progAddr);
if(errT == noErr)
errT = AECreateAppleEvent(kCoreEventClass, kAEOpenDocuments, &progAddr,
kAutoGenerateReturnID, kAnyTransactionID,
&someAE);
AEDisposeDesc(&progAddr);
if(errT == noErr)
errT = AEPutParamDesc(&someAE, keyDirectObject, &aeDirDesc);
AEDisposeDesc(&aeDirDesc);
if(errT == noErr)
if ((errT = AECreateList(nil, 0, false, &fileList)) == noErr) {
errT = AEPutDesc(&fileList, 0, &aeDirDesc);
AEDisposeDesc(&fileList);
if(errT == noErr)
errT= AESend(&someAE, 0, kAENoReplykAEAlwaysInteractkAECanSwitchLayer,
kAENormalPriority, kAEDefaultTimeout, 0, 0);
</pre>
There's no error until the AESend which gives a -50...

Answer 1

etresoft wrote:
I wouldn't mind use AppleEvents (not the same as Applescript!) via the Script bridge or something. However, I thoroughly detest Applescript.
The AppleScript language has one major defect: in order to provide high-level readability, it sacrifices low-level semantics. i.e. Even a complete non-programmer can look at an existing AppleScript script and get a general idea of what it does, but actually figuring out the precise mechanics of how it works requires a load of effort by newbies and expert programmers alike. "English-like" syntax is all well and good, but without all those ugly brackets and braces, it can be a real PITA figuring out what's a variable name, what's a property name, what's a command, and so on. You can't tell from syntax alone as all the different structures look exactly the same - it's hopelessly ambiguous. Allowing whitespace in application-defined keywords also makes it tricky to tell where each keyword begins and ends. e.g. Is 'foo bar' a property name, or a constant name, or a command name, or a command name followed by a property name, something else? (One tip for you: in Script Editor's preferences, set the 'application keyword' style to use underlines.)
(AppleScript also has a whole bunch of lesser defects, of course... but hey, find me a language that doesn't. Come to think of it, even Apple events themselves are a bit wonky; and don't get me started on the mess that is the Apple Event Object Model or the Cocoa Scripting framework.)
OTOH, I will say two things in the AppleScript language's defense:
1. AppleScript frequently gets blamed for the bugs, inconsistencies, appallingly inadequate documentation and other defects of individual applications' scripting interfaces. This is not AppleScript's fault, however; it's the developers who wrote those applications who are to blame - and their failings affect all Apple event-capable languages, not just AppleScript.
2. It still has the best Apple event support of any language. Scripting Bridge, which you mention, doesn't work properly (various bugs, lacks various bits of functionality, and is prone to application incompatibilities), and [ironically] obfuscates and confuses the process of building and sending Apple events much worse than AppleScript does. Even appscript, which [AFAIK] provides the next best Apple event bridge after AppleScript, still chokes on the occasional application command that works without problem in AppleScript. (Of course, some of those compatibility problems are due to applications relying on behaviours that in turn rely on AppleScript's own undocumented quirks; but hey, you work with the APIs you've got, not the ones you wish you had.)
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net