Eingegebene Werte dauerhaft abspeichern in C#

Für die INI Dateien:

GetPrivateProfileString
SetPrivateProfileString
u.a.

Kommt immer drauf an was das für Daten sind.

Registry wurde ja schon genannt.
Andere Möglichkeit: Datei auf, Werte reinschreiben, Datei zu

Da kann  man dann auch mehrere 'Konfigurationen' in verschiedenen Files 
aufbewahren, und der Benutzer kann isch dann die Laden, die er haben 
möchte.

achim wrote:

> Soweit funktioniert das, aber wenn ich eine große Datenmenge schicken
> mag, dann wird das viel Schreiberei.


Du meinst beim Write...
Wieso? Schon mal was von Schleifen gehört?

Ausserdem würd ich ein Array nicht unbedingt so speichern, dass jeder 
Wert einen eigenen Tag hat, sondern alle Arrayelemente in einem Tag 
speichern. zb. mit Kommas trennen, so dass dein jetziges XML so aussehen 
würde

  <Werte>100,200,300</Werte>

Sowas ist leicht zu erzeugen (einfach in einer Schleife an einen String 
immer wieder gegebenenfalls ein Komma und den nächsten Wert an einen 
String anhängen, den String dann als Ganzes aufs XML schreiben) und auch 
wieder leicht zu lesen. (Den gelesenen String an den Kommas in 
Einzelstrings splitten lassen und die Einzelteile weiterverarbeiten)

Ralf wrote:
> Hi,
>
> da gibt es zwei Ansätze. Entweder in eine Config- bzw. INI-Datei oder in
> die Registry. Der erste ist zwar veraltet, aber immer noch in Gebrauch,
> der zweite ist quasi Windows-"konformer".
>
> Beides lässt sich relativ einfach umsetzen, leider kann ich dir jetzt
> nicht genau sagen wie es geht, aber guck mal auf http://www.mycsharp.de
> im Forum, da findest du sicher, was du suchst.
>
> Ralf

Beides sollte in diesem Zusammenhang nicht verwendet werden.
Den XmlTextWriter braucht man dazu auch nicht zu bemühen, da das Net 
Framework dafür ApplicationSettings kennt.
Erzeugt man ein neues Projekt wird automatisch eine entsprechende Klasse 
erstellt, die man direkt verwenden kann (in der Projektmappe unter 
Properties Settings.settings, wo man u.a. auch neue Voreinstellungen 
erzeugen kann).
Geladen werden die Einstellungen automatisch, nur das Speichern muss man 
selbst anstoßen (Settings.Default.Save())
Verwendung dann z.B. Settings.Default.Irgendwas = 1234;

Nachtrag: Das ganze hat auch den Vorteil, dass man damit direkt 
Applikations- und Benutzervoreinstellungen erzeugen kann.

Noch ein Nachtrag: Wenn man was eigenes machen will/muss, ist es 
wesentlich einfacher diese Voreinstellungen in eine eigene Klasse zu 
packen und z.B. als XML zu serialisieren (letztlich dasselbe, was die 
ApplicationSettings intern auch machen)

achim wrote:

>             myXmlTextWriter.WriteStartElement("wert0");
>             myXmlTextWriter.WriteString(Convert.ToString(array[0]));
>             myXmlTextWriter.WriteStartElement("wert1");
>             myXmlTextWriter.WriteString(Convert.ToString(array[1]));
>             myXmlTextWriter.WriteStartElement("wert2");
>             myXmlTextWriter.WriteString(Convert.ToString(array[2]));
>
> Dieses kann ich nicht mit einer Schleife erledigen.

Nicht ?????
Was hindert Dich daran?

achim wrote:

>             myXmlTextWriter.WriteStartElement("wert0");
>             myXmlTextWriter.WriteString(Convert.ToString(array[0]));
>             myXmlTextWriter.WriteStartElement("wert1");
>             myXmlTextWriter.WriteString(Convert.ToString(array[1]));
>             myXmlTextWriter.WriteStartElement("wert2");
>             myXmlTextWriter.WriteString(Convert.ToString(array[2]));
>
> Dieses kann ich nicht mit einer Schleife erledigen.

Das ist aber seltsam. Vor allen Dingen weil so ziemlich alle Zutaten die 
du dazu brauchst, mit Ausnahme der Schleife selbst und der Verkettung 
von Strings schon dastehen

   for( i = 0; i < 3; ++i )
   {
     String tag = "wert" + Convert.ToString( i );

     myXmlTextWriter.WriteStartElement( tag );
     myXmlTextWriter.WriteString( Convert.ToString( array[i] ) );
     myXmlTextWriter.WriteEndElement();
   }

