> From: Chris Nandor mailto:pudge@pobox.com http://pudge.net/ >>I don't know how you would supply a $typeList NULL value so that a >>FILTERPROC could be used, independent of application signature AND not >>create the dialog problems mention above, perhaps this is related to the >>bug(s) you mention above. > > Well, with NavGetFile, the filterproc only gets the items that pass the > typelist check. If you want any file of any type to show up, use > NavChooseObject, which does not specify file types. > > There might be another way ... I suspect the Nav Services docs would have > it if there is. I think your "bless({}, 'NavTypeListHandle')" parameter is on the right track (it does show all TEXT files, independent of application) except for the dialog box anamolies that I mentioned, which may be a bug, or perhaps there is another way...I will experiment, and check the docs again. >>A few questions: >> >>1) I assume that you must supply an event handling procedure to get the >>window title bar to display. Is this correct? > > I don't know. Well I gues I'll try and dive right in and figure out how to write an EVENTPROC and see what happens :|). > >>2) I wanted to pull the filter procedure outside the NavGetFile call, but >>when I did (defining it before the call), I get the following error: >> >> # Can't call method "fileInfo" without a package or object reference. >> >>Since it I thought that Mac:: packages exported their types and functions, >>this was a surprise error. I tried adding Mac::Navigation::, but got the >>same error. Should it be possible to define the FILTERPROC subroutine >>outside the NavGetFile function? > > Did you use Mac::Files? If so, I don't know what the problem would be. > That's where the fileInfo structure is from. Yes, this is why I found the error so bizarre. Basically, I did this: $nav = NavGetFile($default, $options, bless({}, 'NavTypeListHandle'), 0, 0, filterProc()); sub filterProc() { return unless (my $ft = $_[1]->fileInfo->finderInfo->fdType); return 1 if ($_[1]->isFolder()); foreach my $type (@types) {return 1 if $ft eq $type} return; } and got the error, perhaps it is a bug somewhere. By the way, is the "return unless" test necessary? I can't see $ft ever being ''. > >>3) I have discovered that the second element ($_[2]) passed by NavGetFile to >>the FILTERPROC appears to be the filterMode variable (NavFilterModes type), >>which is "...a list of objects currently being filtered." How would one use >>this, as it appears that it is not necessary for one to check that the >>Browser list (kNavFilteringBrowserList = 0) is currently being filtered >>before the filter is applied? > > I don't know. I didn't use it for anything, and didn't find it necessary. > Though if you find a need for it, I am sure we can figure out how to use > it. :) An error on my part, since I forgot that arrays are indexed from 0, I meant the third element, which is a parameter whose purpose I don't understand, callBackUD. The forth parameter passed should be the filterMode, but interestingly, if I check the size of @_ passed to the filter function, and print its contents I get: # of elements in @_ is 2 $_[0] = AEDesc=SCALAR(0x88793f8) $_[1] = NavFileOrFolderInfo=SCALAR(0x8879530) $_[2] = 0 $_[3] = $_[4] = which points up some inconsistencies, strange. If I can think of a need knowing the filterMode variable, I'll get back to you. There must be something interesting and/or useful you can do with the Shortcuts, Favorites and Recent buttons. Mark ---------------------- Mark J. Yannuzzi myannuzzi@aya.yale.edu ===== Want to unsubscribe from this list? ===== Send mail with body "unsubscribe" to macperl-request@macperl.org