Einstellungen speichern und verwalten

[Lord Dave]

Hallo,

mich würde mal interessieren, wie ihr in euren Anwendungen die Einstellungen speichert und verwaltet.
z.B. "Diesen Dialog nicht mehr zeigen", o.ä. Einstellungen.
Speichert ihr diese Daten in der Registry, Ini oder ner XML und lest sie bei jedem Gebrauch neu aus?
Oder ladet ihr alle Einstellungen beim Start ihn den Speicher?
Mir würde ja wie in PHP ein assoziatives Array gefallen, à la if($cfg['showDialog1'] == true)


Ich würde mich da gerne auf eine allgemeingültige Lösung festlegen, da ich es bisher immer so gemacht hatte, worauf ich gerade Lust hatte. Ein paar Erfahrungen wären da ganz hilfreich :)

Danke im Vorraus

[lucius]

Hallo Lord Dave,

Ich speichere alles in einer Ini, die teils verschluesselt wird und wieder entschluesselt wenn ich Daten aus der Ini lese.

[Lord Dave]

Hi,

liest du dann alle Einstellungen beim Programmstart aus?
Oder musst du bei jeder Abfrage die Datei entschlüssen und dann wieder verschlüsseln?

[lucius]

Nein ich verschluessele manche strings in der Ini Datei, ich brauche nicht die ganze Datei zu verschluesseln.

Delphi-Quellcode:

Cipher:= TDCP_rc4.Create(Self);
         Cipher.InitStr(KeyStr,TDCP_sha512);
         with TIniFile.Create(...) do
         try
         WriteString('Inloggevens:', 'Username', Cipher.EncryptString(Useredit.Text));
         WriteString('Inloggevens:', 'Passwort', Cipher.EncryptString(Passedit.Text));
         finally
         Free;
         Cipher.Burn;
         Cipher.Free;

[himitsu]

Ihr wißt aber, daß Microsoft zum Speichern von Programmspezifischen Daten das SPeichern in der Registry empfiehlt?
INIs sind offiziell am Aussterben.


Allerdings haben die INIs auch noch jetzt ihre Vorteile, vorallem bei kleinen Tools, welche nicht installiert und eventuell nach den einmaligen Aufrufen wieder gelöscht werden.

[Daniel Schuhmann]

Ja, MS propagiert das schon seit Windows 95. Aber für ein kleines Tool sind Ini-Dateien doch wesentlich einfacher zu handhaben, zudem ist es auch für den Anwender leichter, diese zu konfigurieren. Wer noch nie regedit aufgemacht hat, wird da schon Schwierigkeiten bekommen und könnte auch ganz leicht durch Löschen falscher Schlüssel was am System kaputtmachen. Bei einer anwendungsbezogenen Ini-Datei kann hingegen kaum etwas passieren.

[Luckie]

Ähm, es geht hier nicht um das Pro und Contra von Registry-Einträgen und Ini-Dateien.

@David: So lange das programm nur ab Windows 2000 ff. laufen soll, mache ich es mir einfach bei diesen Dialogen: "Diesen Dialog nicht mehr zeigen" und lass das Windows selber regeln mit: MessageBoxCheck. ;)

[MisterNiceGuy]

Also ich benutze gerne IniFiles.

Registryeinträge setze ich nur mit Vorsicht, da man diese doch schnell aus Unachtsamkeit vollmüllen kann.

[Hansa]

Zitat:

Zitat von himitsu

Ihr wißt aber, daß Microsoft zum Speichern von Programmspezifischen Daten das SPeichern in der Registry empfiehlt?
INIs sind offiziell am Aussterben...

Mein Artzt/Apotheker ist da aber ganz anderer Ansicht. :mrgreen: Denn aus dem hier :

Zitat:

Zitat von Lord Dave

...da ich es bisher immer so gemacht hatte, worauf ich gerade Lust hatte.

und dann dem :

Zitat:

Zitat von MisterNiceGuy

...da man diese doch schnell aus Unachtsamkeit vollmüllen kann.

