Можно ли вручную реализовать привязку Какао?
Для однопользовательской модификации используйте ~/.profile из перечисленных вами. Следующая ссылка объясняет, когда Bash читает разные файлы.
http://telin.ugent.be/~slippens/drupal/bashrc_and_others
Если вы хотите установить переменную окружения для приложений графического интерфейса, вам нужен ~ / .MacOSX / файл environment.plist
4 ответа
Вот лучшее решение, которое я могу найти. У меня есть более подробное обсуждение и демонстрационный код здесь: http://tomdalling.com/blog/cocoa/implementing-your-own-cocoa-bindings/
По сути, вы НЕ переопределить bind: toObject: withKeyPath: options: или unbind: . Реализация по умолчанию для NSObject будет использовать NSAutounbinder , чтобы избежать циклов сохранения. Как отметил Луис Гербарг, все еще бывают ситуации, когда NSAutounbinder не срабатывает. Однако вы можете заставить свои привязки работать не хуже, чем привязки Apple.
Поскольку реализация по умолчанию ] bind: toObject: withKeyPath: options: не обновляет модель при изменении представления, изменения, связанные с просмотром, должны распространяться вручную. Вы можете использовать - [NSObject infoForBinding:] , чтобы получить всю информацию, необходимую для обновления связанного объекта. Я добавил свой собственный метод в NSObject с категорией:
-(void)propagateValue:(id)value forBinding:(NSString*)binding;
Он обрабатывает получение связанного объекта, связанного пути ключа и применение преобразователя значений. Реализация доступна по ссылке вверху.
Вы можете проверить протокол NSKeyValueBindingCreation . Он позволяет создавать привязки программно с помощью кода. (Не забудьте выполнить эту работу в методе awakeFromNib, если вам нужно ссылаться на переменные IBOutlet, иначе они могут быть нулевыми.)
Короткий ответ: нет, вы не можете заставить его работать без обходного пути в вызывающем коде и перьях. Даже NSAutounbinder пропускает некоторые случаи для NSDocument и NSWindowController, если Apple не может заставить его работать правильно для 2 классов, они специально настраивают тех из нас, у кого нет доступа к внутренностям AppKit, в основном нет никаких шансов.
Сказав это, есть два обходных пути, которые, возможно, немного лучше, чем отмена привязки в windowWillClose:.
- Не привязывайтесь к владельцу файла, а вместо этого перетащите NSObjectController как объект корневого уровня в перо и привяжите к нему, затем установитеContents: на контроллере объекта во время awakeFromNib.
- Включить сборку мусора. Если это вариант, он решает все проблемы с циклом объектов ;-) Очевидно, что GC вносит свои собственные проблемы, и если вам нужна совместимость с 10.4, это не запускается.
См. Пример mmalc GraphicsBindings , чтобы получить хороший пример того, как реализовать свои собственные привязки. Вам необходимо реализовать неформальный протокол NSKeyValueBindingCreation , чтобы заставить его работать. Чтобы ваши контроллеры знали, что есть вещи, которые можно связать, вызовите exposeBinding в методе инициализации + (id) вашего представления:
+ (void)initialize { [self exposeBinding:@"ILIKEBINDAGE"]; }
Затем вам нужно будет реализовать каждый из методов управления привязками в протоколе NSKeyValueBindingCreation. Вам в основном нужно настроить KVO для представления, чтобы оно знало, когда обновлять, на основе поведения приложения и обрабатывать очистку (отменить привязку :).
Это много лишнего, довольно уродливого кода, поэтому может оказаться, что использование традиционного связующего кода работает лучше и его легче читать.