а откуда вы взяли cacheContext и что вы дальше с ним делаете? просто если вы его запоминаете из drawrect - то это ну очень плохо. насчет того что вы делаете - если я правильно понял то что вы хотите сделать, то имхо это нужно реализовывать по другому , через маску слоя. т.е. вы делаете простой графический редактор, но вместо рисования в контекст вьюхи рисуете в bitmap - и ее применяете уже к layer'у uiimageview
Насколько я понимаю, увеличить количество вызовов не возможно. Но если вы до этого в touchesMoved рисовали, и убрав рисование, не получили прироста - то это странно как-то. Хотя я сейчас слабо представляю, что Вы имеете ввиду под "копирование участков картинки"
может зальете тестовый пример, и я, как минимум, посмотрю. А там может и решение придумает
NSXMLParser, имхо, не самый лучший парсер из доступных, да и совет по использованию initWithContentsOfURL откровенно плохой, так как метод работает синхронно и наверняка повесит ui при не wi-fi вском интернете
лучше не от uiwindow, а от uiview. Из документации Every iOS app has a window that handles the presentation of the app’s user interface. Although the window provides crucial functionality, most apps never need to access it. Typically, only an app that supports an external display needs to interact with a window.
На данный момент на xib'ах отсутствует плашка Deprecated. С одной стороны в StoryBoard позволяет делать то, что в xib'aх не возможно (к примеру статическая таблица, да и много чего другого), с другой стороны в Storyboard'е нельзя пока создавать переиспользуемуые UIView. Так что будем считать, что эти технологии дополняют друг друга и Вы пока ошибаетесь.
Просьба к Вам, оставить проект в текущем виде на гит-хаб (ну или перезалить в другой репозиторий и опубликовать тут), что бы можно было продемонстрировать проблему
Ну там явно в нутри messageUI неонка:), а если точнее, то объявлен класс MPViewController, с точно таким же названием как и у Вас. При загрузке сторибоарда, в рантайме берется не тот класс (с messageUI), у которого нет свойства myPicker - получаем падение. Но все выше сказанное - всего лишь предположение. Мораль проста, использовать уникальные имена классов (поменьше банальных ViewController) и не менее уникальные префиксы для классов. Можно переходить на 3х буквенные. плата за отсутсвие пространства имен :)
Большая просьба проверить мое решение. Если это так, то тогда проблема в недрах MessageUI. Скорей всего там есть такой класс MPViewController, и оно конфликтует.
Ах да, забыл, а еще можно создать кастомный класс, наследника UIButton, и в методе initWithCoder сделать то, о чем вы говорили. И не будет никаких левых статических методов. Само собой установить в IB для нужных кнопок этот класс. Имхо, это самое правильное решение
Ну так а кто мешает переопределить awakeFromNib или сделать outlet collection(ну или просто outlet) и применить точно так же требуемый единый стиль к кнопкам? Вы так говорите, как будто использование xib. Но при этом не будет проблем с расположением кнопки на своей позиции+сразу же, не отходя от кассы, можно будет расположение пэлемнов на 3,5", 4", iOS7+выставить autolayout constraince.
@alexyat "вот поэтому я и не пользуюсь interface builder'ом" "Как только появится время обязательно займусь этим."
Вот по этому и нет времени:) А если серьезно, использование IB существенно ускоряет разработку (1) , как не крути , рисовать формочку быстрее, чем ее же кодить.
И субьективно, в чужом xib'e(сделаном другим программистом) на порядок проще разобраться чем в чужом коде(2). Особенно если речь идет о frame'ах или autolayout'e. насчет генерации кнопочкек, никто не запрещает генерировать некоторые элементы вьюшки в коде, комбинируя оба подхода.
Единственный плюс - это скорость загрузки. Иногда это критично.
Если вы внимательно посмотрите на методы dataSource, то увидите, что в них всегда присутствует экземпляр NSTableView. Это та самая таблица, которая делегирует.
Таким образом вы всегда можете проверить, та ли таблица пришла
Рассмотрим пример, у вас есть две таблички
NSTableView * _firstTable;
NSTableView *_secondTable;
тогда банальная проверка
- (NSInteger) numberOfRowsInTableView: (NSTableView *) tableView
{
if (tableView==_firstTable){
return [self.list count];
}
if (tableView==_secondTable){
return 10;
}
return 0;
}
Решает вопрос, само собой, Вам нужно где то установить _firstTable.dataSource = self; + аналогично для _secondTable.
Это самое простое, но не самое идеальное решение. О правильном решении вы можете почитать где-то тут http://www.labirint.ru/books/273378/point/gm/
Не могу так быстро найти прямую ссылку на объяснение этого паттерна, но в двух словах смысл в том, что бы создать отдельный класс, который будет "датасоурсить" данные для таблицы.
_firstTable.dataSource = dataSource1;
_secondTable.dataSource = dataSource2;