folgt : am Ende kommt Schrott dabei raus. Mickysoft ist nicht gerade berühmt dafür, sinnvolle Ratschläge zu geben. Und wegen dieser "guten" Ratschläge häufen sich die Fälle, in denen ein Programm nur deshalb nicht installiert wird, weil die Leute Angst haben, es nicht restlos wieder entfernen zu können, nur weil der Programmierer eben mal keine Lust hatte. :lol:

Deshalb : Sachen wie Fensterkoordinaten oder grundsätzlich vom Enduser änderbare Konstanten landen bei mir immer in einer INI und fertig. Dann kann ich zurecht sagen : weder wird beim Hochfahren eventuell unnötigermaßen was geladen, noch bleibt was übrig, sofern das Programm gelöscht wird, was dann wieder überflüssigerweise jedesmal neu geladen werden muß. Dieses Verhalten steht sogar in meinem Disclaimer.

[Luckie]

Zitat:

Zitat von Hansa

Mickysoft ist nicht gerade berühmt dafür, sinnvolle Ratschläge zu geben.

Muss denn immer dieses Microsoft Bashing sein? Wenn euch das nicht passt, was Microsoft entwickelt hat, dann benutzt ein aderes Betriebsystem und entwicklet auch für dieses andere Betriebsystem. Aber was ich absolut nicht leiden kann, ist immer über Microsoft herzuziehen, dann aber wieder mit dessen Betriebssystem selber Geld zu verdienen, weil man dafür entwickelt. So genug offtopic, dass musste ich jetzt einfach mal loswerden.

[Lord Dave]

Was ist mit dem Userverzeichnis \ Anwendungsdaten?
Wozu ist das von Microsoft erdacht?

Aber mal um ein bißchen von dem Speichern wegzukommen, die benötigten Daten werden erst bei Bedarf eingelesen, versteh ich das richig?

Ich habe immer gerne Methoden wie saveSettings() oder loadSettings() die ich auf einzelne Forms anwende. Oft habe ich ein globales Objekt in dem ich alle Einstellungen verwalte, das ich dann einfach an die Methode übergebe und diese die benötigten Informationen ausliest.

[Luckie]

Zitat:

Zitat von Lord Dave

Was ist mit dem Userverzeichnis \ Anwendungsdaten?
Wozu ist das von Microsoft erdacht?

Eine ganze Adresskartei willst du doch wohl nicht in der Registry ablegen oder? ;)

[Hansa]

Microsoft Bashing ? :shock: Aber das ist ja auch was ganz anderes. :mrgreen:

Aber egal. Gehen wir mal von den Fensterkoordinaten aus :

FormShow :

Delphi-Quellcode:

  try
    FensterIni := TIniFile.Create(FensterDateiName);
    Left   := FensterIni.ReadInteger(Name,'Left',Left);
    Top    := FensterIni.ReadInteger(Name,'Top',Top);
(*
    Width  := FensterIni.ReadInteger(Name,'Width',Width);
    Height := FensterIni.ReadInteger(Name,'Height',Height);
*)
  finally
    FensterIni.Free;
  end;

Jetzt fummelt da einer an den Forms rum und schiebt sie sinnlos durch die Gegend. Deshalb muß der letzte Zustand für den nächsten Programmstart wieder verfügbar sein. Also :

FormClose :

Delphi-Quellcode:

  try
    FensterIni := TIniFile.Create(FensterDateiName); //FensterDateiName));
    FensterIni.WriteInteger(Name,'Left',Left);
    FensterIni.WriteInteger(Name,'Top',Top);
(*
    FensterIni.WriteInteger(Name,'Width',Width);
    FensterIni.WriteInteger(Name,'Height',Height);
*)
  finally
    FensterIni.Free;
  end;

Es wäre ein leichtes, da jetzt noch Voreinstellungen von Checkbooxen usw. unterzubringen. Und das Wort "Name" ist nicht zu unterschätzen ! Das´ist der Form-Name aus dem Quelltext und man braucht somit auch nur eine INI. Speichert man nun diese INI auch noch im User-Verzeichnis, dann kann jeder angemeldete Benutzer sich seinen eigenen Desktop zusammenbauen. Und ein Servicetechniker, der eventuell vor Ort was machen muß, der kann bei total verkorksten Einstellungen durch einfaches kopieren zumindest schnell wieder den Ursprungszustand wiederherstellen.

