Xml_Serialisieren

[nameac]

hallo,

mein zu serialisierendes objekt kann ich nur in eine xml schreiben lassen wenn ich keinen konstruktor deklariert habe.

public: OrderedItem(String ^item,String ^des){
		itemName=item;
		description=des;
		}

wenn ich einen konstruktor schreibe wie oben, kompiliert und linkt er noch ohne probleme aber er serialisiert nicht mehr liegt das daran das für die serialisierung von objekten nur standard konstruktoren vorgesehen sind?

[Knuddlbaer]

Gegenfrage:

Wie soll denn der Serializer von Deinem Konstruktor wissen um dort die Werte einzutragen ?

Tipp: Beschreib doch endlich mal Deine Fehler vernünftig. Keine ************ (suchs Dir aus) weiß hier wie Du die Objekte an den Serializer übergibst oder die Objekte anlegst.

[nameac]

ja aber das ist garnicht so einfach wenn man nicht alles als quellcode schreibt.

serializer->Serialize( writer, orderedItem );

so fehler wirft er in dem sinne keine aber dieses serialize liegt innerhalb eines try catchblocks und daher kommt bei mir nichts anderes als eine selbst definierte massagebox wo halt steht "geht nicht" und ich weiß das das mit dem selbstdefinierten konstruktor zusammen hängt. jetzt ist meine frage ob den serializer das schreiben von objekten mit selbstdefiniertem konstruktor zum abbruch zwingen.

[Knuddlbaer]

Oh man......

a) orderedItem ist eine Instanz eines Objektes. WIE legst Du das an ? Das ist unbekannt. Ohne das zu wissen kann Dir keiner sagen ob das Objekt überhaupt richtig Initialisiert ist.

Du kannst nich einfach irgend einen Quellcodeposten und sagen "Geht nicht". Was erwartest Du denn da als Antwort ?

b) Du bekommst im catch Block einen Zeiger auf eine Exception. Schau Dir da mal die Message an. Dann siehst Du was da geflogen ist.

try
{
  throw gcnew Exception ("Testexception");
}
catch (Exception ^ ex)
{
   MessageBox::Show(ex->Message);
   // oder
   MessageBox::Show(ex->ToString());
}

Damit kommst Du dann schon mal weiter, weil Du weißt warum da ne Exception fliegt.

[nameac]

jo danke dein tip mit ex->massage war sehr hilfreich da kam ne meldung "es fehlt ein leerer konstrukter damit serializer das objekt schreiben kann".

OrderedItem(){
			}

das hab ich dann in die header geschrieben und jetze gehts

[Knuddlbaer]

Auch nich schlecht, werden denn auch die richtigen Daten Serialisiert ?
Es wirkt ein wenig Merkwürdig auf mich, das eine bestehende Instanz eine solche Meldung auslöst.

[nameac]

ja die sachen werden serialisiert die meldung klingt aber wort wörtlich so:

PitPlaner.OrderedItem kann nicht serialisiert werden, weil dafür kein parameterloser konstruktor verfügbar ist.

[Knuddlbaer]

Hm.. mal merken, kann noch nützlich sein das fehlende Konstruktoren auch Laufzeitprobleme erzeugen können. Man lernt nie aus

[Jochen Kalmbach]

Knuddlbaer schrieb:

Auch nich schlecht, werden denn auch die richtigen Daten Serialisiert ?
Es wirkt ein wenig Merkwürdig auf mich, das eine bestehende Instanz eine solche Meldung auslöst.

Der XML-Serialisierer benötigt einen Konstruktor ohne Parameter damit er das Objekt instaziieren kann. Erst wenn es inszanziiert ist, kann er die public Properties/Fileds entsprechend setzen.
Woher sollte er wissen, welche Parameter in welcher Reihenfolge zu übergeben sind?

[Knuddlbaer]

Naja:

Knuddlbaer schrieb:

Wie soll denn der Serializer von Deinem Konstruktor wissen um dort die Werte einzutragen ?

Knuddlbaer schrieb:

Hm.. mal merken, kann noch nützlich sein das fehlende Konstruktoren auch Laufzeitprobleme erzeugen können. Man lernt nie aus

Für was ein Standardkonstruktor benötigt wird ist klar. Ich hätte jedoch nicht vermutet, das soetwas erst zur Laufzeit festgestellt wird.

Schauen wir uns mal die Signatur an:

public:
void Serialize (
	XmlWriter^ xmlWriter, 
	Object^ o
)

Dann schauen wir uns mal zwei Zeilen aus dem Beispiel der MSDN an:

OrderedItem^ i = gcnew OrderedItem; 
serializer->Serialize( writer, i );

Es wird eine Instanz von OrderedItem übergeben.
Da ich mich nicht im Detail mit dem XMLSerializer beschäftigt habe ist für mich nicht ersichtlich, für was der Konstruktor denn benötigt wird. Das Objekt IST bereits kontruiert, also ist das hier ja bereits gegeben:

Erst wenn es inszanziiert ist, kann er die public Properties/Fileds entsprechend setzen.

Beim Deserialisieren wird ein System::Objekt zurück gegeben, da könnte ich mir eine solche Exception vorstellen auch wenn ich aus guten alten C++ Zeiten eher einen Compilerfehler erwartet hätte.

Das Problem wird IMHO aber daran liegen, das ich mich bisher nicht im Detail mit dem Serializieren und dessen internen abläufen beschäftigt habe. Es bleibt daher nur die vermutung übrig, das der Serializer das Objekt genauestens untersucht - er muss ja Informationen wegschreiben um das Objekt später zu Deserialisieren. Die Signatur der Methode erwartet keinen Typen und gibt ein System::Object ^ zurück. (Also etwas anderst als mit einfachen op>> und op<< , dessen vorgehensweise ich Gedanklich mit dem Serialisieren beim Antworten der Fragen gleich gesetzt habe. Dort muss man wissen was man ausliest. Hier scheint bereits eine Fabrik implementiert zu sein mit der Eigenschaft zuvor genauestens auf Serialisierbarkeit zu prüfen bevor das Objekt geschrieben wird. Schade finde ich dann:

Die Serialize-Methode konvertiert die öffentlichen Felder und Lese-/Schreib-Eigenschaften eines Objekts in XML. Methoden, Indexer, private Felder und Nur-Lesen-Eigenschaften werden nicht konvertiert.

das man für die priv. Eigenschaften dann doch Hand anlegen muss).

Die Vermutungen werden natürlich bei Gelegenheit durch fleissiges Lesen ausgebessert. Bis dahin lebe ich mal mit der Vermutung das es so in die Richtung sein könnte und war mit diesen Wissenslücken einfach davon überrascht das fehlende Konstruktoren überhaupt Laufzeitfehler auslösen können.

Also: Interesanntes Thema, dessen Wissen sich lohnt bevor man es einsetzt um genau das zu liefern was vom Serializer erwartet wird bzw. um alles zu Serialisieren was benötigt wird

(Sag ja, man lernt nie aus und die Liste der zu lesenden Themen wird nie beendet sein