„Normalny” UIButton powodujący wyjątek obj_stack_overflow lub EXC_BAD_ACCESS

Z pewnością wygląda wystarczająco niewinnie. W moim Delegacie aplikacji sprawdzamNSUserDefaults po flagę, aby pokazać wskazówki przy starcie. Jeśli tak, to pod koniecapplicationDidFinishLaunching:, Robię to:

TipsViewController *vc = [[TipsViewController alloc]
  initWithNibName:@“TipsView" bundle:nil];
[window addSubview:vc.view];
[vc release];

Pomysł polega na tymczasowym wyświetleniu tego widoku. (Zauważ, że nie jest to modalny VC. Brak kontrolera nawigacji w tym punkcie, a poza tym nie ma paska nawigacji w tym widoku).

Po odrzuceniu tego widoku dodamy nasze uprzedzoneUITabBarControllerWidok okna i przejdź do niego, a następnie usuń widok końcówki z głównego okna. Jeszcze nie dotarłem do punktu zwolnienia, ponieważ czytaj dalej.

VC My TipsView jest połączony mniej więcej tak:

UIView -> view -> File’s Owner (TipsViewController)
  UIImageView -> background image
  UIView -> tipView -> File’s Owner
    UIImageView -> background image
    UIScrollView
      UILabel (tip text)
    UIButton -> touch-up-inside -> -(IBAction)button1:
    UIButton -> touch-up-inside -> -(IBAction)button2:
    UIButton -> touch-up-inside -> -(IBAction)button3:

Źródło zawiera deklaracje i definicje dla wszystkich trzechIBAction połączenia. W tej chwili dwóch z nich nic nie robi. Trzeci zmienia końcówkętext, zmienia rozmiar, aby dopasować, i dostosowuje widok przewijaniacontentSize dopasować.

Po uruchomieniu aplikacjiTipsViewController widok wygląda dobrze. Mogę nawet przewijać tekst końcówki. Jednak kiedy wyzwalam touch-up-inside na dowolnymUIButton, Xcode zaczyna mnie umieszczać w źródle (gdzie umieściłem punkt przerwania na każdym z nich)IBAction)… A potem rezygnuje z aEXC_BAD_ACCESS lubobj_stack_overflow.

Porównałem to z innymi częściami aplikacji, w których mam VC, widok i przyciski. Jest identyczny pod każdym względem, z wyjątkiem tego,Dodałem widok VC jako widok podrzędny okna aplikacji, zamiast wpychać VC do kontrolera nawigacji. PonadtoZobacz przewodnik programowania sterownika dla systemu iPhone OS doktorzy mówią, że to uczciwa gra:

Jeśli używasz kontrolera pojedynczego widoku w swojej aplikacji, dodajesz jego widok do okna zamiast dodawać kontroler widoku do paska kart lub kontrolera nawigacji.

Prawda, jarobić miećUITabBarController czekając na skrzydłach, i ma zakładkiKontrolery UINavigationControl (i inne VC). Jeśli jednak wyświetlany jest widok końcówki, widok kontrolera paska kart ma widoknie jeszcze dodano do okna. Zamiarem jest zamiana go po zakończeniu pokazywania wskazówek. Innymi słowy, dla wszystkich intencji i celów tymczasowo zachowujemy się tak, jakbyśmy mieli w grze pojedynczego VC. Następnie przełączamy się na pasek kart i zbijamy końcówkę VC.

Może robię coś subtelnie źle? Czy jest lepszy sposób? („Musi być lepszy sposób!”)

Przykładowy ślad stosu:

#0  0x992b6f52 in objc_exception_throw
#1  0x302d6ffb in -[NSObject doesNotRecognizeSelector:]
#2  0x3026e056 in ___forwarding___
#3  0x3024a0a2 in __forwarding_prep_0___
#4  0x308f79d1 in -[UIApplication sendAction:to:from:forEvent:]
#5  0x309598b1 in -[UIControl sendAction:to:forEvent:]
#6  0x3095bad2 in -[UIControl(Internal) _sendActionsForEvents:withEvent:]
#7  0x3095a81e in -[UIControl touchesEnded:withEvent:]
#8  0x30910fdf in -[UIWindow _sendTouchesForEvent:]
#9  0x308faecb in -[UIApplication sendEvent:]
#10 0x309013e1 in _UIApplicationHandleEvent
#11 0x32046375 in PurpleEventCallback
#12 0x30245560 in CFRunLoopRunSpecific
#13 0x30244628 in CFRunLoopRunInMode
#14 0x32044c31 in GSEventRunModal
#15 0x32044cf6 in GSEventRun
#16 0x309021ee in UIApplicationMain
#17 0x00002888 in main at main.m:14

Jak widać ze śladu, kończymy nadoesNotRecognizeSelector: … Z wyjątkiem tego, że wyraźnie widzę metody w moim źródle końcówki VC. Ponadto wszystkie są okablowane. (Brak wielu przewodów lub czegoś podobnego w IB. Wszystko tam wygląda dobrze, aż do relacji właściciela pliku.)

Wskazówki mile widziane / doceniane!

questionAnswers(1)

yourAnswerToTheQuestion