[Luckie]

Und genauso gut kann man das auch mit der Registry machen. Wenn man da in HKCU schreibt, muss man sich noch nicht mal darumkümmern, dass die Benutzer getrennt verwaltet werden.

[woki]

Zitat:

Zitat von himitsu

Ihr wißt aber, daß Microsoft zum Speichern von Programmspezifischen Daten das SPeichern in der Registry empfiehlt?
INIs sind offiziell am Aussterben.

Nun, das war einmal. Nachdem Microsoft neben der "DLL-Hölle" auch die Auswirkungen der "Registryhölle" verstanden hat, wird mit .NET ja alles anders, insbesondere sollte die Registry nur noch verwendet werden, wenn es um Dinge geht, die mit Konfigurationsdateien nicht gelöst werden können. Bier sind mit .Net natürlich xml-Konfigurationsdateien gemeint, aber wer zukunftssicher sein will, und sich und seinen Usern unendliche Probleme ersparen will, verwendet auch unter Win32 die Registry nur wenn es unweigerlich notwendig ist.
Unter Win32 kann man sich da natürlich mit ini Dateien behelfen, wenn xml hier unbequemer erscheint.

Grüsse
Woki

[Hansa]

Zitat:

Zitat von woki

...wird mit .NET ja alles anders, insbesondere sollte die Registry nur noch verwendet werden, wenn es um Dinge geht, die mit Konfigurationsdateien nicht gelöst werden können...

Quelle (insbesondere von M$) :?: Das hat mir zwar schon vorher der gesunde Menschenverstand gesagt, aber wie man sieht wird die Registry noch liebend gern verwendet. Mir liegen Informationen vor, daß die Richtung eindeutig in Richtung XML geht (als Ersatz für INIs). Allerdings war da nie die Rede von der Registry in diesem Zusammenhang.

Und das hier ist dann auch in einem etwas anderen Licht zu sehen :

Zitat:

Mickysoft ist nicht gerade berühmt dafür, sinnvolle Ratschläge zu geben.

Was ist denn davon zu halten, wenn die Registry tatsächlich nur für Ausnahmefälle genutzt werden soll ? Alle, die Mickysoft-konform programmiert haben, tja, die haben eben die A-Karte gezogen. :mrgreen:

[woki]

Zitat:

Zitat von Hansa

Zitat:

Zitat von woki

...wird mit .NET ja alles anders, insbesondere sollte die Registry nur noch verwendet werden, wenn es um Dinge geht, die mit Konfigurationsdateien nicht gelöst werden können...

Quelle (insbesondere von M$) :?: Das hat mir zwar schon vorher der gesunde Menschenverstand gesagt, aber wie man sieht wird die Registry noch liebend gern verwendet. Mir liegen Informationen vor, daß die Richtung eindeutig in Richtung XML geht (als Ersatz für INIs). Allerdings war da nie die Rede von der Registry in diesem Zusammenhang.

Die Registry sollte ja schon die Ini's ersetzen. Jetzt geht es halt zurück zu Kofigurationsdateien. Alles andere unterläuft die MS-Strategie des XCopy-Deployments. Das ergibt sich eigentlichauch ohne weitere Quellenangabe, aber z.B.

Holger Schwichtenberg:
Programmierung mit der .Net Klassenbibliothek
Addison Wesley
s. 453:

Sie sollten also nur dann auf die Registry zugreifen, wenn sie sicher sind, dass dieser Zugriff auch wirklich nötig ist ...
Andernfalls benutzen sie die XML- Konfigurationsdateien ihere Applikation, in denen Sie relevante Werte ablegen können.

Zitat:

Zitat von Hansa

Und das hier ist dann auch in einem etwas anderen Licht zu sehen :

Zitat:

Mickysoft ist nicht gerade berühmt dafür, sinnvolle Ratschläge zu geben.

Was ist denn davon zu halten, wenn die Registry tatsächlich nur für Ausnahmefälle genutzt werden soll ? Alle, die Mickysoft-konform programmiert haben, tja, die haben eben die A-Karte gezogen. :mrgreen:

