TIniFile umbiegen zu TIniMemFile

[Jim Carrey]

Ziemlich dumme Frage bitte verzeiht mir.
Aber gibt es eine Möglichkeit die Deklaration von TIniFile so umzubiegen, dass TMemIniFile benutzt wird und zusätzlich bei MeineIniDatei.Free; dann .UpdateFile + Free ausgeführt wird?

Was ich meine ist... ich möchte trotzdem überall TIniFile hinschreiben, es soll aber TMemIniFile benutzt werden und bei Free sollen 2 Aktionen ausgeführt werden.
Ich habe soetwas noch nie gemacht und weiß daher nicht ob es möglich ist.

[Benedikt Magnus]

Du könntest deine eigene Klasse von TMemIniFile ableiten:

Delphi-Quellcode:

interface

type
  TMeineIniFile = class(TMemIniFile)
  public
    destructor Destroy; override;
  end;

implementation

destructor TMeineIniFile.Destroy;
begin
  UpdateFile;
  inherited;
end;

Dann müsstest du allerdings "TMeineIniFile" statt "TIniFile" schreiben...


Edit: Gerade eingefallen, besser wäre natürlich so etwas:

Delphi-Quellcode:

interface

type
  TMeineIniFile = class(TMemIniFile)
  public
    procedure UpdateFileAndFree;
  end;

implementation

procedure TMeineIniFile.UpdateFileAndFree;
begin
  UpdateFile;
  Free;
end;

[Fritzew]

Klar ist das möglich:

Delphi-Quellcode:

Tinifile = class(Tmeminifile)
 // jede menge code also zb
 destructor destroy: override;
end;


destructor tinifile.Destroy;
begin
 UpdateFile;
inherited;
end;

nur so hingetipt
aber so eine klasse in eine eigene unit und darauf achten das die Unit als letztes eingebunden wird wo man diese verwende will.
Dann reicht ein

Delphi-Quellcode:

uses
 // jede menge units
meineIniUnit;

[Jim Carrey]

Ohne euren Code gelesen zu haben, hier mal mein Versuch, damit ihr seht ich versuche es wenigstens :stupid:

Delphi-Quellcode:

type
 TIniFile = class(TMemIniFile)
 
 public
  procedure Free; override;
 end;

procedure TIniFile.Free;
begin
 TMemIniFile.UpdateFile;
end;

[Fritzew]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1352785)

Du könntest deine eigene Klasse von TMemIniFile ableiten:

Dann müsstest du allerdings "TMeineIniFile" statt "TIniFile" schreiben...


Edit: Gerade eingefallen, besser wäre natürlich so etwas:

Delphi-Quellcode:

interface

type
  TMeineIniFile = class(TMemIniFile)
  public
    procedure UpdateFileAndFree;
  end;

implementation

procedure TMeineIniFile.UpdateFileAndFree;
begin
  UpdateFile;
  Free;
end;

Entschuldige das ist Quatsch.

Wieso eine extra Procedure die nichts anderes macht als ein Destructor?

Eine Klasse die sich selber in einer Procedure/Function zerstört verletzt ja wohl alle OOP Regeln ;-)

[Jim Carrey]

Wieder etwas dazugelernt, danke euch :thumb:

[Benedikt Magnus]

Zitat:

Zitat von Fritzew (Beitrag 1352788)

Entschuldige das ist Quatsch.

Wieso eine extra Procedure die nichts anderes macht als ein Destructor?

Eine Klasse die sich selber in einer Procedure/Function zerstört verletzt ja wohl alle OOP Regeln ;-)

Ganz einfach weil eine Prozedur das machen sollte, was ihre Bezeichnung aussagt. Und eine weitere Funktion an den Destruktor zu hängen finde ich unsauber. :wink:

Ich wüsste jetzt nicht, warum eine Prozedur "TueDiesUndFree" irgendeine Regel der OOP verletzen sollte...

Zitat:

Zitat von Jim Carrey (Beitrag 1352789)

