Как связать с пользовательским представлением в Cocoa с помощью Xcode 4?
Я начинаю, когда речь заходит о написании приложений для Mac и работе с Cocoa, поэтому, пожалуйста, простите мое невежество.
Я ищу для создания настраиваемого представления, которое предоставляет некоторые свойства, которые я могу связать с NSObjectController. Поскольку это настраиваемый вид, инспектор Bindings, очевидно, не перечисляет ни одного из свойств, которые я добавил в представление, которое я могу связать с помощью Interface Builder.
После обращения к справочной системе Stackoverflow/Google я наткнулся на несколько возможных решений, но ни один из них не подходит для моей ситуации. Первый предложил создать IBPlugin, который тогда означал бы, что мои привязки будут доступны в инспекторе Bindings. Затем я мог привязать представление к контроллеру с помощью IB. По-видимому, IBPlugins не поддерживаются в Xcode 4, так что один из окна. Я также предполагаю (возможно, ошибочно), что IBPlugins больше не поддерживаются, потому что в наши дни лучший способ сделать такие вещи?
Второй вариант - связать контроллер с представлением программно. Я немного смущен, насколько точно я достиг этого. Будет ли он требовать подклассификации NSObjectController, чтобы я мог добавлять вызовы для привязки к представлению? Мне нужно добавить что-нибудь в представление, чтобы поддержать это? Некоторые примеры, которые я видел, говорят, что вам нужно переопределить метод привязки, а другие говорят, что вы этого не делаете.
Кроме того, я заметил, что некоторые примеры пользовательских представлений вызывают [self exposeBinding:@"bindingName"]
в инициализаторе. Из того, что я собираю из разных источников, это то, что связано с IBPlugins, и это не то, что мне нужно сделать, если я их не использую. Это правильно?
Я нашел сообщение о Stackoverflow здесь, которое, похоже, обсуждает что-то очень похожее на мою проблему, но не было никакого явного победителя в отношении лучшего ответа, Последний комментарий Noa на 12 сентября кажется интересным, хотя они упоминают, что вы должны называть exposeBinding:
. Это комментарий по правильному пути? Является ли вызов exposBinding действительно необходимым?
Извиняюсь за любые немые вопросы. Любая помощь была высоко оценена.
Ответы
Ответ 1
Первое предложение о создании IBPlugin, которое тогда означало бы, что мои привязки будут доступны в инспекторе Bindings. Затем я мог привязать представление к контроллеру с помощью IB. По-видимому, IBPlugins не поддерживаются в Xcode 4, так что один из окна.
Правильно. Интерфейс Builder мертв; долго жить редактором Xcode nib (который они по-прежнему иногда называют Interface Builder).
Когда IB ушел, тоже IBPlugins.
Я также предполагаю (возможно, ошибочно), что IBPlugins больше не поддерживаются, потому что в наши дни лучший способ сделать такие вещи?
Неа.
Второй вариант - связать контроллер с представлением программно. Я немного смущен относительно того, как бы я это достиг.
Отправить представление a bind:toObject:withKeyPath:options:
сообщение.
Требуется ли это для подкласса NSObjectController, чтобы я мог добавлять вызовы для привязки к представлению?
Not NSObjectController, но то, что либо владеет nib (например, оконным контроллером или контроллером представления), либо является объектом верхнего уровня внутри него (например, делегат приложения в MainMenu nib).
Мне нужно добавить что-нибудь в представление, чтобы поддержать это?
См. ниже.
Некоторые примеры, которые я видел, говорят, что вам нужно переопределить метод привязки, а другие говорят, что вы этого не делаете.
Вы использовали для не-просмотров (представления всегда работали без переопределения), но не больше. Вам больше не нужно переопределять метод bind::::
.
Я не знаю, когда это изменилось, но я написал тестовое приложение, чтобы подтвердить текущее поведение (как у Snow Leopard и Lion).
Кроме того, я заметил, что некоторые примеры пользовательских представлений вызывают [self exposeBinding:@"bindingName"]
в инициализаторе. Из того, что я собираю из разных источников, это то, что связано с IBPlugins, и это не то, что мне нужно сделать, если я их не использую. Это правильно?
Неа.
Вам не нужно переопределять bind::::
для привязки к любому свойству KVC-/KVO-совместимости, и вам не нужно отправлять exposeBinding:
.
Смутно, в документации говорится иначе: вы должны переопределить bind::::
и unbind:
даже в представлениях и что exposeBinding:
полезен для чего угодно.
Все, что вам нужно сделать для создания доступного привязки, - это реализовать свойство KVC-/KVO. Если это синтезировано @property
, это делается. В противном случае см. здесь.
Затем отправьте сообщение view/object a bind::::
, чтобы на самом деле связать его, так как нет способа открыть привязку в редакторе nib.
TL; DR:
Просто реализуйте регулярное свойство, и вы сможете связать его с a bind:toObject:withKeyPath:options:
сообщением (по крайней мере, в Snow Leopard и Lion). Вам больше не нужно отправлять exposeBinding:
из любого места. Вы не можете создавать настраиваемые привязки в редакторе nib в Xcode 4.
Ответ 2
Разрабатывать/уточнять/понтификатировать на @PeterHosey ответ.. я взял на себя смелость разбить его тестовое приложение в попытках сделать ясно ЕДИНСТВЕННЫЙ способ, которым я смог найти привязку свойств вида... в "современной" (не), пост-IBPlugin (RIP) эре... Все приложение выполнено в 3 метода в подклассе NSView
с прикрепленными привязками.
![enter image description here]()
Чтобы просмотреть "обновить представление", не забиваясь с помощью установщика свойств hueDegrees
.. Я просто делаю это...
- (void) didChangeValueForKey:(NSString*)key {
self.needsDisplay = YES; [super didChangeValueForKey:key]; }
Таким образом, и установив начальное значение для свойства в IB, так...
![enter image description here]()
Вы удаляете много кода клея. Чтобы правильно обновить "Hue" NSTextField
... так как вы не можете "привязать" к представлению.. Я просто перетаскиваю NSViewController
в области "Объекты" и подключаю контроллер вида View
выход на вид в IB. Затем создайте привязку с помощью контроллера вида.
![enter image description here]()
Надеюсь, это поможет прояснить - с помощью довольно простого решения - эта плохо документированная/обычно запутанная проблема.