Na ja, das war halt die Meinung von MS vor einigen Jahren, und bezogen auf Win32. Mit .Net ändert sich hier halt einiges, und deshalb ist es dann meine Meinung, dass man auch unter Win32 jetzt mit der Registry nicht mehr mehr machen sollte, als man dann unter .Net damit tun wird, nämlich nur das was unbedingt nötig ist. Das veinfacht den Übergang. Außerdem, wennn denn einfach jetzt endlich klar ist, dass die Registry in dieser Form ein Fehler war....

Grüsse
Woki

[Hansa]

Wirklich sehr schön. :-D Sogar M$ ist endlich auf den Trichter gekommen mit der Schrott-Registry. Aber seeeehr spät. Wer sich an deren "Richtlinien" gehalten hat, der ist in Zukunft eben der Dumme. *duck* Wer D2005 hat, der soll mal nach XML suchen und sich nicht wundern, was er da in den Borland-Verzeichnissen findet. Der Weg scheint also wieder zurück zu Textdateien zu gehen. Mit jedem Text-Editor lassen die sich bearbeiten. :thumb: Für mein Beispiel mit den Fensterkoordinaten macht es allerdings keinen Sinn, dafür XML einzusetzen. Da reichen INIs völlig aus. Falls das doch nicht reicht, dann würde ich auch auf XML umstellen, zumindest bevor in wichtigem Programm irgendwo das Wort "TRegistry" auftaucht.

Es fehlt allerdings noch eine Variante, um Einstellungen zu speichern : in einer Datenbank. Man kann auch mit der Datenbank (eventuell sogar leerer) gleich einen voreingestellten "Desktop" mitliefern. Wegen der leichten Editierbarkeit von INI/XML bevorzuge ich aber eher das.

[Luckie]

Das

Zitat:

<?xml version="1.0" encoding="ISO-8859-1"?>
<adressdb><XMLFile><MajorVersion>1</MajorVersion><MinorVersion>226</MinorVersion><Computer>HAL9000</Computer><User>Michael</User>
<ModifyDate>2005-10-29</ModifyDate><ModifyTime>07:05:18</ModifyTime><RecordCount>44</RecordCount><HighestID>44</HighestID></XMLFile>
<Kontakt><ID>1</ID><Name>Alt</Name><Vorname>Stephan</Vorname><Strasse>Ellerhofer Straße 11</Strasse><PLZ>34121</PLZ><Ort>Kassel</Ort>
<Land>Deutschland</Land><Telefon1>[phone]</Telefon1><Telefon2>01603052660</Telefon2><Fax></Fax><EMail1>[e-mail]</EMail1>
<EMail2></EMail2><URL></URL><GebDat></GebDat><Firma></Firma><Position></Position><Bem></Bem><InBericht>0</InBericht></Kontakt><Kontakt>
<ID>2</ID><Name>Kollatz</Name><Vorname>Angie</Vorname><Strasse>Philosophenweg 49</Strasse><PLZ></PLZ><Ort>Kassel</Ort><Land></Land>
<Telefon1></Telefon1><Telefon2>0176 24524122</Telefon2><Fax></Fax><EMail1></EMail1><EMail2></EMail2><URL></URL><GebDat></GebDat><Firma>
</Firma><Position></Position><Bem></Bem><InBericht>0</InBericht>

(Die Zeilenumbrüche habe ich schon eingefügt, damit es nicht den Thread zerschießt.)
ist ein Ausschnitt aus einer XML datei die von einem programm angelegt wurde. Also unter einfach mit dem Editor bearbeiten verstehe ich as anderes.

[Daniel Schuhmann]

Könntest Du bitte noch ein paar Umbrüche einfügen, damit der Thread auf mit 1280 noch auf den Bildschirm paßt? :lol:

Ordentlich formatiert, dazu mit einem Editor, der Syntax-Highlighting beherrscht, lässt es sich schon deutlich besser lesen. Ist bei HTML genau das selbe, das kann man häßlich schreiben (oder von Wysiwyg-Editoren schreiben lassen), oder man strukturiert es ordentlich und kann es auch lesen. Auch bei Delphi-Quelltexten ist es das selbe ;)
XML ist halt bei verschachtelten Datenformaten im Vorteil, das kann eine Ini nicht. Und so ein Format ist mir tausendmal lieber, als eine binäre Datei. Die eierlegende Wollmilchsau ist XML natürlich nicht, und für das Speichern von drei Häkchen im Programm würd ich schon lieber ne Ini oder die Registry vorziehen.

