KodeZwergs TIniHelper Klasse

[KodeZwerg]

Öhm... also der Grundgedanke war nicht das Rad (IniFiles.pas) neu zu erfinden, nur die Handhabung stark zu simplifizieren.

Vielleicht einmal global definiert, ab da nurnoch mit den einfachen Befehlen zum lesen/schreiben aufrufen.
Ob nun mit oder ohne Crypt sei mal dahingestellt.

Wenn ich alle Typen in der Klasse aufgenommen habe kommt weitere funktionalität hinzu, wie die Ausnutzung der MemIniFile Klasse um mehrere Dinge abarbeiten zu können ohne dauernd öffnen/schließen zu müssen und zu guter letzt System-Registry einbindung.

Ich schaue mich mal auf Gammatesters Seite nach Crypt Alternativen um und wie da so die Lizensen sind.
Oder ich lasse es komplett raus und biete lediglich Schnittstellen an damit jeder das Einbinden kann was er hat oder eben nichts.

Großprojekte wie DEC oder DPCrypt als Voraussetzung zu stellen ist ja auch nicht jedermanns Sache.

Eine Formatierung der .ini Datei werde ich mit Sicherheit erstmal nicht berücksichtigen da es mir schlicht weg egal ist.
Aber netter Gedanke.

Da das Projekt anscheinend abgelehnt wird bleibt es wohl dabei. Danke für Feedback.

[mkinzler]

Zitat:

Großprojekte wie DEC oder DPCrypt als Voraussetzung zu stellen ist ja auch nicht jedermanns Sache.

Besser als externe Abhängigkeiten. Oder man verwendet die direkte Unterstützung des Betriebsystems.

[EdAdvokat]

Hallo KodeZwerg,
beim Kompilieren Deines Programms mit der AES 128-Verschlüsselung erhalte ich folgende Exception:

Zitat:

[dcc32 Fehler] Crypto.pas(44): E2250 Es gibt keine überladene Version von 'EncodeBytes', die man mit diesen Argumenten aufrufen kann
[dcc32 Fehler] Crypto.pas(56): E2010 Inkompatible Typen: 'System.TArray<System.Byte>' und 'TIdBytes'

Das tritt beim Aufruf der Function Base64_Encode auf:

Delphi-Quellcode:

function Base64_Encode(Value: TBytes): string;
var
  Encoder: TIdEncoderMIME;
begin
  Encoder := TIdEncoderMIME.Create(nil);
  try
    Result := Encoder.EncodeBytes(Value);
  finally
    Encoder.Free;
  end;
end;

mache ich da was falsch oder wie hängt das zusammen.
Dein vorheriges Programm mit der xor-Verschlüsselung läuft gut durch.

[Uwe Raabe]

System.NetEncoding.pas kann das auch mit TBytes:

Delphi-Quellcode:

function Base64_Encode(Value: TBytes): string;
begin
  Result := TNetEncoding.Base64.EncodeBytesToString(Value);
end;

[DieDolly]

Wenn ich mich nicht irre sind die TId's wesentlich schneller. Ich mache immer einen großen Bogen um die Delphi-eigenen Funktionen, da die einfach zu langsam sind.

[EdAdvokat]

habe nun den Rat von Uwe Raabe befolgt und einfach in den
Proceduren read und write

Delphi-Quellcode:

 ...if WriteIniCryptString( 'Testfile.cfg', 'Setup', 'CryptStringEntry', 'This is a Crypted String.', '-967283')  then
      begin
        Memo1.Lines.Add( 'CryptStringEntry Saved.' )
      end...

den Wert -967283 in Hochkomma gesetzt.
Hoffentlich war das exakt, doch so klappt es, denn eine Inkompatibilität von String und Integer wurde angemahnt.
Da writeIniCryptString strings verlangt, glaube ich somit richtig zu liegen.

[Alter Mann]

Frage am Rande:

Wo bitte wird TIniHelper aufgerufen/verwendet?

[Uwe Raabe]

Zitat von DieDolly:

Wenn ich mich nicht irre sind die TId's wesentlich schneller. Ich mache immer einen großen Bogen um die Delphi-eigenen Funktionen, da die einfach zu langsam sind.

1. Kannst du das irgendwie belegen oder ist das nur ein Vorurteil?
2. Ist schneller in diesem Kontext (IniFiles) wirklich relevant?
3. Finde ich den Aufruf von TNetEncoding wesentlich eleganter.
4. Was, wenn die Indys nun mal keine TBytes akzeptieren?
5. Will ich wirklich eine zusätzliche Abhängigkeit zu den Indy Packages (wenn ich z.B. mit Packages compiliere)?

[Uwe Raabe]

Zitat von DieDolly:

Wenn ich mich nicht irre sind die TId's wesentlich schneller. Ich mache immer einen großen Bogen um die Delphi-eigenen Funktionen, da die einfach zu langsam sind.

Kurzer Performancetest beweist übrigens das Gegenteil. Die Delphi Implementierung ist sogar noch geringfügig schneller. Dabei habe ich die notwendige TBytes -> TIdBytes Konvertierung sogar noch nicht mal berücksichtigt.