Die Warnung hat damit nix zu tun. Sie sagt Dir nur, dass Deine bevorzugte Tastatur nicht genutzt werden kann und (ein Überbleibsel aus Objective-C, als man noch nicht jede Kleinigkeit mit einer Exception oder einem Compilefehler quittiert hat) fällt auf eine als Standard definierte Tastatur zurück.
Sie ist lediglich so freundlich Dich darauf hinzuweisen.

Zum eigentlichen Problem:
Wie ist Dein PickerView konfiguriert?
Wenn automatisch Zeile 0 ausgewählt ist, muss die Delegate Methode nicht feuern, wenn Du selbst noch mal auf die erste Zeile (Zeile 0) tippst.

Wird Deine txtEditingChanged Methode eigentlich überhaupt aufgerufen?
Und wenn ja von wem?
Wieso hängt die eigentlich als inline-Funktion im if-Zweig?

Das scheint mir kein Swift Problem, sondern ein Design Problem.
Welche einführende Literatur nutzt Du?

One more thing:
Unicode in deutschen Variablennamen nutzen aber abkürzen ist echt mal seltsam.
grdmaß statt gradmaß statt degreeMeasure?
frsthö statt firsthöhe statt ridgeHeight?
traufehö statt traufhöhe statt eavesHeight?
Vordachlänge und Dachneigung haben sicherlich auch international nutzbare Äquivalente.
Was sollen eigentlich okfpf und okfipf sein? Und was noch viel wichtiger ist: Weißt Du das in einem halben Jahr immer noch?

Also dass es was mit Zimmerei/Holzbau im Allgemeinen und Dächern im Besonderen zu tun hat dachte ich mir fast.
Da waren so Schlüsselworte wie // Traufehö-Vordach-Neigung oder 2016-01-03 22:35:41.029 Zimmerei und Holzbau[5917:4003335] versteckt.

Zurück zum Thema.
Müsste dann Kapitel 16.4 und 16.5 nicht genau das sein, was Dir in dem Fall weiterhelfen kann?
(Wobei der Herr Kofler für seinen 'CurCalc' Objektnamen gesteinigt, geteert und gefedert gehört. Lesen Sie das, Herr Kofler? Gesteinigt, Geteert und Gefedert! Und auf dem Rathausmarkt vorgeführt. 'CurrencyCalculator', bitteschön. Eventuell auch 'CurrencyConverter', je nachdem, was das Ding tatsächlich tut.)

Du könntest es swift machen und in Deine func pickerView(pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) { eine Ausgabe von row und component machen. Vor Deiner Abfrage.
Dann selektierst Du fröhlich im Pickerview umher und siehst in der Konsole von Xcode sofort, wann die Methode greift und was Du ausgewählt hast.

Du könntest es auch richtig machen und in der ersten Zeile nach func pickerView(pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) { einen Breakpoint setzen. Vor Deiner Abfrage.
Dann selektierst Du fröhlich im Pickerview umher und siehst sofort, wann die Methode greift und erkennst in der Instanzvariablenansicht von Xcode, was Du ausgewählt hast.

Bekommt myLabel überhaupt den richtigen Wert, nachdem Du im PickerView frühlich herumselektiert hast?
Falls nicht kannst Du Dir den ersten Start nach Einpflegen des swiften oder richtigen Weges sparen und musst erst mal das Delegate mit dem PickerView richtig verdrahten.
(Also an geeigneter Stelle pickerview.delegate = self, so wie es hoffentlich auch im Buche steht.)

Nein, das ist überhaupt nicht notwendig, schon gar nicht zwingend.
Es erleichtert Dir lediglich die zukünftige Arbeit (man liest häufiger alten Code als das man neuen Code schreibt. Viel häufiger) und uns eventuelle Hilfestellungen.
Was mit ö geht, geht übrigens auch mit Smilies, vereinfachtem Chinesisch oder Kyrillisch. Wenn Dir ein indischer Dienstleister Code erstellt, bei dem die Variablen in Devanagari notiert sind, dann finde Dich da erst mal zurecht.

Die Lektüre sieht zumindest vom Inhaltsverzeichnis und der Leseproben her gut aus.

Wenn die Felder inaktiv werden, dann läuft Deine Delegate Methode korrekt und es wird (wie angenommen) nicht in die inline Funktion txtEditingChanged(sender: UITextField) { gesprungen.
Oder die Abfrage ist nicht erfüllbar.

if grdmaß.editing && frsthö.editing { besagt ja, dass beide Textfelder gleichzeitig im Editiermodus sein müssen - das stelle ich mir doch etwas schwer umsetzbar vor.

Ich denke, Deine Delegatemethode für die Textfelder ist da einfach völlig fehl am Platz.
Setz das als Funktion außerhalb dieser Pickerview Delegate Methode, achte darauf, dass die Textfelder im Interface Builder ihr entsprechendes Event mit dieser Funktion verbunden haben und üb ein bisschen mit den Breakpoints.

Dann findest Du bestimmt heraus, ob Deine If-Bedingung greift und wie Du weiter vorgehen kannst.
Dass in dem Buch von Versionsverwaltung mit Git geschrieben wird ist löblich, dass Debugging in Xcode außen vor gelassen wird hingegen unverständlich.
Funktioniert Debugging von Swift denn nicht?

Am Besten besorgst Du Dir schnell das Apps programmieren für iPhone und iPad.
Das kümmert sich nicht so sehr um Swift (also viel Objective-C drin, aber auch ein kleiner Swift Teil) sondern vielmehr um das 'wie' bei der Entwicklung.
Ganz akut rate ich Dir zu Kapitel 3.6 der alten, Objective-C only Fassung, da es die als kostenloses Openbook gibt:
openbook.rheinwerk-verlag.de/a…d0-4f94-a46f-35d68214ab45

Das wird Dir sicherlich bei Deinem Selbststudium helfen.
(Der Clemens Wagner springt hier auch rum, da isses einfacher mit dem Steinigen, Teeren und Federn, wenn da Mist drin stünde - was es nicht tut.)

? und welchen?
nicht wirklich

Ja, es dürfte daran liegen, dass einige Outlets oder Actions nicht verbunden wurden. Da solltest Du dringend herausfinden, warum er die Annotations nicht anerkennt. Scheint mir die Wurzel des Übels zu sein.

Und natürlich kannst Du die Rechenfunktion auslagern. Du kannst das zu Tode wegoptimieren.
Solltest Du aber erst mal sein lassen.

Wie bitte was?

Häng mal nen Screenshot an bitte.

du weißt aber was du mit einer IBAction tust ? ... das wäre auch schlimm, wenn es funktionieren würde.

Stichwort @IBAction func


warte auf das Buch oder wühl dich durch das Internet.

Das ist wirkliches Grundlagen erklären.

scheint wohl am Namen zu liegen, kenne ich


nope.

warum möchtest du eine Funktion in einer Funktion implementieren?

if-schleife.de


das kommt drauf an, was du vorhast