Daniel

[Robert_G]

Zitat:

Zitat von Luckie

Das

Zitat:

...

(Die Zeilenumbrüche habe ich schon eingefügt, damit es nicht den Thread zerschießt.)
ist ein Ausschnitt aus einer XML datei die von einem programm angelegt wurde. Also unter einfach mit dem Editor bearbeiten verstehe ich as anderes.

Ich habe das mal einfach in meinen XML Editor gewofen und *plopp* konnte ich es in einem Grid editieren.
Seit wann gibt es Tools die das mit altem INI-Krams ermöglichen? :gruebel:

[Luckie]

Aber das hat ja gerade Hansa so angepriesen, dass man es "einfach" mit einem Editor editieren könnte, jetzt brauche ich ja doch wieder einen spezial Editor... :roll:

Aber auch mit einem Syntaxhighlighter sieht das nicht besser aus, siehe Anhang dazu.

Zitat:

Zitat von Luckie

Das

Zitat:

...

(Die Zeilenumbrüche habe ich schon eingefügt, damit es nicht den Thread zerschießt.)
ist ein Ausschnitt aus einer XML datei die von einem programm angelegt wurde. Also unter einfach mit dem Editor bearbeiten verstehe ich as anderes.

Zitat:

Zitat von Robert_G

Ich habe das mal einfach in meinen XML Editor gewofen und *plopp* konnte ich es in einem Grid editieren.
Seit wann gibt es Tools die das mit altem INI-Krams ermöglichen? :gruebel:

Für Ini-dateien braucht man das eben nicht, aber da findet man bestimmt ähnliches Tools.

[Hansa]

Luckie, deshalb benutze ich ja INIs. Aber es ist trotzdem nicht von der Hand zu weisen, daß man auch XML editieren kann. Übersichtlich aber auch nur mit einem XML-Editor, also wieder extra-Programm oder rumstochern im Original XML file. Sogar letzteres wäre mir lieber als die Registry. Und glaubt mir : Programme, bei denen nicht glasklar ist, was sie machen und wo sie was speichern, die installiert keiner mehr ! Beim kleinsten Verdacht, daß am System was umgestellt werden muß, nur um ein Programm laufen zu lassen, bei der Registry ist das eben so, diese Programme wandern eher in die Tonne, als auf die Festplatte.

[Daniel Schuhmann]

Zitat:

Zitat von Luckie

Aber auch mit einem Syntaxhighlighter sieht das nicht besser aus, siehe Anhang dazu.

Bitte mein ordentlich formatiert nicht unterschlagen. Ein Delphiprogramm, bei dem ich alles in eine Zeile schreibe, kann auch keiner entziffern, aber schön in Blöcke gepackt kann man es schon lesen. Gilt genauso beispielsweise für Tabellen in HTML.

XML-Code:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<adressdb>
  <XMLFile>
    <MajorVersion>1</MajorVersion>
    <MinorVersion>226</MinorVersion>
    <Computer>HAL9000</Computer>
    <User>Michael</User> 
    <ModifyDate>2005-10-29</ModifyDate>
    <ModifyTime>07:05:18</ModifyTime>
    <RecordCount>44</RecordCount>
    <HighestID>44</HighestID>
  </XMLFile> 
  <Kontakt>
    <ID>1</ID>
    <Name>Alt</Name>
    <Vorname>Stephan</Vorname>
    <Strasse>Ellerhofer Straße 11</Strasse>
    <PLZ>34121</PLZ>
    <Ort>Kassel</Ort>
    
  </Kontakt>
</adressdb>

Sieht schon eher lesbar aus, wie ich finde.

Just my 2 cents.

[Luckie]

Zitat:

Zitat von Daniel Schuhmann

Zitat:

Zitat von Luckie

Aber auch mit einem Syntaxhighlighter sieht das nicht besser aus, siehe Anhang dazu.

