0

So I had it working, then I tweaked something re: doc controller - subclassed as

class DocumentController : NSDocumentController {
    override func typeForContents(of url: URL) throws -> String {
        return "Document"
    }
}

and a URL helper to resolve .webloc files:

extension URL {
var webloc : URL? {
    get {
        do {
            let data = try Data.init(contentsOf: self) as Data
            let dict = try! PropertyListSerialization.propertyList(from:data, options: [], format: nil) as! [String:Any]
            let urlString = dict["URL"] as! String
            return URL.init(string: urlString)
        }
        catch
        {
            return nil
        }
    }
}

}

when I lost the Finder menu "open with" entry for my test app while triaging an open vs make file doc issue - see below. I do have an app delegate openFile: as

func application(_ sender: NSApplication, openFile: String) -> Bool {
    let urlString = (openFile.hasPrefix("file://") ? openFile : "file://" + openFile)
    let fileURL = URL(string: urlString.addingPercentEncoding(withAllowedCharacters: NSCharacterSet.urlQueryAllowed)!)!
    return self.doOpenFile(fileURL: fileURL)
}
func doOpenFile(fileURL: URL) -> Bool {
    let dc = NSDocumentController.shared()
    var status : Bool = false
    var itemURL = fileURL

    //  Resolve alias, container webloc bookmark before target bookmarking
    if let original = (itemURL as NSURL).resolvedFinderAlias() { itemURL = original }
    if itemURL.absoluteString.hasSuffix("webloc") {
        if isSandboxed() != storeBookmark(url: itemURL as URL) {
            Swift.print("Yoink, unable to bookmark (\(itemURL))")
        }
        if let webURL = itemURL.webloc {
            itemURL = webURL
        }
    }
    else
    {
        if isSandboxed() != storeBookmark(url: itemURL as URL) {
            Swift.print("Yoink, unable to bookmark (\(itemURL))")
            return false
        }
    }

    dc.openDocument(withContentsOf: itemURL, display: true, completionHandler: { (nextURL, wasOpen, error) in
        if error != nil {
            NSApp.presentError(error!)
            Swift.print("Yoink, unable to open doc for (\(String(describing: nextURL)))")
            status = false
        }
        else
        {
            let newWindow = nextURL?.windowControllers.first?.window
            (newWindow?.contentView?.subviews.first as! MyWebView).next(url: itemURL)
            newWindow?.offsetFromKeyWindow()
            status = true
        }
    })
    return status
}

I was getting an error (presentError:) by my view controller as I was trying to open a 'webloc' url rather than make a doc for it - subtle distintction?

Anyway now my menu entry is gone in the Finder, so I'm in search of a checklist to verify I have [still] set things up right, My app's single doc Info.plist appears as (relevant do docs) as:

enter image description here

when am I missing !? This work uses others' re: resolving Finder alias, sandbox support, and webloc contents resolution.

I was trying to resolved an issue where a search string encoded filename - webloc, was not getting resolved by my -URL.webloc() function when I make "some" change and lost the Finder's "open with" entry for my app.

So for the benefit of me and others, we need a check list (recipe) to run thru. This app is a test mini-browser, using WKWebView with a next(url:) function to load the next url.

slashlos
  • 913
  • 9
  • 17
  • Note that if you need to create a file URL without the scheme "file://" you just need to use URL initializer `URL(fileURLWithPath:)` – Leo Dabus Mar 19 '18 at 00:02
  • You need to understand the difference between URL properties `absoluteString` and `path` – Leo Dabus Mar 19 '18 at 00:04
  • Yes the latter does not encompass a schema file://, but is that the problem? In the webloc check either would do as I see no difference in the test. That introduced another question I'll ask separately - sandboxing webloc urls so their contents can be read. – slashlos Mar 19 '18 at 00:16
  • sometimes the launch services database (which controls the finder menu) gets corrupted. try rebuilding it. also deleting all old copies can help. test with guest account or on another fresh computer. – mahal tertin Mar 19 '18 at 19:05

1 Answers1

0

Info.plist corruption - check your Info.plist as source code as this shows

enter image description here

These launch service tokens, i.e., LSItemContentTypes were new to me and while not recognizing when I had done this I know at once it was not something I've done in the past.

For the record, getting your app to be "registered" is an implicit act as defined in Launch Services. As stated therein, you shouldn't need to do anything explicit - aside from setting up your Info.plist properly.

My problem was in registering several different file type extensions as individual document types - non starter, when instead all I needed was to lump all viewable types under a single document type, and this "fat-finger" probably happened in the mad dash to rectify what was looking bad. Any way your needs may vary re: multiple document types.

slashlos
  • 913
  • 9
  • 17