С существующими устаревшими и современными приложениями Mac не удается связать связанные документы в глобальном масштабе с современным приложением (Launch Services?)

Question

Обновлено 4-9-2013 Это общий отчет моего предыдущего вопроса. Поскольку я узнал гораздо больше о Launch Services, UTIs и обесцененных кодах создателей, я чувствую, что лучше задаю вопрос с нуля.

Описание проблемы:

У нас есть приложение, которое было разработано для устаревших Mac 9.xx, который до сих пор работает на Snow Leopard (с Rosetta). Приложение использует вложенные файлы. Мы разработали наше новое приложение для Snow Leopard и за его пределами. Проблема заключается в том, что Launch Services не связывает новое приложение с новой конфигурацией plist, которую мы сейчас используем, и мне нужно знать, что я делаю неправильно.

Если я нажимаю правой кнопкой мыши на прилагаемом документе и выбираю GetInfo, я могу связать связанный файл с устаревшим приложением или с новым приложением, и он будет работать так, как я ожидаю. Я считаю, что это связано с тем, что Snow Leopard по-прежнему использует технологию Creator Code для такого типа ассоциации. Если я скажу файлу, чтобы он связался со старым устаревшим приложением, и я нажимаю «Изменить все», «Запуск служб» будет правильно связывать все файлы этого типа, и он будет работать, как ожидалось. Если я скажу файлу, чтобы связать себя с новым приложением, и я выбираю «Изменить все», приложение откроется, но файлы не будут. Из того, что я могу сказать, служба запуска назначает динамическое UTI для приложения, а при нажатии на файл OS не знает, какое приложение использовать.

Я нашел пару сообщений, которые, похоже, предполагают, что Apple, возможно, допустила некоторые ошибки дизайна в новой методологии UTI. В одном из сообщений показано, как добавить массив расширений строковых файлов в словарь ExportedUTIs из списка новых приложений pList. Это заставляет приложение функционировать правильно, но это не решит проблему; Если мы разрешим нашим пользователям называть их файлы чем-либо, мы не можем предсказать в массиве, что будет делать их расширение. Нам нужно, чтобы службы запуска работали корректно с кодом UTI, или некоторые из них, как заставить код OSType работать.

Post about UTI's

После того, как новое приложение решает, что не может открыть это связано файл, я должен открыть LanchServices.plist, удалить запись и перезапустить базу данных lsregister. Затем я могу снова открыть файл с новым приложением (связав его, не нажимая «Изменить все»).

Я прилагаю некоторые изображения в приложение plists, комплектного документа PLIST и записи Launch Services:

Любая помощь и наше руководство высоко ценится ,

Майк

Обновлено: 4/16/2013

Ссылка на сообщение о УТИ-х я также предоставленных содержит ссылку на открытое приложение источник программного обеспечения под названием RCDefault приложение. Это приложение свяжет ваш APP с данным файлом на основе вашего выбора UTI, расширений файлов, OST-кодов и типов файлов. Как ни странно, это приложение способно связать файл с приложением, основанное на структуре UTI, которая предоставляется в наших plists.

Возможно ли, что это всего лишь ошибка в Launch Services для Snow Leopard для этого конкретного сценария, и Apple решила просто проигнорировать это на данный момент (учитывая, что они больше не поддерживают Snow)?

Answer 1

Вам не хватает ваших CFBundleTypeExtensions. Создайте CFBundleTypeExtensions типа Array, а Item 0 - расширение вашего файла.

У вас также отсутствует ваше имя CFBundleTypeName, которое является типом псевдонима, который будет использовать этот файл. Делает это красивым и красивым. :)

Reference (CFBundleDocumentTypes): https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html

Answer 2

Ее было некоторое время, так как я первоначально отправил это, но только в том случае, если это интересно кому-то еще я сделал некоторые дополнительные открытия:

Эта проблема Безразлично» t имеет много общего с попыткой быть совместимым с устаревшим приложением и OSX-приложением. Вложенный файл содержит код создателя и код OSType. Пока эти два элемента существуют в унаследованном приложении plist, он будет открыт, когда его попросят, глобально или индивидуально.

Проблема заключается в том, что проблема заключается в том, чтобы включить код ostype в новый планшет приложений как эквивалентный тип в UTI с экспортированным типом.

Единственное решение, которое должно работать, заключается в том, чтобы добавить массив расширений имен файлов в качестве эквивалентного типа, о котором упоминалось выше, с именем @Derek.

Это единственное решение, которое решает эту проблему. Как это ни парадоксально, это нарушает правила человеческого интерфейса яблок, которые в какой-то степени указывают, что пользователь не должен принуждаться к ограничениям на расширение файлов.

Похоже, что работа UTI работает только с несвязанными документами (файлами), которые также поддерживаются несколькими сообщениями, которые в основном говорят о том, что яблоко действительно испортило это. Какой смысл беспокоиться об UTI, если в конце концов вам нужен массив расширений?