Evento comun para tablas
 

Saludos.. tengo muchas tablas y lo que quiero es tener un evento comun para todas ellas en el evento AfterPost, de forma que todas realicen la misma accion, que es FlushBuffers.
Me explico, en el avento AfterPost de Tabla1 tener Tabla1.FlushBufers, en el de Tabla2 tener Tabla2.FlushBuffers,.....
pues en vez de tener que escribir todo esto

Código Delphi [-]
procedure TModuloDatos.Tabla1AfterPost(DataSet: TDataSet);
begin
  Tabla1.FlushBuffers;
end;

procedure TModuloDatos.Tabla2AfterPost(DataSet: TDataSet);
begin
  Tabla2.FlushBuffers;
end;

etc etc

poder tener un procedure que le pueda asignar a todos los eventos Afterpost y realice esta acción.
(Delphi6, Paradox)
Gracias.

Hola, puedes crear un evento común y asignarlo en la creación del datamodulo a todos los componentes que requieras. En esa asignación, puedes validar que no tenga un evento asignado para evitar inconvenientes.

Código Delphi [-]
..
private
  procedure TablaAfterPost(DataSet: TDataSet);
..

procedure TModuloDatos.TablaAfterPost(DataSet: TDataSet);
begin
  //No se que tipo de Dataset estés manejando así que acá debes manejar el tipo correcto
  TTable(Dataset).FlushBuffers;
end;

procedure TModuloDatos.DataModuleCreate(Sender: TObject);
  var
    i: integer;
begin
  for i := 0 to Self.ComponentCount - 1 do
  begin
    //No se que tipo de Dataset estés manejando así que acá debes manejar el tipo correcto
    if Self.Components[i] is TTable
      and (not Assigned(TTable(Self.Components[i]).AfterPost))
    then
      TTable(Self.Components[i]).AfterPost := TablaAfterPost;
  end;
end;

Otra opción puede ser crear un derivado del componente TTable (TTableAF), con una propiedad AutoFlushBuffers, que por defecto tenga valor True.
Si la propiedad está a True, después del evento AfterPost, realizar el FlushBuffers.

Sólo te queda cambiar en el .PAS y en .DFM las apariciones de TTable por TTableAF

Es una buena opción.

Código Delphi [-]
unit TableAF;

interface

uses
  SysUtils, Classes, DB, DBTables;

type
  TTableAF = class(TTable)
  private
    FAutoFlushBuffers: Boolean;
    procedure SetAutoFlushBuffers(const Value: Boolean);
    { Private declarations }
  protected
    procedure DoAfterPost; override;
    { Protected declarations }
  public
    { Public declarations }
  published
    property AutoFlushBuffers: Boolean read FAutoFlushBuffers write SetAutoFlushBuffers default True;
    { Published declarations }
  end;

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('MyBDE', [TTableAF]);
end;

{ TTableAF }

procedure TTableAF.DoAfterPost;
begin
  inherited;

  if FAutoFlushBuffers then
    Self.FlushBuffers;
end;

procedure TTableAF.SetAutoFlushBuffers(const Value: Boolean);
begin
  FAutoFlushBuffers := Value;
end;

end.

Muchas Gracias. Lo he implementado con la primera indicacion de movorack ... me ha parecido mas simple y lo mismo de efectiva.

Como me gusta leer a los que saben… :)

Una consulta referente a este tema:
Hace un tiempo descubrí (creo que aquí en el foro) un tipo de herencia (no recuerdo como lo llamaron) que consistía en definir la clase tal que así…

TTable = class(Bde.DBTables.TTable).

En el caso que nos ocupa, y si en todas mis unidades pongo en el uses mi unidad antes que la unidad Bde.DBTables…

¿ Serviría para no tener que modificar en todos los .pas y .dfm las apariciones de TTable por TTableAF ?
¿ Sería recomendable una solución de este tipo ?
¿Ventajas y/o inconvenientes?

En principio no sería necesario el registro, y la propiedad AutoFlushBuffers debería ser publica en lugar de publicada

Se denominan Clases Interpuestas o Interpose Classes.

En este artículo de Ian Marteens se habla un poco de ellas, aunque es algo antiguo.

Un saludo

Justo a eso me refería [movorack].
Gracias por la implementación. La pensé pero no tuve tiempo de plasmarla.

^\||/^\||/^\||/

Gracias [ElKurgan] por el enlace al artículo.

Después de su lectura me queda mucho más clara su utilización y veo que estaba equivocado :confused: en cuanto al orden de las unidades en el uses que propongo en mi respuesta anterior. Se remarca esto en el final del artículo.

Es verdad, no había caído en ello. Pero tiene su lógica, ya que todo lo "principal" lo hace la clase original, y solo el añadido es el de la clase interpuesta

Un saludo