Bitte mein ordentlich formatiert nicht unterschlagen.

Ich habe es nicht unterschlagen. Diese Datei wurde von einem Delphi-Programm zur Laufzeit angelegt! Aber das habe ich auch schon gesagt. Muss ich mich jetzt auch noch beim Enstellungen schreiben darüm kümmern, dass es schön aussieht? Dann schreibe ich es doch lieber in einer Ini-Datei weg. da brauche ich mich um das Layout nicht kümmern und kann es mit Sicherheit mit einem einfachen Editor lesen und bearbeiten.

[mschaefer]

Moin, Spätmoin,

also da habt Ihr mal wieder ein 1a-Thema. Das ist immer wieder notwendig und eigentlich nicht wirklich gut geklärt. Derzeit stelle ich eine Programmsammlung gerade auf XML um. Die schnelle Edierbarkeit, sieeh Hansa, steht hier der höheren Verschachtelungstiefe, siehe Luckie, gegenüber. Irgendwann braucht man diese Verschachtelungen.
Im Anhang habe ich eine sehr einfache XML-Konmponente, die mir dabei einiges geholfen hat.


Was mir alledigs immer noch fehlt ist eine Komponente wo man andere Komponenten und deren benötigen Eigenschaften auswählen kann, die dann automatisch bei Programmende in eine in/xml/reg geschrieben werden und bei Programmstart gelesen. Unter Delphi4 hatte ich mal sowas, aber dann kamen da größere Umstellungen mit dem Design-Package und seitdem habe ich die Sache nicht mehr gelöst bekommen. :(. Aber irgendwie muß das auch unter den höheren Delphi-Versionen gehen.


Grüße // Martin

[Daniel G]

Ich nutze bei meinem aktuellen Projekt weder Ini's, noch die Registry (iiih..) oder XML:

Meine Eigenschaften - Struktur:

Delphi-Quellcode:

type
  TSetting = record
   DefaultFile: String[254];
   UseDefaultPath: Boolean;
   FirstStart: Boolean;
   Width: Integer;
   Height: Integer;
   Top: Integer;
   Left: Integer;
  end;

Meine Variablen:

Delphi-Quellcode:

type
  TSettingsFile = File of TSetting;

var
 B: TSettingsFile;
 Sets: TSetting;

Meine Speicher - Funktion:

Delphi-Quellcode:

procedure TForm1.WriteProperties;
var
  TempOut, FileName: String;
begin
  FileName := 'C:\Irgendwo\is.dat';
  try                                      
    AssignFile(B, FileName);
    if FileExists(FileName) then
      Reset(B)
    else
      Rewrite(B);

    Write(B, ProgSettings);
  finally
    CloseFile(B);
  end;
end;

Meine Lese - Funktion:

Delphi-Quellcode:

function TForm1.ReadProperties: TSetting;
var
  FileName: String;
  bWasReaded: Boolean;
  Ent: TSetting;
begin
bwasReaded:=false;
  try
    AssignFile(B, SettingsFile);
    if FileExists(SettingsFile) then begin
      Reset(B);
      while not EOF(B) do
      begin
        Read(B, Ent);
        bWasReaded := True;
      end;
    end
    else
      Rewrite(B);
    finally
     CloseFile(B);
   end;

  if not bWasReaded then
  begin
   Ent.DefaultFile := '';
   Ent.UseDefaultPath := false;
   Ent.FirstStart := True;
  end;

  Result := Ent;
end;

(Mag sein, dass die Prozeduren nicht 100-%ig richtig sind, da etwas "zurechgeschnitten')


Sofern vorhanden, werden die Einstellungen im Anwendungsverzeichniss des jew. Users gespeichert. Darauf weise ich ihn hin, damit die Datei bei Bedarf gefunden und gelöscht werden kann.

[Hansa]

Dir ist aber klar, daß auch hier wieder das Rad neu erfunden wird ? 8) Du ersetzt eine Ini-Textdatei durch eine FILE OF "eigener Typ". Für .NET also schon mal ungeeignet. Etwas vergleichbares wie ein XML-Editor müsste man auch selber schreiben. Auch ein Standard-Editor läßt sich nicht benutzen. Also keine wirkliche Alternative. TIniFile bringt da doch einige nützliche Methoden mit.

[Robert_G]

Moin Daniel,
Was du da nimmst sind typisierte Dateien. Sowas war wohl zu TP-Zeiten "in" aber vergiss nicht, dass du hier darauf vertraus, dass dein record immer gleich groß ist. Eine Änderung im Compiler macht dich auf jeden Fall inkompatibel zu alten Dateien. Zum Beispiel ein D64-Compiler. ;)
Außerdem musst du dich nun zu Fuss mit diesem, seit Delphi1 veralteten, IO Kram rumärgern.
Die dpCollection wäre das was du da machst in "netter". ;)

