Handling "Open Document" (odoc) events in Snow Leopard

Question

I have code in my application that response to "Open Document" (odoc) events. In Mac OS X Tiger and Leopard, this code works fine:

- (void) handleOpenDocumentEvent:
    (NSAppleEventDescriptor*)event
    withReplyEvent:(NSAppleEventDescriptor*)replyEvent
{
    NSAppleEventDescriptor const *const dirObj =
        [event descriptorForKeyword:keyDirectObject];
    DescType const dirObjType = [dirObj descriptorType];

    if ( dirObjType == 'alis' ) {
        //
        // Open a single file.
        //
        NSData const *const data = [dirObj data];
        AliasHandle const fileHandle =
            reinterpret_cast<AliasHandle>( ::NewHandle( [data length] ) );
        if ( fileHandle ) {
            [data getBytes:*fileHandle];
            err = [self queueFile:fileHandle fromSender:senderSig];
        }
    } else if ( dirObjType == 'list' ) {
        //
        // Open multiple files.
        //
        AliasHandle fileHandle =
            reinterpret_cast<AliasHandle>( ::NewHandle( 0 ) );
        if ( fileHandle ) {
            int const numItems = [dirObj numberOfItems];
            for ( int i = 1; i <= numItems; ++i ) {
                NSData const *const data = [[dirObj descriptorAtIndex:i] data];
                ::SetHandleSize( reinterpret_cast<Handle>( fileHandle ), [data length] );
                if ( (err = ::MemError()) != noErr )
                    break;
                [data getBytes:*fileHandle];
                err = [self queueFile:fileHandle fromSender:senderSig];
                if ( err != noErr )
                    break;
            }
        }
    }
}

Under Mac OS X Snow Leopard, however, this code doesn't work. Here is a dump of an AppleEvent from a Leopard system:

{ 1 } 'aevt':  aevt/odoc (i386){
          return id: 1012269061 (0x3c560005)
     transaction id: 0 (0x0)
  interaction level: 112 (0x70)
     reply required: 0 (0x0)
             remote: 0 (0x0)
      for recording: 0 (0x0)
         reply port: 150031 (0x24a0f)
  target:
    { 1 } 'psn ':  8 bytes {
      { 0x0, 0x655655 } (iPhoto)
    }
  fEventSourcePSN: { 0x0,0x655655 } (iPhoto)
  optional attributes:
    < empty record >
  event data:
    { 1 } 'aevt':  - 1 items {
      key '----' -
        { 1 } 'list':  - 1 elements {
          { 1 } 'alis':  326 bytes {
            /Users/pjl/Pictures/IMG_8501.JPG
          }
        }
    }
}

Here is a dump of an AppleEvent from a Snow Leopard system:

{ 1 } 'aevt':  aevt/odoc (i386){
          return id: 5173 (0x1435)
     transaction id: 0 (0x0)
  interaction level: 112 (0x70)
     reply required: 0 (0x0)
             remote: 0 (0x0)
      for recording: 0 (0x0)
         reply port: 81695 (0x13f1f)
  target:
    { 1 } 'psn ':  8 bytes {
      { 0x0, 0x17c17c } (iPhoto)
    }
  fEventSourcePSN: { 0x0,0x17c17c } (iPhoto)
  optional attributes:
    < empty record >
  event data:
    { 1 } 'aevt':  - 1 items {
      key '----' - 
        { 1 } 'list':  - 1 elements {
          { 1 } 'bmrk':  944 bytes {
                  000: 626f 6f6b  b003 0000  0000 0110  1000 0000     book............
                  001: c002 0000  0500 0000  0101 0000  5573 6572     ............User
                  002: 7300 0000  0300 0000  0101 0000  706a 6c00     s...........pjl.
                  003: 0800 0000  0101 0000  5069 6374  7572 6573     ........Pictures
                  004: 0e00 0000  0101 0000  6950 686f  746f 204c     ........iPhoto L
                  005: 6962 7261  7279 0000  0800 0000  0101 0000     ibrary..........
                  006: 4d6f 6469  6669 6564  0400 0000  0101 0000     Modified........
                  007: 3230 3037  0b00 0000  0101 0000  4a75 6e20     2007........Jun 
                  008: 392c 2032  3030 3700  0c00 0000  0101 0000     9, 2007.........
                  009: 494d 475f  3633 3837  2e6a 7067  2000 0000     IMG_6387.jpg ...
                  ....
                  058: 0000 0000  30f0 0000  3002 0000  0000 0000     ....0...0.......
          }
        }
    }
}

The 'alis' type has been replaced by the new Snow Leopard "bookmark" type. How can I modify this code so that it:

a) tests for and handles the new 'bmrk' type, i.e., get the absolute path of the file
b) continues to work on Tiger and Leopard

?

Or is the some way I can tell the OS that I still want odoc events that contain 'alis' structures?

Answer 1

The "bookmark data" included here can be handled using some new CFURL and/or NSURL APIs that were introduced in Snow Leopard. +[NSURL URLByResolvingBookmarkData:options:relativeToURL:bookmarkDataIsStale:error] is the NSURL API you can use to resolve the bookmark data included in the event descriptor.

You may also be able to coerce the descriptor to an alias using the coerceToDescriptorType: method and handle it that way, thought it's not documented whether or not Snow Leopard includes a built-in coercion handler for this (it sure seems like it should though).

As for Tiger/Leopard compatibility, you'll never be passed bookmark data on either of those systems, so calling the new NSURL method(s) shouldn't be a problem, since that code path will never be followed on the older systems.

BTW, the header file "AEDataModel.h" contains symbolic constants for the four char codes you're using, so you can use typeAlias instead of 'alis', typeBookmark instead of 'bmrk', and so forth. That tends to make the code a little more readable and lets the compiler protect you against typos and such.