2013-11-29 3 views
3

В настоящее время я работаю над проектом iOS, который содержит множество ярлыков/кнопок/элементов управления, расположенных на десятках сцен. Большинство этих элементов управления были созданы с помощью Interface Builder.Изменить системный шрифт для тестирования

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

Есть ли способ временно изменить системный шрифт, чтобы было легче увидеть, где настройки шрифта были забыты?

Я искал:

  • Изменение системного шрифта программно
  • Изменение шрифта в Xcode где
  • Изменение шрифта в тренажере IOS (может быть, как вариант отладки)

Но я пока не увенчался успехом. Я не могу быть единственным с такой проблемой - просто естественно утомительно устанавливать каждый шрифт управления программным путем.

Единственное, что я мог себе представить, это как переопределение базового метода рисования UILabel с помощью специального шрифта (кто-нибудь?), Но это кажется немного чрезмерным?

ответ

0

Вы можете попробовать создать категорию, которая переопределяет метод systemFontOfSize: метод UIFont или метод swizzling (вы можете узнать больше о методе swizzling здесь: http://cocoadev.com/MethodSwizzling). Оба являются чрезвычайно уродливыми и не должны использоваться в производстве, но должны быть хорошими для целей тестирования.

Вот пример категория UIFont:

@interface UIFont (SysFont) 
@end 
@implementation UIFont (SysFont) 
+ (UIFont *)systemFontOfSize:(CGFloat)fontSize { 
    return [UIFont fontWithName:@"YourFont" size:fontSize]; 
} 
@end 
+0

Да я хотел бы избежать swizzling и надеялся, что там будет, как вариант отладки где-нибудь, но используя категорию кажется, разумный компромисс. Должен был подумать об этом сам. Спасибо :-) – JiaYow

+1

Обновление: использование этой категории приведет к неопределенному поведению (переопределению существующего метода с категорией). Swizzling был бы единственным выбором при таком подходе. Я все еще принимаю ваш ответ, так как swizzling кажется правильным ответом. – JiaYow

+0

Да, согласно документам, это может привести к неопределенному поведению, и именно поэтому я сказал, что они оба уродливые и не должны использоваться в производстве. Однако вы можете подавить предупреждения для этой категории с помощью простого макроса: #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wobjc-protocol-method-implementation" // метод идет здесь ... #pragma clang diagnostic pop –

Смежные вопросы