Can't find the info I need - any help out there???
Don Bruder
I've just spent the last two hours chasing what seems like a phantom -
How to handle an "odoc" event in my application.
I can find about 14 bazillion samples on *.apple.com for how to SEND an
odoc event (I don't want to SEND it, I want to RECEIVE and HANDLE it!),
I can find the unbelievable mess in MIB that tells me exactly NOTHING
useful about how to retrieve the file/list of files from the odoc event
(because they buried that part someplace deep in the guts of the MIB
code where I can't seem to find it, and only mention that they've
already torn apart the event prior to coming to the code that actually
handles the file that was passed), I can find several samples that use
an odoc event handler that consists of the comment "...but since we
don't have any files, we don't do anything here" (AUGH!!!! What good is
sample code that doesn't demonstrate how to deal with the topic it's
supposedly covering????), I can find references to "odoc" scattered
around in several places on *.apple.com, and within the help information
in the "developer" info that comes with Xcode, but none of them give me
the information I need. if there's such a thing as a plain old
non-obfuscated "This is what the parameter list that comes with the odoc
event contains, this is the name/type you need to hand to
GetEventParameter() in order to retrieve it, and this is what you get
back when you do", I can't find it.
Something this basic should be as easy to find as rain in Seattle, but
for whatever reason, I'm coming up blank - and frustrated. It's not like
I'm trying to do anything "fancy" - When the user drops a document (or
several of them) on my app, I want to open it and do things with it. The
simplest way to do so would seem to be catching the odoc event that the
Finder hands me when the program fires up. But once I go looking for how
to do that, I hit a brick wall.
Am I asking the wrong questions? Misunderstanding the answers when
they're right in front of me? Just plain screwing the pooch? Dunno. But
I'm at the point where I don't have any viable option but to beg for
help from the group, since I can't seem to accomplish the task on my own.
Thanks in advance for any assistance you can offer...
--
Don Bruder - dak...@sonic.net - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info
David Phillip Oster
Don Bruder <dak...@sonic.net> wrote:
> I've just spent the last two hours chasing what seems like a phantom -
> How to handle an "odoc" event in my application.
The Open dialog box, and the 'odoc' event both return an aeList of
aeDescriptors that represent file paths. ideally, you should write your
code so that you pass the aeList to a common handler.
If you are writing in Cocoa, the framework handles this for you. Create
a new project for a Cocoa document-based application, and look at the
comments in the generated MyDocument.m.
If you are writing in Carbon, well, here's some old code that coerces to
an FSSpec. Modern code would coerce to an FSRef.
Document based code would check to see if the file is already open in
this app, and bring that window to the front.
static OSErr DoOpenDocList(const AEDescList docList){
long index, itemsInList;
OSErr err;
Size actualSize;
AEKeyword keywd;
DescType typeCode;
FSSpec fss;
if(noErr != (err = AECountItems(&docList, &itemsInList))){
return err;
}
for(index = 1; index <= itemsInList; index++){
if(noErr != (err = AEGetNthPtr(&docList, index, typeFSS, &keywd,
&typeCode,
(Ptr)&fss, sizeof(FSSpec), &actualSize))){
break;
}
if(noErr != (err = FSProcessTheFile(&fss))){
break;
}
}
return err;
}
/* DoOpenDoc - we get called with a list of file specs as the direct
object.
for each file spec, run FSRot13 on it.
then quit.
*/
static pascal OSErr DoOpenDoc(const AppleEvent *message, AppleEvent *
/*reply*/, long /*refCon*/){
AEDescList docList;
OSErr err;
if((err = AEGetParamDesc(message, keyDirectObject, typeAEList,
&docList)) != noErr ||
(err = MissedAEParameters(message)) != noErr){
return err;
}
err = DoOpenDocList(docList);
AEDisposeDesc(&docList);
isDone = true;
return err;
}
static void InitAppleEventHandlers(void){
long response;
AEInstallEventHandler(kCoreEventClass, kAEOpenApplication,
NewAEEventHandlerProc(DoOpenApp), 0, false);
AEInstallEventHandler(kCoreEventClass, kAEOpenDocuments,
NewAEEventHandlerProc(DoOpenDoc), 0, false);
AEInstallEventHandler(kCoreEventClass, kAEPrintDocuments,
NewAEEventHandlerProc(DoPrintDoc), 0, false);
AEInstallEventHandler(kCoreEventClass, kAEQuitApplication,
NewAEEventHandlerProc(DoQuitApp), 0, false);
}
static void Init(){
InitCursor();
InitAppleEventHandlers();
SetMenuBar(GetNewMBar(128));
DrawMenuBar();
}
void main(){
EventRecord e;
Init();
while( ! isDone){
WaitNextEvent(everyEvent, &e, 10, nil);
GoEvent(&e);
}
}
David Phillip Oster
> I've just spent the last two hours chasing what seems like a phantom -
> How to handle an "odoc" event in my application.
oh: and your Info.plist has to specify what extensions or old-style
4-byte codes are legal for the Finder to drop on your app. And Xcode is
sloppy about noticing you've changed your Info.plist and copying it into
your app's bundle. Best to delete the app from your build folder and
make Xcode re-create it from scratch.
Don Bruder
With assistance from your other response (which pointed me to where I
needed to be looking - I was digging through the "Carbon Events" info,
rather than the "Apple Events" stuff, so I wasn't seeing what I needed.
One of those "can't see the forest 'cause of all the darn trees!"
moments...) I've figured out how to deal with the odoc event, and have
the handler written/installed and the app running in the debugger with
no sign of problems. Thanks much for that!
Now, however, I have a new problem, and it seems related to the issues
you raise in this message: I can't drag a document to the app and have
it do anything - trying to gets me a copy of the document sitting on top
of the app, rather than the app firing up and opening the document.
A brief overview of what I'm trying for and background on why:
For various reasons, as far as I'm concerned, there is currently no such
thing as an acceptable "HJ-split" utility for Mac OS X. All of them that
exist fall short of my expectations in one way or another, so I'm
attempting to cure the deficit I see. One of the biggest "sins" (in my
eyes) that all of them I've tried seem to commit is failing to accept a
drag of the Thisfilename.000" or "Thisfilename.001" file to fire up and
do their duty, without needing further human intervention - INCLUDING
finding all the rest of the pieces (Thisfilename.002, Thisfilename.003
... Thisfilename.nnn) when they're sitting in a folder next to the
Thisfilename.000 or Thisfilename.001 file.
My goal, at this point, is to get the app to accept a drag/drop of the
Thisfilename.000/Thisfilename.001 file, look in the directory where that
file lives for any other Thisfilename.nnn pieces, and proceed from there.
With those requirements, and your advice from above in mind, I've added
the following block of keys/values to the base Info.plist file that
Xcode generated for me as part of the "create a new project/Carbon
Application" process:
<key>CFBundleDocumentTypes</key>
<dict>
<key>CFBundleTypeExtensions</key>
<array>
<string>000</string>
<string>001</string>
</array>
<key>CFBundleTypeOSTypes</key>
<array>
<string>****</string>
</array>
<key>CFBundleTypeRole</key>
<string>Editor</string>
</dict>
<key>NSAppleScriptEnabled</key>
<string>YES</string>
<key>LSRequiresCarbon</key>
<string>1</string>
So, if I've done things the way seems to be required, I should be able
to get drag/drop launching of the app/opening of the dragged file(s) by
dropping any type of file, with any name, and an extension of either
".000" or ".001" on the app. But that's not what's happening... Dropping
a file just gets me a copy of the file sitting on top of the app's icon,
so I'm stuck. See anything obviously wrong with my plist entries?
Don Bruder
Don Bruder <dak...@sonic.net> wrote:
Found it... Operator error.
Specifically, I needed an "<array>" between the
"<key>CFBundleDocumentTypes</key>" and "<dict>" lines, and a
corresponding "</array> after the "</dict>" line. With those two lines
added, I'm now getting the proper behavior when I drag a file of any
type with an extension of ".000" or ".001" to the application icon. Now
that I can actually get the odoc event (and its payload), it's time for
the fun of *DOING SOMETHING* with it. Should be pretty simple, unless
there's some sort of unexpected complications involved.
David Phillip Oster
Don Bruder <dak...@sonic.net> wrote in his Info.plist file:
...
> > <string>Editor</string>
...
Shouldn't that be <string>Viewer</string> ? After all, you aren't
changing the input files.
Don Bruder
David Phillip Oster <os...@ieee.org> wrote:
Looking at the docs concerning Info.plist, it seemed to me like "Editor"
was more appropriate than "Viewer", since it's going to be processing
the data in the file(s) (even though the user won't see anything other
than a progress/status indication, and will have very little (if any)
direct control over the process), and when fully completed, it will also
be responsible for creating them.
Phase 1 is getting it to take the "pieces' files and put them together
into a single file. Phase 2 is going to involve having it accept a file
of arbitrary type whose extension *IS NOT* ".000" or ".001", and chop it
up into a user-configured sequence of output files.
I'm betting that before I'm done, I'll have to go with having it accept
*ALL* files as valid for dropping on it to start the process, then look
at them in the odoc handler to decide what needs to be done based on the
extension - as in "if extension of dropped file == ".000" or ".001",
goto "find the pieces and put 'em together" else goto "chop it into
pieces"