Mam następujący zestaw kodów:
CustomView.h
#import <UIKit/UIKit.h>
IB_DESIGNABLE
@interface CustomView : UIView
@property (nonatomic) IBInspectable UIColor *borderColor;
@property (nonatomic) IBInspectable CGFloat borderWidth;
@property (nonatomic) IBInspectable CGFloat cornerRadius;
@end
CustomView.m
#import "CustomView.h"
@implementation CustomView
- (void)setBorderColor:(UIColor *)borderColor {
_borderColor = borderColor;
self.layer.borderColor = borderColor.CGColor;
}
- (void)setBorderWidth:(CGFloat)borderWidth {
_borderWidth = borderWidth;
self.layer.borderWidth = borderWidth;
}
- (void)setCornerRadius:(CGFloat)cornerRadius {
_cornerRadius = cornerRadius;
self.layer.cornerRadius = cornerRadius;
}
@end
(Dla odniesienia w języku Swift ten problem występował również w kodzie Swift)
CustomView.swift
@IBDesignable
class CustomView : UIView {
override init(frame: CGRect) {
super.init(frame: frame)
}
required init(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
@IBInspectable var borderColor : UIColor = UIColor.clearColor() {
didSet {
self.layer.borderColor = borderColor.CGColor
}
}
@IBInspectable var borderWidth : CGFloat = 0.0 {
didSet {
self.layer.borderWidth = borderWidth
}
}
@IBInspectable var cornerRadius : CGFloat = 0.0 {
didSet {
self.layer.cornerRadius = cornerRadius
}
}
}
Dodałem UIViewdo kontrolera widoku w scenorysie i ustawiłem jego podklasę na CustomView.
Spowoduje to dodanie wiersza „Designables”. Utknął na „Aktualizacji”, a podpowiedź mówi „Oczekiwanie na zbudowanie celu”. Ten status nigdy się nie zmienia.
Kiedy przejdę do inspekcji atrybutów, mogę ustawić następujące IBInspectablewłaściwości:
Po ustawieniu pojawiają się również w „Atrybutach środowiska wykonawczego zdefiniowanych przez użytkownika”:
Jednak status „Designables” nigdy nie wykracza poza „Updating” z wciąż tą samą wskazówką (próbowałem budować Cmd + B kilka razy, nic się nie zmienia).
Ponadto podczas ustawiania IBInspectablewłaściwości otrzymuję ostrzeżenie o każdej z nich:
IBDesignables - Ignorowanie atrybutu środowiska wykonawczego zdefiniowanego przez użytkownika dla ścieżki klucza „borderColor” w wystąpieniu „UIView” ... ta klasa nie jest zgodna z kodowaniem klucz-wartość dla klucza borderColor.
Zrzut ekranu z wygenerowanymi ostrzeżeniami:
Znam problemy związane z kodowaniem klucz-wartość i ogólnie wiem, jak je rozwiązać ... ale nie rozumiem, jak rozwiązać ten problem tutaj. Według inspektora tożsamości widoku jest to „Widok niestandardowy” (a nie zwykły „UIView”, który nie ma tych właściwości). A gdyby widok nie był „Widokiem niestandardowym”, te dające się zaprojektować właściwości nie pojawiałyby się w Inspektorze atrybutów, prawda? Ale kiedy Interface Builder próbuje zastosować te atrybuty do widoku, wraca do myślenia, że klasą widoku jest „UIView” i nie może zastosować atrybutów.
Jakaś pomoc? Daj mi znać, jeśli pominąłem kilka ważnych szczegółów, ale ze względu na to, co jest warte, dokładnie postępowałem zgodnie z tym samouczkiem (poza ObjC vs Swift). Warto również zauważyć, że śledziłem ten samouczek dokładnie na innej maszynie i działał jak urok (zamierzałem napisać ten post wczoraj wieczorem, ale komputer, na którym byłem wtedy, nie miał tego problemu).
Na podstawie komentarzy zasugerowano, że być może .mplik nie jest dołączony i to może być przyczyną problemu. Myślałem, że na pewno zrobię wszystko, co w mojej mocy, aby ten scenariusz miał miejsce, ale i tak sprawdziłem.
Kiedy po raz pierwszy zacząłem to robić, zdawałem sobie sprawę, że te IB_DESIGNABLEzajęcia muszą być częścią innej UIKitstruktury. Na tym pierwszym zrzucie ekranu widać, że skonfigurowałem strukturę „CustomViews”, która ma jedną klasę CustomView. Zobaczysz tutaj również, że utworzyłem również plik OtherView, który jest identyczny z tym CustomView, że nie znajduje się w oddzielnym frameworku. Jednak identyczny problem występuje w scenorysie między obiema klasami.
Tutaj mamy zrzut ekranu wskazujący, że CustomView.mjest dołączony do zbudowania z CustomViewsframeworkiem:
Tymczasem poniższy zrzut ekranu wskazuje na kilka rzeczy:
CustomViews.frameworkjest odpowiednio uwzględniony w głównym projekcie.OtherView.mjest również dołączany jako źródło kompilacji, więc nawet jeśli coś jest nie takCustomView,OtherViewpowinno działać, jednak generuje identyczne błędy.Main.storyboardiLaunchScreen.xibsą wyświetlane jako czerwone. Nie mam pojęcia dlaczego i nie mam najmniejszego pojęcia, dlaczegoLaunchScreen.xibpowinienem (nie dotykałem tego pliku), chociaż mogę powiedzieć, że po obejrzeniu innych projektów,Main.storyboardrównież pojawia się na czerwono dla tych projektów, a ja nic nie robić zIB_DESIGNABLElubIBInspectabletam.
Próbowałem i próbowałem to teraz kilka razy. Działa za każdym razem na moim komputerze w domu - nie mogę odtworzyć problemu opisanego w tym pytaniu w domu. W pracy to nigdy nie działa. Problem opisany w tym pytaniu zdarza się za każdym razem.
Oba komputery to Mac Minis zakupione nowe w tym roku (nie nowe modele, model z końca 2012 roku). Oba komputery działają pod kontrolą systemu OS X Yosemite 10.10. Na obu komputerach działa Xcode w wersji 6.1. W domu kompilacja to (6A1052d). Dziś rano mogę potwierdzić, że na obu komputerach działają identyczne kompilacje Xcode.
Inni zasugerowali mi, że może to być zła pamięć RAM. Wydaje mi się to naciągane. Wielokrotnie restartowałem projekt, wielokrotnie restartowałem komputer. Wydaje mi się, że gdyby na komputerze mającym około 6 miesięcy była zła pamięć RAM, zobaczyłbym inne problemy i że ten problem byłby mniej spójny. Ale ten właśnie problem utrzymuje się pomimo wielokrotnego restartowania całego projektu od zera i pełnych restartów na komputerze.
Warto zauważyć, że jeśli faktycznie skompiluję i uruchomię ten projekt, niestandardowy widok z IBInspectablewłaściwościami faktycznie wyświetla się tak, jak oczekuję, że wyświetli go scenorys. Wyobrażam sobie, że tak by się stało nawet bez dyrektyw IB_DESIGNABLEi IBInspectable, ponieważ są one tworzone jako atrybuty środowiska wykonawczego zdefiniowane przez użytkownika.
