Jetzt versteh ich gar nichts mehr :-(

  • tomekcp
    Ja, beide Möglichkeiten helfen.
    Ich habe für mich festgestellt, dass bei gravierenden Problemen der Debugger schneller ist.

    Thallius schrieb:

    Alleine schon das heute immer
    Object=[Klasse alloc] init];
    als absolut selbstverständlich funktionierend angenommen wird. Da kommt gar keiner auf die Idee das das mal fehlschlagen könnte und sei es nur weil kein Speicher mehr dafür da ist?

    Genau genommen kann [[Klasse alloc] init]; nicht fehlschlagen: man bekommt immer ein valides Objekt zurück.
    Natürlich kann man mit dem nil-Objekt im Zweifel nicht viel anfangen. ;)

    faulk
    Deine Problembeschreibung ist irreführend.
    Was steht wo wann wie warum nicht drin?
    Was steht in Description von wem drin?
    (bedenke: -description ist eine Methode, die in NSObject definiert ist. Ergo gibt sie in jedem Fall irgend ein brauchbares Ergebnis in Form eines NSString, selbst wenn es nur (null) ist.)

    Und überhaupt: jede deiner Methoden macht x Dinge auf einmal.
    Da irgendwo einzugreifen und Fehler aufzuspüren ist eine Herausforderung.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Ich würde ja das Error-Handling abfangen und nicht nil setzen. Dann wüsste man z.B. vielleicht auch wenn mal z.B. das Schreiben nicht geklappt hat.
    However, wenn du meinst da klappt was nicht dann schreib ein Testprogramm und reduziere dies bis auf die Funktionen des Problems und schau ob sich das Problem deines Hauptprogramms dort rekonstruieren lässt. Das hilft enorm um eigene Fehler zu finden.
    [self setSignature:null];
    [[self postCount] increment];
  • @mike: ja das mache ich sonst auch, nur das in diesem fall vorher alles geklappt hat, und erst seit dem ich ein File runterlade, hab ich mir mein programm zerschossen :(

    Wie kann es sein das wenn ich mir die .Description von data ausgeben lasse das alle werte da sind, also zb.

    Quellcode

    1. CarboCheck[46733:c07] data: (
    2. "Cheeseburger (Erw./Kind)",
    3. "1",
    4. "30",
    5. "7",
    6. "13",
    7. "1
    8. "
    9. )


    aber wenn ich sage NSLog(@"%@",[data objectAtIndex:5]);
    dann bekomme ich das zurück : "" (leeren string)

    dazu noch diese komische nachricht mit data is no ObjC Object ... ??
  • dieser code:

    Quellcode

    1. NSMutableArray *data = [NSMutableArray arrayWithArray:[[lines objectAtIndex:i] componentsSeparatedByString:@";"]];
    2. NSLog(@"data.Description: %@",data.description);
    3. //Hand over the Data
    4. Food *tempFood = [[Food alloc] init];
    5. tempFood.Title = [data objectAtIndex:0];
    6. tempFood.Gramm = [data objectAtIndex:1];
    7. tempFood.CarbsPerGramm = [data objectAtIndex:2];
    8. NSLog(@"ie data/carbs: %@",[data objectAtIndex:2]);
    9. tempFood.Sugar = (NSString *)[data objectAtIndex:3];
    10. tempFood.Fat = [data objectAtIndex:4];
    11. [tempFood.unitSizeArray addObject:[NSString stringWithFormat:@"Normal;%@",[data objectAtIndex:5]]];
    12. tempFood.picture = [UIImage imageNamed:image];
    13. tempFood.typ = typ;
    14. //Add to the FoodArray
    15. [[libary libaryFoodArray] addObject:tempFood];
    16. }
    17. NSLog(@"Libary: %@",libary.libaryFoodArray.description);
    Alles anzeigen


    ergibt diesen consolen ausdruck:
    CarboCheck[69883:c07] data.Description: (
    "Big Mac\U00ae",
    "1",
    "40",
    "8",
    "25",
    "1
    "
    )
    2012-09-11 08:47:12.033 CarboCheck[69883:c07] ie data/carbs:

    und keines der Objekte ist im debugger nil...
    -> siehe bild im anhang..

    Wie ist denn sowas möglich, ich bin zwar noch ziehmlicher Anfänger, aber das kommt mir einfach spanisch vor :-S..
  • <Not an Objective C Object> stammt vom NSMutableArray und weist dich darauf hin, dass das Objekt, das du da in das Array pappen willst, kein Objective C Objekt ist und deshalb nicht reingepappt werden kann.

    Thallius
    Nope, das ist ein Array.

    C-Quellcode

    1. NSSet *aSet = [NSSet setWithObjects:@"Dies", @"ist", @"ein", @"Set", nil];
    2. NSArray *anArray = [NSArray arrayWithObjects:@"Dies", @"ist", @"ein", @"Array", nil];
    3. NSDictionary * aDict = [NSDictionary dictionaryWithObjectsAndKeys:@"Dies", @"Eins", @"ist", @"Zwei", @"ein", @"Drei", @"Dictionary", @"Vier", nil];
    4. NSLog(@"Set:\n%@", aSet);
    5. NSLog(@"Array:\n%@", anArray);
    6. NSLog(@"Dictionary:\n%@", aDict);

    Tests[586:403] Set:
    {(
    ein,
    Dies,
    Set,
    ist
    )}
    Tests[586:403] Array:
    (
    Dies,
    ist,
    ein,
    Array
    )
    Tests[586:403] Dictionary:
    {
    Drei = ein;
    Eins = Dies;
    Vier = Dictionary;
    Zwei = ist;
    }

    Know your tools, know your console output. :P

    () = Array, {} = Dictionary, {()} = Set.

    C-Quellcode

    1. NSArray *data = [NSArray arrayWithArray:[[lines objectAtIndex:i] componentsSeparatedByString:@";"]];

    Was soll denn bitte der Quatsch? o.O

    C-Quellcode

    1. NSArray *dataArray = [[lines objectAtIndex:i] componentsSeparatedByString:@";"];


    Dieses Array-Hin-Und-Her verwirrt doch nur.
    Vielleicht liegt da schon das Array-Problem.
    Mach mal lieber vor der Zuordnung zu deinen Objekten:

    C-Quellcode

    1. NSArray *data = [[lines objectAtIndex:i] componentsSeparatedByString:@";"];

    Du brauchst das Array nicht in Veränderbar, also musst du es auch nicht so anlegen.
    Und wie geschrieben: dieses Hin und Her verwirrt nur.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • So habe jetzt mal alle Rückgabewerte, bin trotzdem nicht schlauer.. :(

    hier der Code

    Quellcode

    1. NSString * content = [NSString stringWithContentsOfFile:[self getPathForFile:@"Import.txt"] encoding:NSUTF8StringEncoding error:nil];
    2. NSLog(@"Content :%@",content);
    3. NSArray *lines = [content componentsSeparatedByString:@"\n"];
    4. NSLog(@"%@ - %@",lines,[lines objectAtIndex:2]);


    und hier was dabei rauskommt:

    Quellcode

    1. CarboCheck[21193:c07] Content :ÿþ;
    2. 2012-09-11 10:40:18.405 CarboCheck[21193:c07] (
    3. "\U00ff\U00fe;pro;KH;Zucker;Fett;Portion
    4. ",
    5. "Test;1;2;3;4;5
    6. ",
    7. "Test;1;2;3;4;5
    8. ",
    9. "Test;1;2;3;4;5
    10. ",
    11. "Test;1;2;3;4;5"
    12. ) -
    Alles anzeigen


    btw. die dummy textdatei die ich runtelade ist momentan diese:

    Quellcode

    1. ;pro;KH;Zucker;Fett;Portion
    2. Test;1;2;3;4;5
    3. Test;1;2;3;4;5
    4. Test;1;2;3;4;5
    5. Test;1;2;3;4;5


    Warum wird content so seltsam ausgegeben, kann das encoding schuld sein an der ganzen sache hier??

    lg

    /edit man bemerke das nachher data von lines generiert wird und sich das somit auch schon komisch verhält...
    ich hab jetzt mal UTF8,UTF16,ASCII - Encoding gecheckt hilft auch nichts, is das encoding okay wie es ist?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von faulk ()

  • Als erstes würde ich IMMER ein paar Sonderzeichen und Umlaute in meine Dummydatei packen. Das zeigt sehr schnell wenn was mit dem encoding nciht passt. Auf jede Fall scheinen die LF nicht korrekt zu sein. Wer erzeugt die Datei womit ?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)