Wieder etwas dazugelernt, danke euch :thumb:

Achte nur auf das "inherited" in deinem Destruktor und dass du Destroy statt Free überschreibst.

[Fritzew]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1352791)

Zitat:

Zitat von Fritzew (Beitrag 1352788)

Entschuldige das ist Quatsch.

Wieso eine extra Procedure die nichts anderes macht als ein Destructor?

Eine Klasse die sich selber in einer Procedure/Function zerstört verletzt ja wohl alle OOP Regeln ;-)

Ganz einfach weil eine Prozedur das machen sollte, was ihre Bezeichnung aussagt. Und eine weitere Funktion an den Destruktor zu hängen finde ich unsauber. :wink:

Ich wüsste jetzt nicht, warum eine Prozedur "TueDiesUndFree" irgendeine Regel der OOP verletzen sollte...

Zitat:

Zitat von Jim Carrey (Beitrag 1352789)

Wieder etwas dazugelernt, danke euch :thumb:

Achte nur auf das "inherited" in deinem Destruktor und dass du Destroy statt Free überschreibst.

Ganz einfach

Deine klasse kann man nicht benutzen wie jede andere

normalerweise erwartet man nicht das eine Procedure die Klasse freigibt.

immer
1.create
2.arbeiten
3.freigeben

Delphi-Quellcode:

T := TIrgendwas.create;
try
  t.tuewas;
t.UpdateFileAndFree; // Du gibts die klasse frei
t.tuewasanders; // Knallt


finally
 t.free;
end;

Wenn Du das verhalten änderst ist das einfach falsch.
Wenn schon überschreibe den destructor.

[Benedikt Magnus]

Zitat:

Zitat von Fritzew (Beitrag 1352795)

Ganz einfach

Deine klasse kann man nicht benutzen wie jede andere

normalerweise erwartet man nicht das eine Procedure die Klasse freigibt.

immer
1.create
2.arbeiten
3.freigeben

Delphi-Quellcode:

T := TIrgendwas.Create;
try
  t.tuewas;
t.UpdateFileAndFree; // Du gibts die klasse frei
t.tuewasanders; // Knallt


finally
 t.free;
end;

Wenn Du das verhalten änderst ist das einfach falsch.
Wenn schon überschreibe den destructor.

Versuche es doch mal so:

Delphi-Quellcode:

T := TIrgendwas.create;
try
  T.TueEtwas;
  T.UpdateFile; 
  T.TueEtwasAnderes; 
finally
  T.UpdateFileAndFree;
end;

[Fritzew]

Delphi-Quellcode:

T := TIrgendwas.create;
try
  T.TueEtwas;
  T.UpdateFile; 
  T.TueEtwasAnderes; 
finally
  T.UpdateFileAndFree;
end;

Klasse.

Warum das normale verhalten ändern?
Echt das musst Du mir erklären.
Was ist an Deiner Lösung besser?

Achte mal auf die Fragestellung.
Ich binde eine andere Unit ein und fertig.
Du musst jeden Aufruf von free durch Deine Routine ersetzen.
Wenn das besser ist dann sei es so.

[Benedikt Magnus]

Zitat:

Zitat von Fritzew (Beitrag 1352797)

Warum das normale verhalten ändern?
Echt das musst Du mir erklären.
Was ist an Deiner Lösung besser?

Weil das normale Verhalten geändert wurde. So ist es nunmal sauberer.

Zitat:

Zitat von Fritzew (Beitrag 1352797)

Achte mal auf die Fragestellung.
Ich binde eine andere Unit ein und fertig.
Du musst jeden Aufruf von free durch Deine Routine ersetzen.
Wenn das besser ist dann sei es so.

Wie du an meiner Antwort sehen kannst, habe ich zwei Vorschläge gemacht, oder? Und mein Erster ist ein anderer.

Aber ich höre jetzt auf, darüber zu diskutieren. Das erscheint mir nicht sehr sinnvoll und wird langsam Off-Topic...

