2012-11-05 11 views
6

In einer UITableViewCell-Unterklasse überschreibe ich layoutSubviews, weil ich die Frames einiger Subviews berechnen muss. Die Basis für alle meine Berechnungen ist die Breite der Inhaltsansicht. Dies ist, wie der Anfang meiner Implementierung von layoutSubviews wie folgt aussieht:Falsche contentView-Breite in benutzerdefiniertem UITableViewCell?

- (void) layoutSubviews 
{ 
    [super layoutSubviews]; // invoke this to set up the content view's bounds 

    CGFloat contentViewWidth = self.contentView.bounds.size.width; 

    [...] // calculate and assign frames to subviews 
} 

ich begonnen haben, testen diese in einer gruppierten Tabellenansicht im iPhone-Simulator. Die Zelle sollte nur aus dem bestehen, was sich in der Inhaltsansicht befindet, d. H. Ich habe alle umgebenden Phantasiestücke ausgeschaltet. Insbesondere habe ich die Zubehöransicht deaktiviert, indem ich den Zubehörtyp auf UITableViewCellAccessoryNone eingestellt habe. Aus diesem Grund ist die Zubehöransicht ausgeblendet, obwohl ihre Grenzen/Rahmeneigenschaften immer noch eine Größe von 20/20 aufweisen.

Basierend auf all diese und die folgende einfache Darstellung, würde ich die Seitenbreite in dem obigen Codeausschnitt erwarten 300.

<----------- screen width = 320 -----------> 
+------------------------------------------+ 
|           | 
| <--- content view width = 300 ---> | 
| +--------------------------------+ | 
|<-->|   table view cell  |<-->| 
| 10 +--------------------------------+ 10 | 
|           | 
|     [...]     | 

wie berichtet werden, aber es ist nicht, Breite der Inhalt Ansicht, die ist tatsächlich gemeldet ist 270!

Ein wenig Forschung zeigt, dass die 30 fehlenden Punkte bestehen aus a) 20 Breite der Zubehöransicht und b) 10 Abstand zwischen Inhaltsansicht und Zubehöransicht. Ich habe versucht, die Größe der Zubehöransicht auf 0/0 zu setzen, der Effekt war, dass die Breite der Inhaltsansicht jetzt als 290 angezeigt wird. Etwas besser, aber immer noch 10 Punkte. Ich habe auch versucht, die accessoryView Eigenschaft auf nil zu setzen, aber die Ansicht wird einfach von [super layoutSubviews] neu erstellt.

Schließlich die Frage: Gibt es eine Möglichkeit, wirklich deaktivieren Sie die Zubehöransicht, so dass es nicht in der Berechnung der Breite der Inhaltsansicht enthalten ist? Oder wäre es sicher, das Aufrufen von [super layoutSubviews] zu überspringen und einfach die Breite selbst zu berechnen?

+0

keine Lösung, aber wenn man super hier nennen vernachlässigen verlieren Sie die gekrümmten Zell Ecken in einer gruppierten Tabelle Ansicht, so dass das keine Option ist – jackslash

+0

'LayoutSubviews' wird wahrscheinlich ein paar Mal aufgerufen, bevor die Zelle schließlich in der Tabelle angezeigt wird. Haben Sie die Größe der 'contentView' für den letzten Anruf überprüft oder sehen Sie nur den ersten Anruf? – rmaddy

+0

@rmaddy: In meinem Testfall ruft UIKit 'layoutSubviews' nur einmal auf. – herzbube

Antwort

7

Nachdem ich diese Frage erneut gestellt habe, stelle ich fest, dass ich das in der Frage beschriebene Verhalten nicht mehr reproduzieren kann. Das Verhalten wird nun wie erwartet:

  • Der Standardzubehör Stil der Zelle Tabellenansicht ist UITableViewCellAccessoryNone
  • Die accessoryView Eigenschaft gibt nil
  • Der Inhalt Ansicht Breite als 302

I berichtet Ich teste das jetzt in Xcode 4.2 auf dem iPhone 5.1 Simulator. Als ich die Frage stellte, glaubte ich, dass ich noch den iPhone 4.3 Simulator laufen hatte. Ich muss jetzt davon ausgehen, dass das Problem entweder nur im 4.3-Simulator existiert, oder aufgrund einer Xcode-Fehlkonfiguration meinerseits war, oder überhaupt erst imaginär war.

Für das Protokoll: war meine Abhilfe in layoutSubviews eine neue Breite auf den Inhalt Ansicht anzuwenden:

- (void) layoutSubviews 
{ 
    [super layoutSubviews]; 

    CGRect contentViewFrame = self.contentView.frame; 
    contentViewFrame.size.width = 302; 
    self.contentView.frame = contentViewFrame; 

    [...] 
} 
Verwandte Themen