[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Using Mac:: '...' Modules



> 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