Zitat:

Delphi-Quellcode:

if not bWasReaded then

Und das von unserem stolzen English-LK'ler :mrgreen:

@Topic
Solche Diskussionen machen wohl nicht viel Sinn für bestehende Anwendungen. Und ehrlich gesagt kapiere ich nicht ganz, warum man sich soviel mit native W32 rumärgert, wo doch solche Dinge für neue Apps durch .Net kinderleicht geworden sind. ;)

Delphi-Quellcode:

uses
   System.Xml.Serialization,
   System.Drawing;
type
   Setting = public class
   public
      property DefaultFile: String;
      property UseDefaultPath: Boolean;
      [XmlAttributeAttribute]
      property FirstStart: Boolean;
      property Location : Point;
      property Size : Size;
      
      property Width : Integer read Size.Width;
      property Height : Integer read Size.Height;
      property Top : Integer read Location.Y;
      property Left : Integer read Location.X;
   end;

Während du oben 5 Zeilen brauchtest um es in ein auf-/abwärts inkompatibles, proprietäres Format zu schreiben, brauche ich 3 um es in ein XML zu schreiben:

Delphi-Quellcode:

begin
   var setting := new Setting();

   setting.DefaultFile := 'x:\y.z';
   setting.Location := new Point(10, 20);
   setting.Size := new Size(100, 200);
   setting.FirstStart := false;

   using writer := new XmlTextWriter('Setting.xml', Encoding.Unicode) do
   begin
      with serializer := new XmlSerializer(typeof(Setting)) do
         serializer.Serialize(writer, setting);
   end;
end;

Oder 3 um es aus einem solchen zu laden:

Delphi-Quellcode:

using reader := new XmlTextReader('Setting.xml') do
   with serializer := new XmlSerializer(typeof(Setting)) do
      var setting := serializer.Deserialize(reader) as Setting;

Oder binär? :gruebel:

Delphi-Quellcode:

using stream := new FileStream('Setting.bin', FileMode.Create) do
with formatter := new BinaryFormatter() do
   formatter.Serialize(stream, setting);

btw: Wo bringt TIniFile nützliche Funktionen mit? Muss man ja alles ständig selbst tippen... :gruebel:

[Hansa]

Alles auf .NET umzustellen ist etwas verfrüht. Was soll das ?

Zitat:

Zitat von Robert_G

...btw: Wo bringt TIniFile nützliche Funktionen mit? Muss man ja alles ständig selbst tippen... :gruebel:

Wie, was selber tippen ? :shock:

[mschaefer]

Moin, Frühmoin,

Naja Net ist wohl noch nicht das Maß der Dinge, aber Robert hat schon eine recht zeilenoptimierte Variante der Einstellungsspeicherung.

Das zeilenfressende Grundproblem haben aber alle gezeigten Varianten bisher: Die Eigenschaften von Fremdobjekten müssen einem Speicherobjekt "im Code" erst zugewiesen werden, bevor diese gespeichert werden. Umgekehrt müssen diese beim Auslesen wieder 'per Code' an die Zielobjekte verteilt werden. Also das Prinzip ist irgendwie unelegant...

Grüße // Martin


PS: Muß mal sehen ob ich dieses alte Testprojekt mit visueller Object- und Propertyauswahl wiederfinde.
Irgendwas knackte noch im Gebälk, aber vom Prinzip funktionierte das schon...

PPS: Projekt verschollen, aber Komponente gefunden, dauert etwas muß mal ein Tesprojekt neu zusammenbauen...