> Aber ich werde mir das nochmal schnauen. Wusste bis heute noch nichtmal
> was ein XML überhaupt ist ;-)

Das hat weniger mit XML zu tun, als mit der Fähigkeit sich einen String 
so zusammenbauen zu können, wie man ihn braucht.

Johnny wrote:
> Du machst Dir viel zu viel Arbeit. Speichere Deine Daten einfach in
> einem Struct bzw. in einer Klasse.
> Dann lass das .NET Framework die Arbeit tun. Das Zauberwort heisst
> serialisieren; mit etwa drei Zeilen Code ist es dann erledigt, egal wie
> komplex Deine Daten sind. Das Umgekehrte um die Daten wieder
> zurückzuholen heisst deserialisieren.
> Also such im Netz einfach mal nach "xml", "file", "serialize", ...

Na ja, ich finde schon, dass ein Programmierer in der Lage sein sollte, 
selbst eine Datei zu lesen/schreiben.

Spätestens dann, wenn deine gespeicherten Daten in einem anderem 
Programm widerverwendet oder manipuliert werden sollen(ev. sogar in 
einer anderen Programmiersprache), stehst du nämlich mit der 
Serialisierung schön dumm da. Been there, done that.

Karl heinz Buchegger wrote:
> Na ja, ich finde schon, dass ein Programmierer in der Lage sein sollte,
> selbst eine Datei zu lesen/schreiben.
>
> Spätestens dann, wenn deine gespeicherten Daten in einem anderem
> Programm widerverwendet oder manipuliert werden sollen(ev. sogar in
> einer anderen Programmiersprache), stehst du nämlich mit der
> Serialisierung schön dumm da. Been there, done that.

Deshalb auch XML, das könnte man zur Not auch noch problemlos mit einem 
externen Programm passend konvertieren. Aber wie oben schon gesagt, für 
das ursprüngliche Problem gibt's mit ApplicationSettings eine einfach zu 
benutzende Lösung im Framework, die XML benutzt.

Johnny wrote:
> Er denkt halt, dass richtige Programmierer alles noch "von Hand" selbst
> ausprogrammieren.

:-)
Immerhin kann ich das noch und brauch niemanden der für mich vorarbeitet
:-)

> Wahrscheinlich implementiert er nun gerade einen neuen
> XML Parser.

Nö. Wozu?
Sowas nimmt man fertig.

Im Ernst: Sobald du darauf angewiesen bist, deine Datenfiles an irgend 
jemanden zu übergeben, bist du mit irgendwelchen proprietären Lösungen 
immer schlecht beraten. Deinen Quelltext rausgeben willst du mit 
Sicherheit nicht.
XML ist schon eine gute Lösung, wenn der Overhead keine Rolle spielt. 
Wenn er es aber doch tut, was machst du dann?

Dann holst du dir einen richtigen Programmierer, der kein Framework 
braucht um 3 Zahlenwerte in eine Datei zu speichern.

Wir reden aneinander vorbei.

Ich versteh deinen Standpunkt durchaus, das Rad nicht neu erfinden zu 
wollen und das ist auch gut so.

Auf der anderen Seite reden wir von einem Programmierer, der 
Schwierigkeiten damit hat 2 Strings miteinander zu verknüpfen um sich 
den Tag-Titel in einem XML Dokument zu generieren.

Klar ist er mit deinem 3 Zeiler gut bedient. Er hat erst mal eine Lösung 
mit der er gut klar kommt und die ihm alle Arbeit abnimmt.

Er verkauft sich dann als Programmierer bis er in eine Firma kommt, wo 
er dann ein Autocad DXF einlesen soll und mit großen Augen davor steht, 
weil er in seinem ganzen Leben noch nie ein File gelesen oder 
geschrieben hat. Aber Hauptsache er kann sich aus dem Framework die 
Teile zusammenklicken die er braucht. Das beherrscht er.

Ein File lesen oder Schreiben zu können ist für mich Grundlagenwissen, 
das muss bei mir jeder Programmierer können, egal ob ihm später ein 
Framework diese Arbeit abnimmt oder nicht. Ditto für 
Stringmanipulationen. Übung ist in der Programmierung die halbe Miete. 
Die Welt da draussen ist voll mit 'Programmierern' die ausser sich aus 
einem Framework irgendwelche Klassen zusammenzuklicken nichts anderes 
können. Und dementsprechend sehen auch ihre Programme aus.

Und ich hab keineswegs einen Feldzug gegen XML gestartet :-)