Rückgabe des NSOpenPanel falsch?

[michael m.]

Hi,

ich habe eine Methode geschrieben, die mir den Pfad der SD-Karte mit Hilfe eines NSOpenPanels zurück gibt.
Leider funktioniert der Pfad nicht, weil dort anstatt von "Leerzeichen" das hier "%20" eingesetzt wird.
Das komplette Ergebnis welches zurück gegeben wird sieht so aus.

Die erste URL: file:///Volumes/NO%20NAME/GRAPHV1/DATA/

Ich weis jetzt nicht wo ich noch nachschauen soll. Vielleicht sieht ja jemand eine mögliche Fehlerquelle?

-(IBAction)auswahlSdKarte:(id)sender {
    // Ein Öffnen Pannel wird erzeugt
    NSOpenPanel *ladePanel = [NSOpenPanel openPanel];
    // deaktiviert die option mehrere Objekte auswählen zu können
    [ladePanel setAllowsMultipleSelection:NO];
    // Titel des Dialogfeldes für die Aufgabe festlegen
    [ladePanel setTitle: @"Pfad zur SD-Karte auswählen"];
    [ladePanel setCanChooseDirectories:YES];
    [ladePanel setCanCreateDirectories:NO];
    [ladePanel setCanChooseFiles:NO];
    
    // Aufruf (runModal) des Dialogfensters Laden
    if ([ladePanel runModal] == NSModalResponseOK) {
        // Liefert ein Array-Objekt mit den vollständigen Pfadnamen der ausgewählten Dateien
        NSArray *ladeURLs = [ladePanel URLs];
        // Da nur eine Auswahl möglich war, wird die erste Datei im Arrray ermittelt
        NSURL *ersteURL = [ladeURLs objectAtIndex:0];
        NSLog(@"Die erste URL: %@", [NSString stringWithFormat:@"%@", ersteURL]);
        // Der String wird in die Variable gespeichert
        pfadSD = [NSString stringWithContentsOfURL:ersteURL encoding:NSUTF8StringEncoding error:nil];
        // Der String wird im Label ausgegeben
        [tfSdKarte setStringValue:pfadSD];
        
        NSUserDefaults *einstellungen = [NSUserDefaults standardUserDefaults];
        [einstellungen setObject:pfadSD forKey:@"pfadSD"];
        [einstellungen synchronize];
    }
}

Vielen Dank
Michael

 

[ProjectBuilder]

in URLs wird das Leerzeichen mit %20 kodiert, das ist schon richtig so.

 

[little_pixel]

Du verstehst die Angabe des Pfades in NSURL falsch.
Du "konvertierst" das URL-Objekt zu NSString. Das ist falsch.
Was Du suchst ist [URL path]. Diese Methode liefert Dir einen Pfad als Text.

Um das Encoding musst Du Dich gar nicht kümmern.

Eigentlich müsstest Du erkannt haben, dass Apple sich immer mehr von Pfaden als Text entfernt und nur noch auf NSURL setzt.

Deshalb wäre es klüger, wenn Du auch Deine Klassen entsprechend implementierst.
Dann sparst Du Dir immer die Hin- und Rückfahrkarte.

Viele Grüße

 

[michael m.]

Das liegt daran, das in den Büchern die ich habe, alle Dateioperationen mit Strings gemacht werden. Ich habe mich schon gewundert, warum das immer hin und her gewandelt wird. Ich dachte, das es mit den Dateinamen zu tun hat, damit man das vergleichen und prüfen kann.

Das Problem ist, das man für OBC veraltete Literatur findet und wenn man noch nicht so viel Ahnung hat, macht man das halt so.
Ich habe mittlerweile mein kleines Progrämmchen 3 mal neu gemacht und mit mehr wissen, sah da ganze dann immer anders aus.

Wo jetzt Swift auch draussen ist, schein auch keiner mehr OBC Bücher zu schreiben und scheinbar für OSX nichts wirklich hilfreiches da ist. Alles stürzt sich nur noch auf iOS Entwicklung aber OBC ist ja für iOS und OSX gleich zu verwenden.

