Ошибка MonoTouch 5: «Не удалось найти селектор setXxxxxx» после перехода на Xcode 4.2 и MonoDevelop 2.8

Question

У меня есть проект для iPad, который разрабатывался в Xcode 3.2.6 / MonoTouch 4.2.x / MonoDevelop 2.6, и когда я установил Monotouch 5, MonoDevelop 2.8.1 и Xcode 4.2, проект компилировался и работал нормально. Но когда я начал изменять файлы XIB в Xcode 4.2 (добавление точек), у меня начались некоторые глюки:

1) Приложение аварийно завершает работу, и MonoDevelop в режиме отладки сообщает, что представления не были загружены, потому что выход представления не был установлен. Я понял, что в Xcode 4.2 нет необходимости создавать выход с именем «view» в файле .h, и просто нужно подключить представление «Владелец файла» к элементу управления view в конструкторе. Правильно?

2) Основная проблема, которая еще не решена, состоит в том, что я получаю исключения "Не удалось найти селектор setXxxxx", где "xxxxx" - это имя выхода для элемента управления пользовательского интерфейса. Это начало происходить в ViewControllers, которые унаследованы от базового контроллера представления, но как только я начал изменять другие обычные viewControllers, я получаю ошибки того же типа. Любые намеки на то, что не так?

3) У меня есть контроллер, который динамически загружает некоторые виды и работает нормально. но когда я устанавливаю свойство в одном из выходов этого суб-представления (например, в тексте UILabel), значение устанавливается (в отладчике), но в пользовательском интерфейсе изменений нет. Действия, например, работают нормально. Что может быть не так.

4) Любые специальные настройки в XIB, которые необходимы для правильной интеграции под Xcode 4.2 с MonoDevelop 2.8?

Помощь очень ценится, подумал я, возвращаясь к предыдущему набору инструментов и monotouch, но я думаю, что после обновления проекта невозможно вернуться назад, не потеряв все разработки, сделанные сейчас.

Спасибо, Педро

РЕДАКТИРОВАТЬ : Помимо нового кода [Outlet] с чистым атрибутом, сгенерированного MonoTouch 5 (заменяющего множество ранее сгенерированного кода), существенным отличием является то, что до того, как созданный частичный класс был общедоступным, и теперь является частным , это может быть источником моей проблемы. Есть ли способ создания открытых частичных классов или защищенных?

EDIT 2 : Если я вручную добавлю ключевое слово public к частичному классу и членам, сгенерированным MonoTouch в designer.cs, селекторы будут созданы за кулисами и все работает. Это указывает на то, что при переходе от общего к частному частичному классу генерация привязок изменилась в MonoTouch 5, это из-за замысла или ошибки? Мне было бы очень странно, что теперь невозможно создать контроллер представления с выходами, создать его подкласс, а дочерний контроллер представления не может получить доступ к выходам родительского класса.

Answer 1

1) В базовом классе UIViewController действительно есть выход представления, который является свойством Objective-C. При использовании Interface Builder 3 с MonoTouch IB часто не разрешал подключаться к выходу базового представления, поэтому многие пользователи создавали свои собственные подклассы. MonoDevelop 2.6 и более ранние версии создавали эти пользовательские выходы как ivars (поля Objective-C), и, очевидно, среда выполнения UIKit соединяла бы объект с обеими версиями выхода - как с пользовательским ivar, так и с базовым свойством. MonoDevelop 2.8 генерирует настраиваемые выходы в качестве свойств, что означает, что выход избыточного представления затеняет выход базового представления, поэтому выход базового представления никогда не устанавливается, и UIKit становится несчастным. Вы можете исправить это, удалив лишнюю розетку пользовательского представления - MD 2.8.2 сделает это автоматически .

2) Кажется, ошибка в том, как MonoTouch экспортирует пользовательские розетки, что предотвращает подключение к пользовательским розеткам, определенным в базовых классах. Возможный обходной путь упоминается в отчете об ошибке .

3) Визуализация пользовательского интерфейса не будет обновляться, пока ваше приложение приостановлено в отладчике, оно будет обновляться при следующей итерации основного цикла.

4) Нет.

5) Доступность класса должна контролироваться частью класса пользователя, а не частью класса конструктора, поэтому вы можете свободно ее изменять.