Bookmark and DisableControls - ein kleiner Trick mit Interfaces

[Uwe Raabe]

In BeginUpdate sollte besser DisableControls verwendet werden.

[hschmid67]

@Uwe Rabe: Vielen Dank - das ist natürlich ein Fehler

Delphi-Quellcode:

procedure TDBTool.BeginUpdate;
begin
  FBookmark := FDataSet.Bookmark;
  FDataSet.DisableControls;
end;

[Der schöne Günther]

Wenn du wirklich eine Meinung möchtest:

Es ist zwar spaßig, mittels ARC Dinge auszulösen (wie z.B. hier beim TDataSet). Aber abseits von Smart Pointern finde ich das persönlich eher kontraproduktiv.

Angenommen ich bin neu bei euch und sehe deinen Code zum ersten mal. Beim

Delphi-Quellcode:

Dataset.DisableControls();
   try
     { tu hier irgendwas}
   finally
     Dataset.EnableControls;
   end;

-Muster ist auf den ersten Blick alles klar.

Im Fall von

Delphi-Quellcode:

procedure TuIrgendWas;
begin
   BookmarkAndDisable(Dataset);
   { tu hier irgendwas }
end;

sparen wir zwar zwei Zeilen, aber es ist auf den ersten Blick überhaupt nicht ersichtlich was im Hintergrund wirklich passiert. Wenn man den Namen gut wählt sollte das zwar kein Problem sein, aber in anderen Fällen wird das vielleicht doch mal wichtig.

Beim Refactoring sehe ich bei so etwas auch eine Fehlerquelle (diskutiert vor etwas längerer Zeit): http://www.delphipraxis.net/180596-h...ml#post1260998. Bzw. macht es Refactoring unmöglich oder deutlich arbeitsaufwändiger.


Es gibt Fälle wo so etwas eine tolle Sache (mir fallen spontan nur Smart Pointer ein), aber dieser hier gehört mMn nicht dazu - Dafür ist der bestehende Code mit dem try..finally viel zu eindeutig und gut.

[Zacherl]

Sehe ich ähnlich wie Günther. Du hättest wahrscheinlich deine Freude mit C++, da dort das RAII Prinzip zum Einsatz kommt. Solche "Guards" sind da ganz normal. Ich persönlich finde es aber auch ziemlich unübersichtlich, wenn der "finally" Teil vor dem "eigentlichen Code" steht.

Wenn du dir die immer gleichen try..finally Blöcke sparen willst, könnte auch eine anonyme Prozedur ganz interessant sein:

Delphi-Quellcode:

type
  TMyAnonProc = reference to procedure(const Dataset: TDataset);

  TDatasetHelper = record
  public
    class procedure MyProcedure(const Dataset: TDataset; Proc: TMyAnonProc); static;
  end;

{ TDatasetHelper }

class procedure TDatasetHelper.MyProcedure(const Dataset: TDataset; Proc: TMyAnonProc);
var
  lBookmark : TArray<Byte>;
begin
  lBookmark := Dataset.Bookmark;
  Dataset.DisableControls;
  try
    Proc(Dataset);
  finally
    Dataset.Bookmark := lBookmark;
    Dataset.EnableControls;
  end;
end;

Aufruf dann so:

Delphi-Quellcode:

TDatasetHelper.MyProcedure(Dataset, procedure(const Dataset: TDataset)
  begin
    // do something
  end);

[himitsu]

Pssst, per Class-Helper als Funktion and TDataSet hängen, anstatt als irgendwo rumliegende eigenständige Funktion.
So hat man auch mehr Spaß am CodeInsigt/CodeVervollständigung.

Und nein, man kann sich auch das Interface speichern, um schon vor Prozedurende das Freizugeben.

Also das läuft ja bis zum END.

Delphi-Quellcode:

begin
  DataSet.BookmarkAndDisable;
  ...machwas
end;

Aber hier ist vorher Schluss.

Delphi-Quellcode:

var
  Bookmark: IDBTool;  // oder IInterface
begin
  Bookmark := DataSet.BookmarkAndDisable;
  try
    ...machwas
  finally
    Bookmark := nil;  // alternativ kann man auch ein Bookmark.EnableBookmark; anbieten
  end;
  ...machnochwas
end;

Da wir hier ein Interface haben, können wir das Try-Finally auch weglassen, denn Delphi baut implizit ein Try-Finally für solche lokalen Variablen ein, um sie freizugeben/finalisieren.

Delphi-Quellcode:

var
  Bookmark: IDBTool;  // oder IInterface
begin
  Bookmark := DataSet.BookmarkAndDisable;
  ...machwas
  Bookmark := nil;
  ...machnochwas
end;

[Der schöne Günther]

Zitat von himitsu:

Bookmark := nil;

Tut also genau das Gegenteil vom dem was es sagt: Es stellt ein Bookmark auf einem DataSet wieder her. Intuitiv ist das nicht.

Mir ist die (potentielle) Verwirrung die zwei gesparten Zeilen echt nicht wert.

[Uwe Raabe]

Zitat von Der schöne Günther:

Tut also genau das Gegenteil vom dem was es sagt: Es stellt ein Bookmark auf einem DataSet wieder her. Intuitiv ist das nicht.

Eventuell kann man das auch nach dem Muster von TRecall aufbauen - mit anderer Implementierung halt.

[Der schöne Günther]

Wieder was neues kennengelernt, danke!

[himitsu]

Zitat von Der schöne Günther:

Mir ist die (potentielle) Verwirrung die zwei gesparten Zeilen echt nicht wert.

OK, aber da muß man ja nur einfach die Variale anders "benamsen".

[hschmid67]

Hallo Leute,
vielen Dank für Eure Diskussion. In letzter Zeit finde ich Interfaces an manchen Stellen ganz Klasse, weil ich mir die vielen try...finally...end-Blöcke spare, die meinen Code manchmal ganz schon unübersichtlich machen.

@Günther: Danke aber für den Hinweis, dass man besser erkennt, was getan wird, wenn man alles schön ausschreibt. Das sollte ich sicherlich berücksichtigen, wenn ich weiter mit Interfaces und dem damit möglichen Aufräumen experimentiere. Sieht man noch, was getan wird, oder verwirrt es nur, weil man vielleicht versucht doppelt aufzuräumen?

@Zacherl: Ja, auch die Überlegung mit anonymen Prozeduren hatte ich, als ich mir das Ganze überlegte. Ist sicher eine Möglichkeit, aber der Code wird nicht so schön aufgeräumt dadurch. Eine Prozedur in der Procedure lohnt im vorliegenden Fall wohl nicht wirklich. Aber für andere Konstrukte, wo man was umgeben, umklammern möchte, ist das sicher eine Option.

Vielleicht lässt sich der Gefahr der Unübersichtlichkeit hier wirklich durch einen besseren Namen übergeben. Wenn ich schreibe:

Delphi-Quellcode:

  ProtectDatasetCursor(Dataset);  // statt BookmarkAndDisable
  { tu hier irgendwas }

Dann könnte das - zumindest in meinen Augen - dem Ganzen näher kommen und wäre damit möglicherweise intuitiver. Aber das ist vielleicht auch Ansichtssache.

Viele Grüße
Harald