Проблема делегатов UITextView

Я пытаюсь получить доступ к делегатам UITextView, но у меня проблема

У меня есть UIViewController с протоколом UITextViewDelegate и перо, содержащее textView.

Если я устанавливаю делегата внутри viewDidLoad как «textView.delegate = self» и касаюсь textView, приложение вылетает без регистрации ошибок. Если я начну редактировать textView с помощью кода типа «[textView статьFirstResponder]», будут вызваны все делегаты.

Когда я устанавливаю делегата в перо, создавая соединение между textView и владельцем файла и удаляя «textView.delegate = self», делегаты также не вызываются.

Что я здесь делаю не так?

С уважением,

Элиас


person Elias    schedule 23.09.2010    source источник
comment
Вы уверены, что владельцем файла является правильный файл? Кроме того, какие методы делегата вы вызываете? Пожалуйста, разместите код.   -  person MishieMoo    schedule 23.09.2010


Ответы (1)


Нелегко помочь вам без дополнительного описания, опубликованного кода или файла xib.

Вы говорите, что приложение вылетает без каких-либо ошибок регистрации - ну, вы имеете в виду, что в окне консоли нет вывода? Это нормально для приложения, в котором произошел сбой.

В любом случае, вы должны иметь возможность получить трассировку стека, чтобы выяснить, где примерно произошло сбой приложения. Откройте отладчик (⇧⌘Y) и посмотрите положение. Это должно дать вам представление о том, что пошло не так.

Вот пример такой сессии отладчика (после EXC_BAD_CRASH):

alt text

Первые две строки не дают нам много информации, но позже мы можем увидеть, что приложение вылетело при загрузке пользовательского интерфейса из файла NIB. Что ж, обычно единственный код, который выполняется во время такой загрузки, - это awakeFromNib методы - вам решать, как найти проблему в этих строках.

Часто верх выполнения кода не имеет никакого смысла - например, вы можете где-то увидеть свой метод ViewController, но несколько основных вызовов функций (те, где произошел сбой кода) находятся в методах / классах, которые вы никогда не вызываете в своем коде. В большинстве случаев это признак неправильного выделения / выделения памяти. Может случиться так, что вы забыли retain некоторые из ваших объектов, они уже были выпущены, но вы все еще сохраняете ссылку (указатель) на его память. Поскольку эта память была фактически освобождена, позже ее место занял другой объект, обычно это какой-то внутренний объект Apple, о котором вы никогда не слышали. Позже ваш код пытается отправить сообщение вашему плохому объекту, но он отправляет сообщение чему-то совершенно другому. БАММЕР! Вот как вы получаете эти сбои и странные следы стека.

Чтобы решить проблему, которую я только что описал, вы можете использовать Instruments и ее инструмент Zombies. К сожалению, вы не можете запустить Zombies из Xcode, вам нужно запустить инструменты отдельно, затем выбрать Zombies в iPhone Simulator/Memory, затем Choose Target на панели инструментов, вы должны увидеть свое приложение там или иметь возможность перейти к нему в файловой системе.

Что делает инструмент Zombies, так это то, что он никогда не освобождает память после освобождения объектов. Вместо этого он преобразует эти объекты в класс NSZombie. Этот класс перехватывает все обращения к себе и сообщает вам, когда какой-то код пытается отправить ему сообщение.

Вот как выглядит такая сессия инструментов (это тот же сбой, что и в отладчике выше):

alt text

В таблице вы можете видеть, что мы пытаемся отправить сообщение UIScrollView, который уже был освобожден. Вы также можете увидеть всю историю вызовов сохранения / освобождения этого конкретного объекта. Таким образом вы можете найти недостающую фиксацию или неправильную разблокировку / автоматическую разблокировку.

Помните - инструменты Zombies можно использовать только с симулятором, потому что на реальном устройстве недостаточно памяти для хранения всех этих блоков памяти.

Надеюсь, я смогу помочь вам с дальнейшим анализом вашей проблемы.

person Michal    schedule 23.09.2010