[AndreasP]

mahlzeit,

imho hat jede der bisher genannten möglichkeiten ihre vor und nachteile (mal mehr, mal weniger) und durchaus ihre daseinsberechtigung. die registry solle meiner meinung nach nur für sachen gebraucht werden die explizit was mit windows zu tun haben. sollen es wirklich nur ein paar fenster koordinaten sein reicht eine ini aus, für mehr sollte man schon xml verwenden. eins sollte aber nicht vergessen werden, wenn man z.b. xml eh schon (für was anderes) im projekt hat ist es eigentlich überflüssig auch noch TIniFile einzubinden.

ein paar beiträge zuvor wurde (mit einem ablehnenden unterton) darauf hingewiesen das man ja für xml einen extra editor bräuchte. dazu sind 2 dinge zu sagen:
1 - zur not kann man die xml datei auch in delphi öffnen (getestet D7) und bearbeiten
2 - eigentlich hatt jeder programierer der was auf sich hält eh einen ordentlichen editor auf der platte der über die funktionen von wordpad hinausgeht (was keine kunst ist). es gibt wirklich gute (freeware) editoren wie z.b. pspad oder notepad++. oder wenn es etwas mehr sein darf auch shareware a la ultraedit. (btw die kommplette sprachdatei für meinen AppManager hab ich mit pspad erstellt, und mit den richtigen macros kann man sich viel schreibarbeit sparen und braucht kein spezialisiertes/selbst geschriebenes programm. und auch die setting.xml kann ich damit prima kontrolieren/bearbeiten, inkl. syntaxhighlightning und korrekter formatierung)

um zum kern der diskusion zurürk zu kommen: zum laden und speichern der programm einstellungen verwende ich eine extra klasse die das für mich macht. damit werden alle relevanten eigenschaften beim programmstart ausgelesen und für den weiteren gebrauch vorrätig gehalten (bei den heutigen ram größen halte ich es nicht für sinnvoll die daten immer wieder neu auszulesen, was ja auch performance frisst). über diese klasse werden die eingegebene parameter auch gleich auf plausibilität geprüft und gegebenfalls andere werte gleich mit geändert/hinzugefügt/gelöscht. auch wird ein interner timer gesteuert der das reglmäßige scheichern der daten übernimmt. beim beenden des programmes sorgt die klasse dafür das die daten richtig in einer xml datei geschrieben werden.

//Edit: Schlechtschreibung

[Lord Dave]

@andreasP:

Genau sowas wollte ich hören ;) Das halte ich auch für eine gute Lösung.

Einzig das macht mich stutzig:

Zitat:

auch wird ein interner timer gesteuert der das reglmäßige scheichern der daten übernimmt.

Wozu das?
Ich speichere bei jeder Änderung einer Einstellung die Daten, was macht es für einen Sinn einen Timer damit zu beauftragen? Steigt damit nicht das Risiko, etwa bei einem Absturz eine ungültige Einstellungs-datei zu erzeugen?

[AndreasP]

mahlzeit,

Zitat:

Wozu das?
Ich speichere bei jeder Änderung einer Einstellung die Daten, was macht es für einen Sinn einen Timer damit zu beauftragen? Steigt damit nicht das Risiko, etwa bei einem Absturz eine ungültige Einstellungs-datei zu erzeugen?

das war wohl etwas unglücklich formuliert :stupid: . selbstverständlich werden die einstellungen nur gespeichert wenn sie sich geändert haben, bzw das einstellungsmenü über ok verlassen wird. ich meine damit so ein funktion wie word, das ja auch in regelmäsigen abständen das gerade offene dokument speichert, nur eben für meine katalogdaten.

[Robert_G]

Zitat:

Zitat von Hansa

Alles auf .NET umzustellen ist etwas verfrüht. Was soll das ?
Wie, was selber tippen ? :shock:

Immer wieder überraschend, wieviel Mühe du dir doch machst, nichts zu kapieren. Ich sprach mit keinem Wort über irgendeine Migrierung zu .Net und zeige mir mal wie du Objekte in eine INI serialisieren kannst, alles andere läuft unter "selbst tippen".