.wav zu NSData

Und weil sie dir einen existierenden Pfad zurückgibt.

Ha ha,

oki seit mittlerweile 30Jahre wird ein Slash als Trenner benutzt. Sich deswegen aufzuhängen... naja aber unter Beachtung das morgen als Trenner nicht mehr ein Slash sondern das "Ü" herhalten muss ist das Vernünftig.

2..: Macht schon eher Sinn. Dennoch bin ich mit der anderen Variante gut gefahren. Liegt wohl auch daran, das ich Projekte recht selten nachträglich umstrukturiere.

Es ist zwar angenehme das er , zur Not die Datei in den .lproj - Verzeichnis sucht - nur das finde ich ein wenig schwammig. In C gabs so etwas auch nicht und wir haben es auch überlebt.

Bezüglich der Lokalisierungen das währe dan schon richtig. Bei uns heißen aber Dateien dann auch anders - der Ordnung halber.

Einzig interessante daran: pathToResource ist case sensitive.

Nicht unter Mac OS 9 und kleiner, da war es der Doppelpunkt …

Die Methode pathForResource:ofType: hat noch eine weitere Annehmlichkeit. Sie kann nämlich auch unterschiedliche Resourcen finden, abhängig vom Gerät (iPhone oder iPad).
Beispiel:

[[NSBundle mainBundle] pathForResource:@"Beispiel" ofType:@"bla"];

findet auf einem iPhone/iPod: Beispiel~iphone.bla
und auf einem iPad: Beispiel~ipad.bla

Michael

Ja ,da hab ich was angezettelt Ich war auf dem iPhone als ich pathForResource geschrieben habe, dabei wollte ich noch forType: dranhängen, hab aber ausversehen schon auf absenden geklickt

Was heißt war. Der Pfadtrenner wird vom Dateisystem bestimmt und der ist bei HFS+ der Doppelpunkt. Versuch mal in einem SavePanel einen Doppelpunkt mit in den Dateinamen einzugeben. Da macht Dir OS X gleich ein '-' draus. OS X versteckt den Doppelpunkt nur hinter dem Slash.

Michael

Und abgesehen davon, dass die Lösung von gritsch die Sauberste ist und die von Kismet null Vorteile hat, sollte man Pfade sowieso über stringByAppendingPathComponent: zusammenkleben.

Oki ich habe mich beim Pfad-Trenner nicht auf das Apple-Habitat bezogen....

Und seit mittlerweile 14 Jahren macht Apple das anders.