Suchergebnisse

Zitat von kafffee: „Da ist natürlich noch diese Property, die nicht gehen kann, weil date ein Schlüsselwort ist.“ mach so: VB.NET-Quellcode (1 Zeile)

Zitat von kafffee: „Ja aber der Datentyp ist doch da an sich auch wieder ein Schlüselwort ?“Also wies mir aussieht, haben sie für viele Datentypen Extra-Schlüsselworte eingeführt: learn.microsoft.com/en-us/dotn…guage-reference/keywords/ Der Grund wird sein, dass sie Verwirrung schaffen wollten, und verhindern, dass Vb.Net-Programmierer den Unterschied von Datentyp und Schlüsselwort verstehen.

Hi + rutsch! ich hab auch mal probiert, und ich konnte beide Json-Texte fast problemlos deserialisieren - also dieses Root-Dingens, und das Welcome. Den Fehler kannich natürlich nicht reproduzieren, weil der durchs gegebene Welcome-Json wohl nicht ausgelöst wird. Und um die fehlerhaften Welcomes selbst abzurufen fehlen mir natürlich die Credentials. Also Fehler reproduzieren könnte man, wenn du den fehlerhaften JsonCode auch einstellen würdest. Übrigens vorzugsweise in einem CodeBlock, dann biet…

also ich hab einfach json2csharp genommen. allerdings ist das json aus post#37 strukturell ähnlich zu dem aus post#1. Und somit nicht zu verwechseln mit dem aus post#16. Die Jsons aus post#1 + post#16 würde ich mal als "ReleasesData" bezeichnen, während es sich bei post#16 ja um "AlbumSearchData" handelt. Jo, und nachwievor tritt bei mir kein Fehler auf. Liegt wohl daran, dass ich die generierten Datentypen nicht geändert habe, also bei mir gibt Datumse As String und sowas. Was mir auffällt ist,…

Ich hab ma TestApp gemacht für bisserl gründlichere Untersuchigung. Da sind alle 3 Jsons enthalten (post#1, post#37, post#16), und alle 3 generierten Datenstrukturen. man sieht, dass post#1 eine Untermenge von post#37 zu sein scheint - also die Datenstruktur von #37 ist eiglich dieselbe, aber einige Klassen haben noch mehr properties. generiert habich die Classes mit json2csharp.com/ Zur besseren Laufzeit-Unterstützung der Class-Viewer habich bei einigen Properties in den Classes das [TypeConver…

ah. Mir ist noch ein Fehler meinerseits aufgefallen: Besser ist, man nutzt die .FromJson() - Methode, also VB.NET-Quellcode (3 Zeilen)Dann braucht man nichts nachbessern mittm JsonConverter(typeof(xxxxxx))]-Attribut. Zitat von siycah: „An QuickType habe ich bereits auch schon rumgebastelt“Wie jetzt - du hast da beim Quellcode der Site mitgewirkt?

na, du solltest noch meine TestApp runterladen - allein wegen des legendären GUIs, was mehrere Alternativen abklopft. Das QuickType-Gedöhns ist klar Favorit, besonders wenn mans benutzt wie gedacht (also post#48 beachten) Und im Nachgang habich jetzt auch die bekloppte QT-Date-Structure (teilweise) rausgeworfen, und durch richtiges DateTime ersetzt. Dazu habich einen eigenen DateTimeConverter eingebaut. Was nicht weiter schwer war - ich hab den QT-generierten Date-Konverter umkopiert und bisserl…

und denke daran, die Properties, die DateTime sind, auch so zu deklarieren. Guck dir die generierten Klassen sorgfältig an - auf die Schnelle finde ich folgendes komisch:C#-Quellcode (32 Zeilen)

ich bin noch unüberzeugt. Weil wenn im Json "2008-04-01" steht, dann wird Date.DateTime befüllt und Date.Integer bleibt leer. Und wenn im Json "2008" steht, dann wird Date.Integer befüllt und Date.DateTime bleibt leer. Von einer Kompatiblitäts-Klasse täte ich Umrechnungs-Funktionalität erwarten. Auch Prop-Namen wie Recording.FirstReleaseDate deuten auf Datumse hin - nicht auf Timestamps

guck dir auch meine Lösung an. Ich versteh dieses Date-Dingens nämlich so, dass er "2008" nicht als Date parsen kann - (obwohl das iso8601-konform ist). Daher denkt sich die QT-Heuristik: "Da steht ja mal ein Datum, mal ein Long drin - also bastel ich eine Spezial-Struct, wo Datum oder Long drin stehen kann." Also nix mit posix-Kompatiblität, sondern ein Fehler der Heuristik. Und guck dir auch das Json an - da gehts ganz bestimmt nicht um Timestamps (zumindest was ich darunter verstehe). Und mei…