Zugriff auf IBOutlet von View 1 über Knopfdruck in View2

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

  • ThaBigD schrieb:

    Ich habe jetzt versucht deinen Code in meinem Beispiel zu übernehmen. Das UILabel heißt bei mir "textLabel". Das einzige Problem was jetzt noch existiert:

    [self.textLabel setDelegate:self]; <-- UILabel may not respond to setDelegate:

    Ich hänge das Projekt mal an, evtl. sieht jemand ja den Fehler, danach lasse ich euch damit auch in Ruhe ?( :wacko:


    Danke,
    Denis.


    Das "setDelegate" bezieht sich in meinem Beispiel auf ein UITextField nicht auf ein UILabel !!
  • Ja gut, das hab ich dann als nächstes probiert. Verknüpft ist ja alles. Habe in die IBAction des BUttons, der den Text des Labels im anderen View ändern soll mal
    NSLog(@"%@", MVC1.textLabel.text); eingebaut, was mir aber als ergebnis in der konsole immer nur Null liefert. Irgendwas muss ja trotzdem falsch sein :S
  • Leute, was ist an diesem Code Falsch:

    ich definiere in der headerdatei die property:

    @property (assign) NSString *string;

    und rufe sie in beiden implementierungsfiles wieder mit @synthesize string; ab.

    Ich kann nun per string = @"blabla"; einen Textstring zuweisen, der nach der Zuweisung auch als solcher erkannt wird (NSLog), jedoch wird er NICHT an den anderen Programmteil, sprich den anderen viewController übergeben. In der Funktion viewDidAppear des anderen viewControllers liefert NSLog("%@", viewController2.string); immer das ergebnis "(null)".

    ;(
  • Du hast gleich 2 Fehler drin.

    1) must Du wenn Du den String nicht per alloc intialisierst, die property als retain oder coyp deklarieren. Sonst ist sie nur innerhalb der Methode gültig wo Du sie zuweist

    2) Must Du bei der Zuweisung auch den Setter benutzen also: self.string=@"blabla"

    und zu guter Letzt wieder der Rat: Ließ die Einführenden Guides zu Obajectiv-C. Dort wird das alles erklärt.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    1) must Du wenn Du den String nicht per alloc intialisierst, die property als retain oder coyp deklarieren. Sonst ist sie nur innerhalb der Methode gültig wo Du sie zuweist

    Das ist ein Fehler, richtig. Die Begründung ist aber verkehrt. Welchen Speicherverwaltungstyp eine Property bekommt, hängt nicht davon ab, wie die Werte erzeugt werden. (Übrigens werden alle Heap-Objekte über alloc-init erzeugt.)

    String-Properties sollten in der Regel den Typ copy bekommen, damit
    1. die Property den Wert hält und
    2. die Propertywert gegen Änderungen von Außen (durch mutable Strings) abgesichert ist.

    Last but not least sollten die Speicherverwaltungsmethoden retain, release und autorelease niemals an Properties gesendet werden, da das zu Speicherverwaltungsfehlern oder einer chaotischen Speicherverwaltung führt.
    „Meine Komplikation hatte eine Komplikation.“
  • Verstehe ich nicht:

    Quellcode

    1. @property (assign) NSString *strinfg1;
    2. @property (copy) NSString *string2;
    3. ...
    4. self.string1=[[NSString alloc] initWithString:@"blabla"];
    5. self.string2=@"blabla";
    6. ...
    7. [string 1 release];
    8. [string 2 release];
    Alles anzeigen


    ist doch beides koorekt. Auch wenn das erste sicher nicht die feine Art ist.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Oh, ich meinte natürlich die 1. Property.

    Wie stabil ist die Property string1 beispielsweise bei Zuweisungen über KVC? Da wirst Du in der Regel Lecks erzeugen. Wenn Du eine Property haben willst, die ihre Werte hält, dann verwende auch retain oder copy. Dazu sind sie schließlich da. Wenn Du assign verwendest, sagst Du ja dem Verwender der Property, dass das Objekt den Wert nicht hält. Auch daran solltest Du Dich halten.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Oh, ich meinte natürlich die 1. Property.

    Wie stabil ist die Property string1 beispielsweise bei Zuweisungen über KVC? Da wirst Du in der Regel Lecks erzeugen. Wenn Du eine Property haben willst, die ihre Werte hält, dann verwende auch retain oder copy. Dazu sind sie schließlich da. Wenn Du assign verwendest, sagst Du ja dem Verwender der Property, dass das Objekt den Wert nicht hält. Auch daran solltest Du Dich halten.


    Also ist es für den, von mir geschriebenen Fall, nicht falsch sondern nur unschön weil sehr leicht zu Folgefehlern führen kann. Und genau das habe ich geschrieben. Irgendwie wird mir hier immer alles im Mund rumgedreht.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Also ist es für den, von mir geschriebenen Fall, nicht falsch sondern nur unschön weil sehr leicht zu Folgefehlern führen kann.

    Nein, es ist falsch, weil Du Dich nicht an die Konventionen hältst. Es bleibt auch falsch, wenn Dein Programm absolut stabil läuft. Ex falso quodlibet.

    Thallius schrieb:

    Und genau das habe ich geschrieben. Irgendwie wird mir hier immer alles im Mund rumgedreht.

    Das ist eine sehr interessante Feststellung. Was meinst Du genau damit?
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Thallius schrieb:

    Also ist es für den, von mir geschriebenen Fall, nicht falsch sondern nur unschön weil sehr leicht zu Folgefehlern führen kann.

    Nein, es ist falsch, weil Du Dich nicht an die Konventionen hältst. Es bleibt auch falsch, wenn Dein Programm absolut stabil läuft. Ex falso quodlibet.

    Thallius schrieb:

    Und genau das habe ich geschrieben. Irgendwie wird mir hier immer alles im Mund rumgedreht.

    Das ist eine sehr interessante Feststellung. Was meinst Du genau damit?


    Dann betrachte mich halt als den Che Guevara der Programmierer. Für mich ist ein Fehler nur ein Fehler und damit falsch, wenn er zur Fehlfunktion der Software führt. Konventionen sind das was der Name schon sagt: Konventionen:

    Eine Konvention (lat. conventio „Übereinkunft, Zusammenkunft“) ist eine nicht formal festgeschriebene Regel, die von einer Gruppe von Menschen aufgrund eines Konsenses eingehalten wird

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Dann betrachte mich halt als den Che Guevara der Programmierer.

    Ach das Pop-Model auf den T-Shirts.

    Thallius schrieb:

    Für mich ist ein Fehler nur ein Fehler und damit falsch, wenn er zur Fehlfunktion der Software führt.

    Machst Du das beim Gleitschirmfliegen auch so?

    Thallius schrieb:

    Konventionen sind das was der Name schon sagt: Konventionen:

    Eine Konvention (lat. conventio „Übereinkunft, Zusammenkunft“) ist eine nicht formal festgeschriebene Regel, die von einer Gruppe von Menschen aufgrund eines Konsenses eingehalten wird

    Die Konventionen von Apple sind aber schon recht formal.
    „Meine Komplikation hatte eine Komplikation.“
  • Mir geht es hier um die Definition von "Falsch".

    Und nach Deiner Definition ist alles was nicht konventionell ist falsch. Das fände ich aber sehr traurig wenn das so wäre und wenn alle so denken würden, würden wir heute noch in Höhlen leben und die Frauen an den Haaren hinter uns herschleifen (wobei letzteres schon seinen Reiz haben könnte ;) )

    Für mich ist das Wort unkonventionell nämlich erstmal total wertfrei. Und was anderes ist es nicht wenn ich mich nicht an die Konventionen halte.
    Du kannst gerne sagen "Es ist falsch sich nicht an die Konvetionen zu halten" und damit wären wir in den meisten Fällen sogar einer Meinung, aber Du kannst nicht sagen "Das ist Falsch weil es nicht nach Konvention ist".

    Und genau das meine ich auch mit "Worte im Mund umdrehen". Es geht hier teilweise sehr spitzfindig zu (Siehe auch Amin sein Kommentar bezüglich meiner zwei in Großbuchstaben markierten Worte" den ich einfach mal so stehen lasse) und das finde ich unnötig.
    Man kann durchaus erst einmal versuchen das Geschriebene seines Gegenüber so zu verstehen das es einem richtig erscheint und dann, wenn man es für nötig hält, dieses zu ergänzen so das es seinen eigenen (z.B.höheren Ansprüchen an theoretischer Rhetorik) genügt.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Es geht hier aber nicht um Höhlenmenschen und auch nicht um die Gesellschaft sondern um Technik. Daran hinkt Dein Vergleich. Ein unkonventioneller Mensch ist im besten Fall extrem kreativ und im schlimmsten Fall nervtötend.

    Die unkonventionelle Anwendung von Speicherverwaltungsregeln ist zeitfressend, fehleranfällig und nervtötend und ich nenne das auch einfach falsch.
    „Meine Komplikation hatte eine Komplikation.“
  • "Richtig" und "falsch" gibt es im engeren Sinne nur in der formalen Logik (Nachtrag: und in der Ethik).

    Ist es falsch, sich in der Nase zu bohren? Nein. Ist es falsch, nackt in der Fußgängerzone herumzulaufen? Nein. Ist es valsch, falsch mit v zu schreiben? Nein.

    Ist es falsch, mit seinem neuen Maserati auf der A1 im Feierabendverkehr entgegen der vorgeschriebenen Fahrtrichtung Vollgas zu geben? Formal nicht. Es ist StVO- (und wahrscheinlich auch StVG-)widrig. Trotzdem kann es unangenehme Folgen haben. Die meisten Menschen, die ich kenne, würden es vermutlich vermeiden, obwohl es im Sinne der formalen Logik nicht falsch ist.

    Zurück zum Programmieren: Ich kann alle Compiler-Warnungen ignorieren, das ist nicht falsch, nur saublöd. Ich kann mich sogar dazu entschließen, hinter Statements kein Semikolon mehr zu setzen. Das ist nicht falsch, es entspricht nur nicht mehr der Syntax der Programmiersprache.

    Also, bitte: Einfach mal "falsch" durch "problematisch" und "richtig" durch "sinnvoll" ersetzen. Dann kann man sich immer noch toll um alles Mögliche kloppen (da bin ich immer gerne dabei), aber es ist nicht mehr ganz so unsinnig.

    Jetzt der eigentliche Senf: Konventionen darf man brechen. Aber man sollte einen guten Grund dafür haben. Gibt's in diesem Fall einen guten Grund?
    Multigrad - 360°-Produktfotografie für den Mac
  • @mattik: Dann gibt es also kein falsch und richtig, sinnvoll? Der Code hier im Forum ist also entweder problematisch oder sinnvoll?

    Aber ich finde es auch problematisch, etwas problematisch zu nennen. Das hört sich unpositiv an. Sagen wir doch lieber unsinnvoll, gerne mit Doppelplus davor, dazu. Also etwas Falsches ist Unsinn. Gut, darauf können wir uns einigen. ;) +scnr+

    (Aber mich bitte nicht problematisch verstehen.)
    „Meine Komplikation hatte eine Komplikation.“