NSTableView einstieg

Doch, es ist ein Fehler, wie du beim Einfügen oder Entfernen sehen kannst. Ein Table-View strukturiert seine Eiinträge nach Zeilen nach Spalten, nicht umgekehrt.

glaube ich gern dass es bei dir ein 10-zeiler ist aber für einen anfänger ist das ein dicker brocken!

Gerade einen Anfänger sollte man davor warnen, gleich einen ganz falschen Weg einzuschlagen. Der kann das nämlich am wenigsten beurteilen.

auch wenn er 100 spalten und 100 arrays verwendet dann ist es noch kein fehler (aber alles andere als gut ;-))

Doch, ist es. Ein PProgramm ist nicht fehlerfrei, weil es ordnungsgemäß compiliert.

Wenn man zwei Arrays sortiert, hat meini Nachbar den Vornamen meines andderen Nachbarn und den Nachnamen von mir. Gemeinhin will man das nicht.

weil in der init-funktion das nib noch nicht geladen ist (die outlets sollten auf nil zeigen)

GUI-Elemente zu füllen etc kann man die - (void)awakeFromNib verwenden!

@tom: es stand nirgends was von sortieren (hab ich zumindest nirgends gesehen) und einen FEHLER würde ich etwas nennen was nicht FEHLERFREI funktioniert -> kein Fehler

ja da hat dein buch recht - ich hoffe aber, dass dein buch dir nicht versucht die schleife genau so beizubringen denn falls es sich bei list um ein array handelt dann musst du die indexe 0 bis count-1 abfragen und nicht von 1 bis count also i++ verwenden und nicht ++i

du hast nichts von speichern gesagt - denn dann hätte ich dir sagen können dass du keine dictionaries mit NSNumbers als Keys SPEICHERN kannst (ist mir auch schon passiert dass ich das wollte *lol*)

kommt drauf an was du machen willst.

du kannst es zb auch in einen archiver packen und auf die platte speichern!

Ich fing auch nicht vom Sortieren an, sondern habe a nur jemanden geantwortet.

Und ein (konzeptioneller) Fehler liegt auch dann vor, wenn etwas nicht so funktioniert, wie es erwartet. Irgendwelche Code-Wüsten, die zufällig dem Nutzer das präsentieren, was er erwartet, sind für mich nicht fehlerfrei. Ist aber vllt auch eine Frage des Anspruches.

i++ und ++i machen hier genau keinen Unterschied. Die Schleife läuft bis count-1, denn der letzte Teil der for-Schleife wird _immer_ vor der Abfrage ausgeführt.

Original von Tom9811
i++ und ++i machen hier genau keinen Unterschied. Die Schleife läuft bis count-1, denn der letzte Teil der for-Schleife wird _immer_ vor der Abfrage ausgeführt.

jup - da hatte ich nen dicken blocker ;-\

Original von deconceptional
Das mit dem Array auslesen funktioniert schon. Und wenn ich [NSNumber numberWithInt: i] durch [current objectForKey: @"someKey"] ersetze wird das ganze auch brav in ein File geschrieben (ich kann und will nicht garantieren, dass das Objekt für "someKey" einzigartig ist) . Mit NSNumber gehts jedoch nicht!? Und wenn ich Objekte aus dem Array abfrage, die nicht existieren, müsste mir das ja ein Runtime error geben, tut es aber nicht.

laut doku beherrschen die Container nur property list serialisierung von haus aus

das heißt möchtest du sie schreiben und lesen wenn du keine NSPropertyList fähigen Objekte hast must du sie "von" hand durch einen NSKeyedArchiver jagen

und NSNumber ist imho kein Object welches Property List Serializierung beherrscht

Original von chartus
und NSNumber ist imho kein Object welches Property List Serializierung beherrscht

Doch NSNumber gehört zu den Property List Objekten.

Michael

Und ich dachte schon, ich hätte es falsch im Kopf.

Mir scheint das Problem bei dem NSDictionary zu liegen, nämlich, dass dieses sich weigert, Dictionarys mit NSNumber-Objekten als _Keys_ zu schreiben. Und ich ahne auch vage, warum das so ist: Um jedenfalls im Klartext die PL zu schreiben, muss das Objekt in Text gewandelt werden. Das Wandeln von Floats in Text und umgekehrt führt jedoch nicht zum Ursprungsergebnis, jedenfalls nicht zwingend. Da könnte es lalilustige Effekte geben.

Wenn du indizierst, wieso nimmst du nicht ein Array?