Bookmark and DisableControls - ein kleiner Trick mit Interfaces

[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

[himitsu]

Das "sparen" ist aber nicht so wichtig ... darüber Nachdenken sollte man dennoch, ob und wo sowas nötig wäre.

Aber falls es mal vergessen wurde, dann wird es im Notfall dennoch immer freigegeben und es gibt keinen Deadlock.