[Daniel]

Zitat:

Zitat von Fritzew (Beitrag 1352797)

Achte mal auf die Fragestellung.

Achte bitte ein wenig darauf, wie sich Deine Beiträge für Dritte darstellen könnten. Du wirkst ausgesprochen schroff - auch wenn dies möglicherweise nicht so gemeint ist.

[Fritzew]

Dein erster Vorschlag war ja auch in Ordnung.

Ich habe einfach ein Problem mit "unerwartetem" Verhalten von Klassen.
Und eine Procedure/ Function die eine Klasse freigibt ist für mich unerwartet. Dafür gibt es nämlich genau eine Lösung
den Destructor.

Aber nichts für ungut.

[Uwe Raabe]

Zitat:

Zitat von Jim Carrey (Beitrag 1352782)

Aber gibt es eine Möglichkeit die Deklaration von TIniFile so umzubiegen, dass TMemIniFile benutzt wird und zusätzlich bei MeineIniDatei.Free; dann .UpdateFile + Free ausgeführt wird?

Ich habe noch nicht so recht den Sinn hinter dieser Aktion verstanden, aber in der Regel verwendet man im Programm überall

Delphi-Quellcode:

TCustomIniFile

(der gemeinsame Vorfahre von

Delphi-Quellcode:

TIniFile

und

Delphi-Quellcode:

TMemIniFile

). Bei der Erzeugung wird dann entweder eine

Delphi-Quellcode:

TIniFile

- oder

Delphi-Quellcode:

TMemIniFile

-Instanz oder sonst eine Ableitung von

Delphi-Quellcode:

TCustomIniFile

erzeugt. Das automatische

Delphi-Quellcode:

UpdateFile

wird (ab Berlin) durch ein

Delphi-Quellcode:

AutoSave := true

realisiert. Das schreibt auch nur, wenn sich wirklich was verändert hat.

[Fritzew]

Zitat:

Zitat von Daniel (Beitrag 1352801)

Zitat:

Zitat von Fritzew (Beitrag 1352797)

Achte mal auf die Fragestellung.

Achte bitte ein wenig darauf, wie sich Deine Beiträge für Dritte darstellen könnten. Du wirkst ausgesprochen schroff - auch wenn dies möglicherweise nicht so gemeint ist.

War bestimmt nicht so gemeint.
Sollte ich jemandem zu nahe getreten sein, tut es mir leid.
Mea culpa

[Lemmy]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1352791)

Ganz einfach weil eine Prozedur das machen sollte, was ihre Bezeichnung aussagt. Und eine weitere Funktion an den Destruktor zu hängen finde ich unsauber. :wink:

Tipp: Schau dir mal BeforeDestruction an, da musst Du weder den Destructor überschreiben noch eine eigene Methode einführen.

[Benedikt Magnus]

Zitat:

Zitat von Lemmy (Beitrag 1352805)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1352791)

Ganz einfach weil eine Prozedur das machen sollte, was ihre Bezeichnung aussagt. Und eine weitere Funktion an den Destruktor zu hängen finde ich unsauber. :wink:

Tipp: Schau dir mal BeforeDestruction an, da musst Du weder den Destructor überschreiben noch eine eigene Methode einführen.

Danke!
Das löst aber nicht das Problem (weshalb ich ursprünglich auf die neue Methode kam), dass auf diese Weise etwas mitunter Unerwartetes beim Freigeben des Objektes passiert, das ich auch nicht mehr unterbinden kann.
Die von Uwe Raabe angesprochene Lösung mit

Delphi-Quellcode:

AutoSave := true

, wie sie in Berlin realisiert wurde, scheint mir daher die eleganteste zu sein. Nichts Unerwartetes, keine neuen Methoden.

[Fritzew]

Um das für mich abzuschließen

Delphi-Quellcode:

unit myini;

interface

uses
   sysutils,
   IniFiles;

