On Jun 1, 2015, at 13:59 , Lee Ann Rucker <lruc...@vmware.com> wrote: > > Because I couldn’t possibly be the only person using that …
What does that dangling “because” refer to? I can’t make it out. > for a non-URL path. What’s a non-URL path? AFAIK a URL** always contains a path, even if only relative, and even if surrounded by other stuff. > Even if I could URL-ify my data, … If you look at the header file for NSPathControlItem, it has a URL property that appears to URL-ify the path in spite of your data. > I still need to tweak the icons to match it. There are actually 3 cases, I think: 1. The control’s URL is not a file URL. 2. The control’s URL is a file URL for a file that exists. 3. The control’s URL is a file URL for a file that doesn’t exist. Doesn’t NSPathControl do some special things in case #3, for things like the user’s home folder etc? Does this mess you up in cases where your fake path happens to match the real path to an actual file? Sorry if I sound nit-picky here. That’s not my intention. I’m actually interested in your success at using NSPathControl for an arbitrary non-file-system path, since I came to the conclusion a couple of years ago that it was too unreliable an approach. I’m wondering if it’s now/again a valid use case. ** And I mean “URL”, not “NSURL”, though I guess the same thing applies to NSURL as a consequence. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
