Prinzip ist verständlich, damit reicht der Quelltext (erstmal) aus:
Delphi-Quellcode:
type
ERefreshError =
Class(
Exception);
type
// diese Klasse kann ich nicht verändern:
TDataSetMitExtraFunktionalitaet =
class(TDataSet)
public
procedure NichtAenderbar;
end;
implementation
procedure TDataSetMitExtraFunktionalitaet.NichtAenderbar
begin
// in dieser Prozedur kann ich nichts ändern
[...]
Refresh;
end;
procedure EignesBeforeRefresh(DataSet: TDataSet);
begin
if meineAbbruchBedingung
then begin
raise ERefreshError.Create('
Refresh nicht zulässig.');
end;
end;
// aber dashier ist änderbar?
procedure Demo;
var
ds1: TDataSetMitExtraFunktionalitaet;
begin
[...]
// hier passiert ein implizierter Refresh, der unterdrückt werden soll:
ds1.OnBeforeRefresh := EignesBeforeRefresh;
Try
ds1.NichtAenderbar;
except
// Das "Fressen" der Exception an dieser Stelle wirkt wie ein Exit in der RefreshMethode.
// TDataSetMitExtraFunktionalitaet.Refresh wird nicht ausgerufen.
on e: ERefreshError
do;
end;
ds1.OnBeforeRefresh :=
Nil;
end;
Würde sowas helfen?
Natürlich scheitert das, wenn in der nichtänderbaren Routine sowas enthalten ist:
Delphi-Quellcode:
procedure TDataSetMitExtraFunktionalitaet.NichtAenderbar(DataSet: TDataSet);
begin
[...]
Refresh;
[...] // Dashier würde dann nichtmehr ausgeführt.
// Wenn das aber ausgeführt werden muss, dann kann man den Vorschlag vergessen.
end;
Ist denn der Quelltext von "NichtAenderbar" so, dass man eventuell auftretende Probleme erkennen kann und nach einer gezielten Lösung suchen kann?