Seltsame Vorkommnisse bei UITableView Subklasse

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Seltsame Vorkommnisse bei UITableView Subklasse

    Wenn das so weitergeht glaube ich demnächst doch noch an Gott oder was ähnliches...

    Folgende Situation: Ich habe eine Subklasse einer UITableView, nur die touches-Dinger überschrieben. Klappt soweit prima. Wenn ich nun folgende Methode hinzufüge, dann verschwinden die Zell-separier-Zeilen, schon beim Start der App, bevor ich irgendwas anrühre! Nehm ich die BOOL "didSelectRowXXX " oder die ganze Methode raus sind die Zeilen wieder da. Kompiliere ich für 2.2 ist das Problem ebenfalls weg. Mit Sachen wie "NSUInteger a = indexPath.row" hab ichs sogar geschafft, dass für einzelne Zeilen der rote "Zelle löschen" Button angezeigt wird, obwohl ich das nirgends benutze, und andere lustige Sachen.
    Meine Frage: Woran kann sowas liegen? Das muss ja fast ein Fehler seitens Apple sein, oder kann ich so krass was falsch machen? Das Phänomen tritt sogar auf, wenn die Subklasse ausschliesslich aus angegebener Methode besteht. Ich versuche zu verstehen, wie sowas möglich ist, aber ich kann mir das nicht erklären...

    Quellcode

    1. - (void) deselectRowAtIndexPath:(NSIndexPath *)indexPath animated:(BOOL)animated
    2. {
    3. [super deselectRowAtIndexPath:indexPath animated:animated];
    4. didSelectRowXXX = NO;
    5. }



    [Blockierte Grafik: http://www.hillrippers.ch/temp/UITableView%20Subclass%20Weirdness.png]
    Widgetschmie.de • Life is too short for gadgets

  • Ich kann mich daran erinnern, dass ich mit den SDK-Betas (vor dem offiziellen Start des AppStores) auch manchmal Probleme verschwindenden Tabellenseparatorlinien hatte.
    Allerdings bin ich mir ziemlich sicher, dass diese dem Update auf OS 2.0 (final) behoben waren.

    Wer weiß, vielleicht hatte Apple ein größeres Problem mit Tabellenseparatoren erst notdürftig geflickt und erst mit OS2.2 endgültig ?!?

    Wenn das Problem mit einem Testprogramm auch auf andern iPhones oder iPod touch nachzuvollziehen ist, würde ich auf jeden Fall einen Radar-Bug bei Apple anlegen.
    Bevor man jemanden kritisiert, sollte man zuerst ein paar Meilen in dessen Schuhen gehen!
    Erstens ist man dann in sicherem Abstand und zweitens hat man die Schuhe...

  • Original von psog
    Wenn das Problem mit einem Testprogramm auch auf andern iPhones oder iPod touch nachzuvollziehen ist, würde ich auf jeden Fall einen Radar-Bug bei Apple anlegen.


    Wenn das Problem mit 2.2 behoben ist, wird sich Apple da nicht weiter drum kümmern. Was interessieren Apple 2.0 und 2.1 wenn es schon 2.2. gibt. :(

  • Original von MCDan
    Original von psog
    Wenn das Problem mit einem Testprogramm auch auf andern iPhones oder iPod touch nachzuvollziehen ist, würde ich auf jeden Fall einen Radar-Bug bei Apple anlegen.


    Wenn das Problem mit 2.2 behoben ist, wird sich Apple da nicht weiter drum kümmern. Was interessieren Apple 2.0 und 2.1 wenn es schon 2.2. gibt. :(


    Jo, das denk ich auch.

    Was ich jetzt mache ist auch witzig; ich habe eine retain-te property "previousIndexPath", ein NSIndexPath, lasse die setter und getter synthetisieren. Sobald ich unter 2.0 oder 2.1 self.previousIndexPath = indexPath (indexPath ist der der gerade berührten Cell) ausführe stürzt das Programm ab, hängt sich im Setter auf. Unter 2.2 kein Problem. Wirklich seltsame Sache.
    Widgetschmie.de • Life is too short for gadgets