2009-09-21 4 views
1

В разрисованных обычной для пользовательской UITableViewCell, используют следующее без каких-либо проблем:Bad Ошибки доступа при обращении к UIColor *

CGContextRef context = UIGraphicsGetCurrentContext(); 
UIColor* backgroundColor = [UIColor colorForHex:@"FFFEFF"]; 
[backgroundColor set]; 
CGContextFillRect(context, rect); 

Конечно, это вполне стандартное для моего интерфейса на объекте UIColor за исключением для colorForHex, которая принимает строку и ломает это вниз в значения RGB 0-255 и возвращает объект UIColor со следующим (а по умолчанию настроен на 1.0f):

return [UIColor colorWithRed:((float) r/255.0f) green:((float) g/255.0f) blue:((float) b/255.0f) alpha:a]; 

Теперь это работает отлично, но я пытался улучшить это и централизовать создание цвета (и шрифта), чтобы попробовать чтобы максимально ускорить процедуру розыгрыша. Здесь я получаю проблему.

создать протокол, используя:

@protocol ItemListTableViewCellDelegate 
-(UIFont*) fontForId:(int) fontID; 
-(UIColor*) colorForId:(int) colorID; 
@end 

Контроллер реализует этот протокол и реализует метод colorForId как:

-(UIColor*) colorForId:(int) colorID { 
    UIColor* requestedColor = nil; 
    switch (colorID) { 
     case BACKGROUND_COLOR_ID: 
     { 
      requestedColor = backgroundColor; 
     } 
      break; 
    } 
    return requestedColor; 
} 

, где BackgroundColor создается в качестве члена контроллера в качестве UIColor * в методе initWithStyle контроллера. Это вызвано и создается backgroundColor.

Клетка имеет NSObject<ItemListTableViewCellDelegate>* cellDelegate элемент, который инициализируется с контроллером, так что клетка может позвонить

UIColor* backgroundColor = [cellDelegate colorForId:BACKGROUND_COLOR_ID]; 

, который появляется, чтобы вернуть правильный указатель на UIColor в контроллере, но когда «множество» называется на этом цвете в методе рисования ячейки, то ячейка выдает ошибку BAD ACCESS, и я не могу понять, почему.

Любые указатели в правильном направлении?

ответ

2

Для любых ошибок EXC_BAD_ACCESS вы обычно пытаетесь отправить сообщение выпущенному объекту. BEST способ отслеживания этих действий используется NSZombieEnabled.

Это работает, никогда не выпуская объект, а завершая его как «зомби» и устанавливая внутри него флаг, который говорит, что он обычно был бы выпущен. Таким образом, если вы попытаетесь получить к нему доступ еще раз, он все еще знает, что это было до того, как вы сделали ошибку, и с этой небольшой информацией вы обычно можете отступить, чтобы узнать, в чем проблема.

Это особенно помогает в фоновом режиме, когда отладчик иногда дергает любую полезную информацию.

ОЧЕНЬ ВАЖНО ДЛЯ ЗАМЕЧАНИЯ, однако, необходимо, чтобы 100% убедитесь, что это только в вашем отладочном коде, а не в вашем коде распространения. Поскольку ничто никогда не выпускается, ваше приложение течет, течет и течет. Чтобы напомнить мне об этом, я поместил этот журнал в свой appdelegate:

if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")) 
    NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!"); 
Смежные вопросы