type
   tinifile = class(tmeminifile)
   private
      fautosave: boolean;

   public
      constructor Create(const FileName: string; const autosave: boolean = true); overload;
      constructor Create(const FileName: string; const Encoding: TEncoding; const autosave: boolean = true); overload;
      destructor Destroy; override;
   end;

implementation

{ tinifile }

constructor tinifile.Create(const FileName: string; const Encoding: TEncoding; const autosave: boolean = true);
begin
   inherited Create(FileName, Encoding);
   fautosave := autosave;
end;

constructor tinifile.Create(const FileName: string; const autosave: boolean = true);
begin
   inherited Create(FileName);
   fautosave := autosave;
end;

destructor tinifile.Destroy;
begin
   if fautosave then
      UpdateFile;
   inherited;
end;

end.

Diese Unit überall da einbinden wo das neue verhalten gewünscht ist.

[hoika]

Hallo,
dieser Thread scheint der Nachfolger von diesem hier zu sein
http://www.delphipraxis.net/190773-p...ml#post1352810

Und im aktuellen Thread geht es um den Austausch von TIniFile durch TMemIniFile,
ohne den Quellcode zu ändern.
Die neue Klasse und das Einbinden als letzte Unit löst das ja am Besten,
Ob so eine Vorgehensweise gut ist, sei dahingestellt.

Wenn die Code-Stellen abzählbar sind,
kann ich ja gleich TMemIniFile schreiben.

[Rollo62]

Nur mal zum Verständnis:
Wenn du mit "umbiegen" meinst das diese neue TIniFile Klasse dann IMMER statt der alten aufgerufen wird,
egal wo und wann ...
Das wird nicht funktionieren.

Du musst immer deine neue Unit einbinden, also wozu dann den Namen gleich machen ?
Da würde ich schon eher ein IIniFile Interface anlegen, das würde mehr Sinn machen.

Rollo

[Blup]

Zitat:

Zitat von Uwe Raabe (Beitrag 1352803)

Zitat:

Zitat von Jim Carrey (Beitrag 1352782)

Aber gibt es eine Möglichkeit die Deklaration von TIniFile so umzubiegen, dass TMemIniFile benutzt wird und zusätzlich bei MeineIniDatei.Free; dann .UpdateFile + Free ausgeführt wird?

Ich habe noch nicht so recht den Sinn hinter dieser Aktion verstanden, aber in der Regel verwendet man im Programm überall

Delphi-Quellcode:

TCustomIniFile

(der gemeinsame Vorfahre von

Delphi-Quellcode:

TIniFile

und

Delphi-Quellcode:

TMemIniFile

). Bei der Erzeugung wird dann entweder eine

Delphi-Quellcode:

TIniFile

- oder

Delphi-Quellcode:

TMemIniFile

-Instanz oder sonst eine Ableitung von

Delphi-Quellcode:

TCustomIniFile

erzeugt. Das automatische

Delphi-Quellcode:

UpdateFile

wird (ab Berlin) durch ein

Delphi-Quellcode:

AutoSave := true

realisiert. Das schreibt auch nur, wenn sich wirklich was verändert hat.

Leider gibt es schlecht programmierte Komponenten, die nur ein TIniFile akzeptieren, obwohl alle notwendigen Methoden bereits in TCustomIniFile deklariert sind.

Man könnte natürlich ein TMemIniFile zu TIniFile casten, aber das währe mir dann doch ein bischen zu unsauber.
Alternative war dann ein Klassenadapter als Ableitung von TIniFile, der alle virtuellen Methoden überschreibt und auf ein internes TMemIniFile umleited.

[Jim Carrey]

Ich habe mittlerweile alles auf TCustomIniFile als Deklaration und TMemIniFile.Create umgestellt.
Ich muss jetzt zwar höllisch aufpassen, dass ich da wo es gebraucht wird kein UpdateFile vergesse aber das klappt schon.

Zu Berlin will ich aktuell nicht umsteigen, da mein altes XE'schen gut funktioniert.