loading custom and standard file types

[frac707]

I am having trouble defining a NavTypeList for a Carbon Open dialog (OSX). I'd like to be able to screen out all files in the open-file requester except the file types my application supports. (Right now I'm passing a NULL list to NavCreateGetFileDialog which allows everything to be displayed.) I can't find any information on how to make a 'dynamic' NavTypeList. The list would contain custom file types and/or file types that have an extension other than four characters, such as 'QFRM' (custom type) or 'PNG' (standard picture type). It doesn't seem to work to use an 'open' resource created with Resorcerer (which requires all file types to be four characters long and either TEXT or PICT). I'd rather create the type list 'on the fly' since there will be more than one kind of open-file requester in my app.

Can someone point me in the right direction?

Thanks for any help on this.

[OneSadCookie]

I can offer the helpful suggestion that this is dead easy in Cocoa :D

file:///Developer/ADC%20Reference%20Library/documentation/Carbon/Conceptual/ProvidingNavigationDialogs/nsx_tasks/chapter_3_section_5.html#//apple_ref/doc/uid/TP30001147-CH203-BEIBEAHH

[frac707]

It's quite easy in Windows too. Unfortunately my application is already built with Carbon and CodeWarrior. I have no experience with Cocoa.

[OneSadCookie]

follow my link.

[frac707]

Thanks. Using a callback filter (see below) I can screen out everything but text files. But I would like to make this more specific, since my application will be loading two different text files. So how do you distinguish one text file from another (using the callback filter), e.g. one type with an extension of 'tex1' and one with 'tex2'? I guess the question should really be: How do you register different text types with the Finder?


unsigned pascal char myFilterProc(AEDesc *theItem, void *info,void *callbackUD,NavFilterModes FilterMode)
{
OSErr theErr=noErr;
Boolean display=true;
NavFileOrFolderInfo *theInfo;

theInfo=(NavFileOrFolderInfo *) info;
if(!theInfo->isFolder)
if(theInfo->fileAndFolder.fileInfo.finderInfo.fdType!='TEXT')
display=false;
return display;
}

[OneSadCookie]

the link shows you how.

[frac707]

The link has a UTI example, but it doesn't compile in Codewarrior (unknown identifiers). I've tried looking up the unknown variables, but there are no references to them. UTI is so broad a topic that nothing readily appears in regards to Macintosh OSX. So it looks like I need to study the Developer's Finder reference in depth to find a solution to this, since no one appears to have a quick answer for the implementation in Carbon. I can see why people are switching to Cocoa if Apple has made Carbon so inscrutable...

[OneSadCookie]

carbon has always been inscrutable ;)

are you trying to build a CFM application or something? It should work for a Mach-O app...

[frac707]

No, just the odious (to some) MSL, which is as close to MSVC++ as I can find on Codewarrior and Mac. Hard enough to translate my work from Windows without having to rebuild everything, including the core routines. With Carbon I only have to reconstruct the user interface. The majority of my C++ code is easily compiled with Codewarrior, including the PNG library. But the Finder is another thing altogether. Establishing default directories and getting complete control over the file requesters, I still have to learn. The process of creating Quicktime movies turned out not any harder than making AVI movies, though the previewing of Quicktime files seems a lot more complex. Everything looks hard until you have an example that shows you how. Thanks for the thread.

[wadesworld]

The example gives you what you need to know.

The file is described in the AEDesc that's passed in. From that, you can get an FSRef. From that, you can get any information you want about the file using file system calls.

So, if you find out the extension is "tex1" you'd return true since you want to display that type of file.

Ignore all the UTI stuff in Apple's example. It's not really useful until Tiger since there's currently like only 3 UTI's defined.

Wade

[frac707]

After a good night's sleep, I arrived at the same conclusion as your last post (before reading it.) The UTI code was irrelevant. All that was needed was to examine the file extension using LSCopyItemInfoForRef(), and screen out any files that didn't match my app's file type. :)