Xcode func in ViewDidLoad aufrufen

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

  • Xcode func in ViewDidLoad aufrufen

    Hallo zusammen,
    ich möchte folgende func automatisch ausführen lassen, wenn der View geladen wird.

    Quellcode

    1. func an_aus() {
    2. if visible3.text == "aus" {
    3. mySwitchOn()
    4. }else
    5. {
    6. mySwitchOff()
    7. }
    8. }

    in die ViewDidLoad habe ich es so geschrieben

    Quellcode

    1. override func viewDidLoad() {
    2. an_aus()
    3. }
    aber es passiert nichts ?
    Hat jemand einen Tipp für mich?
    Danke Klaus
    ich bin ein absoluter Anfänger und programmieren ist das nicht was ich mache :thumbsup:
  • Thallius schrieb:

    Strings mit == vergleichen geht gar nicht...

    ioscampus schrieb:

    Dann solltest du dich schlau machen (= googeln oder im Buch nachschlagen) wie man Strings vergleicht.
    Vielleicht solltet ihr euch erst einmal mit Swift beschäftigen, bevor ihr Fragen zu Swift Code beantwortet. Könnte sonst peinlich werden.


    funboxbolzer schrieb:

    Hat jemand einen Tipp für mich?
    Wird denn viewDidLoad() aufgerufen?
  • die ViewDidLoad wird ausgeführt.
    das kann ich bestätigen
    die weiteren Funktionen tun auch das was sie sollen. Wenn ich die Befehle durch einen Button ausführen lasse, wird alles aufgeführt wie es soll.

    Ich habe mir jetzt einen NSTimer erstellt, der dann die Funktionen in der ViewDidLoad ausführt, das geht auch.
    Da ich ja ein Absoluter NOOB bin habe ich mir diesen Umweg ausgedacht.
    Falls doch jemand noch einen Tipp für mich hat würde ich mich freuen.
    ich bin ein absoluter Anfänger und programmieren ist das nicht was ich mache :thumbsup:
  • funboxbolzer schrieb:

    func an_aus() {
    if visible3.text == "aus"
    erst mal nichts zur Frage, aber als Anfänger kannst du hoffentlich von konstruktiver Kritik profitieren - und in den zwei Zeilen gibt es gleich drei Dinge, die zumindest diskussionswürdig sind:
    1) Sprachen mischen (also in diesem Fall Deutsch und Englisch... nicht C und Swift ;)
    Mehr oder weniger Geschmacksache, aber ich denke die Mehrheit (in dem Fall zähle ich mich ausnahmsweise mal dazu) macht einfach alles in Englisch; statt an_aus also etwa toggle...
    2) das leitet gleich zum nächsten Punkt über - sprechende Namen:
    "an_aus" und "visible3" sind etwas besser als "funktion12" und "textfeld8", aber nicht viel; gut, die Auto-Vervollständigung streikt vielleicht manchmal ;-), aber auf lange Sicht macht es Sinn, aussagekräftige Namen zu wählen
    3) Textfelder und String-Konstanten
    Wenn es "aus" und "an" gibt, dann ist ein Textfeld mit an Sicherheit grenzender Wahrscheinlichkeit nicht das optimale GUI-Element. Generell ist es schlecht, den aktuellen Status von GUI-Text abhängig zu machen - auch wenn ein extra Bool oder Enum zunächst nach mehr Aufwand aussieht funktioniert das auch, wenn man die App in eine andere Sprache übersetzt.
    Ausdrücklich nicht diskutiere ich über Unterstriche:
    Dass die an so vielen Stellen in Swift benutzt werden ist schon schlimm genug, Methoden werden in CamalCase benannt.

    Thallius schrieb:

    Strings mit == vergleichen geht gar nicht..
    Um's noch mal klar zu sagen: Doch ;)
    Swift räumt schließlich auf mit den C-Altlasten, und dazu gehört neben den Collections auch die Prüfung auf Gleichheit. Zum Ausgleich gibt's noch "===" zusätzlich ;)

    Waffeln schrieb:

    Ich finde man kann immer gut mit print() rausfinden/nachvollziehen was grad passiert wenn man keinen Breakpoint setzen will.
    Davon rate ich dringend ab:
    Wir können froh sein, nicht auf solche Krücken angewiesen zu sein. Die sorgen letztlich nur dafür, dass selbst die Release-Version im Appstore Logfiles produziert, in denen man die versehentlich reingerutschten Passwörter nur deshalb nicht sofort sieht, weil sie in der riesigen Menge von Debug-Infos untergehen...
    Die Breakpoint-Verwaltung in Xcode ist leider nach wie vor in einem desolaten Zustand, aber Breakpoints sind in fast allen Fällen die richtige Antwort, und print ist nur der bequeme Notnagel.