Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Q] NavServices, Open FilterProc, Mounting UI

On 8/29/03 12:27 PM, Eric Gorr didst favor us with:

> I've got what I believe is a pretty normal filter proc which I pass
> to NavCreateGetFileDialog.
>
> Now, the problem that I am seeking a solution for is it is quite
> annoying if several files come along which are aliases to things that
> need to bring up a UI to be accessed.
>
> The behavior I would like to see is for an alias of this type to be
> lit, but for the UI to only appear when the user selects the item.
>
> Now, when considering only aliases to server volumes, I can achieve
> this behavior by detecting it is an alias and then looking at
> filetype field in LSItemInfoRecord and checking it against
> kContainerServerAliasType. In this case, I can simply bypass the call
> to FSResolveAliasFile and return true.
>
> However, I do not believe that the kContainerServerAliasType is the
> only type that may need to bring up a UI to be mounted, nor do I know
> if checking the filetype field will continue to work in the future
> (will it?).
>
> Assuming that I discover all of the AliasTypes that may need to bring
> up a UI, it would only be valid until such a time as a new type would
> be added.
>
> So, my basic questions are...
>
> Is there something here I am missing?
>
> I noticed that
> FSResolveAliasFileWithMountFlags( ..., kResolveAliasFileNoUI )
> will return -35. Is this a reliable thing to check against to know
> that I have something that can be lit, but could not be mounted? If
> this is the case, it would seem to be a solution to my problem.

You don't state your requirements for what it means to quality as "something
that can be lit" or what it means to be lit (though I assume you mean
selectable). But logically speaking, aliases have to point to one of three
things:

- Existing objects on currently mounted volumes. These aliases should
resolve with noErr.

- Objects which *were* on on currently mounted volumes, but no longer exist.
FSResolveAliasFileWithMountFlags will return fnfErr or dirNFErr for these.

- Existing objects on volumes not currently mounted. These aliases should
return nsvErr when passed to FSResolveAliasFileWithMountFlags. Note that you
can also get afpNoServer as a result, which means the server is not
responding or not available.

So basically there seem to be five possible error codes with which you
should concern yourself:

- noErr is the only one which means the target is currently available.

- nsvErr and afpNoServer mean the volume containing the target is not
available. The original target may or may not still exists.

- fnfErr or dirNFErr mean the target no longer exists.

Larry
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.
References: 
 >[Q] NavServices, Open FilterProc, Mounting UI (From: "Eric Gorr" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.