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

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

0 голосов
/ 23 сентября 2010

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

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

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

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

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

С уважением,

Элиас

1 Ответ

4 голосов
/ 23 сентября 2010

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

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

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

Здесь вы можете увидеть пример такого сеанса отладчика (после EXC_BAD_CRASH):

alt text

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

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

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

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

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

alt text

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

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

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

...