Auf jeden fall finde ich es toll, das man hier im Forum so eine tolle Hilfe bekommt und dann mach das lernen noch mehr Spass.

Viele Grüsse
Michael

 

[ProjectBuilder]

Swift kannst du übrigens auch für OS X verwenden (falls dich das bis dato von Swift abgehalten hat)

 

[michael m.]

Ich wusste schon das man Swift auch für OSX verwenden kann. Mir hat man allerdings angeraten Objective-C zu erlernen und später Swift.
Allerdings gab es da noch keine Bücher als ich angefangen hatte. OBC zu verstehen begann ich aber erst, nachdem ich in Java eingestiegen bin.

 

[little_pixel]

Ich habe mittlerweile mein kleines Progrämmchen 3 mal neu gemacht und mit mehr wissen, sah da ganze dann immer anders aus.

Mache es in drei Jahren nochmals neu, wenn Du am Ball bleibst.
Wahrscheinlich bist Du in 10% der Zeit fertig, mit viel effizienteren und vor allem weniger und "recyclebaren" Code.
Auch Dein Stil wird sich eklatant verbessern - nicht so Kraut wie jetzt ;-)

Das ist eben Erfahrung und das ist der Wert den viele nicht erkennen, wenn sie die Zeit bezahlen müssen.
Wenn ich zu jemandem sage, dass ich für die Programmierarbeit von zwei Stunden 200 Euro möchte (nur für bestimmtes Sachen und mit enormen Zeitdruck), dann heißt es "was???".
Aber man kauft eben nicht nur die zwei Stunden, sondern die Expertise dahinter.

Aus dem Nähkästchen geplaudert:

Mich hat mal ein Interessent angerufen, der ne kleine App programmiert haben wollte.
Ich habe vier Tage geschätzt und mein Preis vorgeschlagen. Kurze Zeit später habe ich ne Absage via Email erhalten, dass ich definitiv zu teuer sei und das aus seiner Sicht nicht verhältnisgemäß.

Über ein Jahr später hat er mich wieder angerufen und mir seine Erfahrung geschildert.
Er hat die Anwendung zwei Mal in Auftrag gegeben und beide male konnten die Entwickler ein Kernproblem nicht lösen.
Geld wollten sie natürlich trotzdem, auch wenn nur anteilig.

Ich habe seine Anwendung dann in drei Tagen erstellt und somit habe ich ihm auch im Preis nachgelassen.

Seine Konsequenz aus der Sache:
Ach auch bei Programmierarbeiten gibt es Qualität und wer billig kauft kauft mehrmals.
Und mit den am Ende drei Tagen war ich sogar günstiger als das Angebot der anderen günstigen Anbieter von sieben Tage.
Der Tagessatz war wesentlich tiefer, aber sie haben mehr Zeit rausholen wollen.

Bisschen Smalltalk…
Wenn Du in fünf Jahren noch immer Programmierer/Entwickler bist, dann wirst Du sicherlich mal daran denken und wahrscheinlich selbst die Erfahrung gemacht haben

Viele Grüße

 

[michael m.]

Lernphasen sind Schwierig und dauern, aber wenn man es dann mal kann ist man froh.

Ich selbst habe für mein grösseres Projekt einige Programmierer angefragt und nachher habe ich fest gestellt was für luschen das waren.
Erst hies es immer geht nicht und nachher waren die überhaupt nicht mehr erreichbar ?!??!

Ich habe festgestellt, das man sich nur auf sich selbst verlassen kann.


Habe jetzt mal ein paar Strings in NSUrls programmiert und da die Existenzprüfungen String-Werte habe wollten, habe ich das mit path kompensiert.

fileExistsAtPath:[pfadProgramm path]

Wie ist es denn wenn ich jetzt eine Datei prüfen möchte wie "//users/michael/Documents/BenutzerDaten.plist" ?
wird es dann immer noch als NSUrl deklariert?

Danke
Michael

 

[little_pixel]

-checkResourceIsReachableAndReturnError:

Viele Grüße