1

To overcome a bug in 10.3.3 (see QC report https://quality.embarcadero.com/browse/RSP-29565) relating to TFDTable detailed elsewhere (Delphi TFDTable open fails when indexname is set), I want to be able to define a class with a method in a common unit that can be assigned (programmatically) as a BeforeOpen event in the relevant DFM for TFDTable components defined on a Form or DataModule.

I realize that this question has been asked before (e.g. How to make a separate unit for event methods, which IDE allows me to assign to component events at design time?), but the solutions batted about there match what I have done, and they do not work.

So, in a unit that must already be listed in the uses clause of the units using TFDTable, I define my class thus:

Common_unit:

type
  TmyMethodHolder = class(TComponent)
  published
    procedure FDTableBeforeOpen(DataSet: TDataSet);
  end;

...

var
  myMethodHolder : TmyMethodHolder=nil;

...

procedure TmyMethodHolder.FDTableBeforeOpen(DataSet: TDataSet);
begin
  // this procedure below is also defined within this "common_unit" 
  FDTableSetCatalogName(Dataset);
end;

...

initialization
  myMethodHolder := TmyMethodHolder.Create(nil);
finalization
  myMethodHolder.Free;

In the Registration unit, the component (and the class - though this seems to make no difference) are registered as follows:

RegisterComponents('MyComponents', [TmyMethodHolder]);
RegisterClass(TmyMethodHolder);

Finally, in a test unit, I define a Form with a TFDTable. That unit uses the "common_unit" above:

unit FDTable_Bug_Demo2;

interface

uses
  ... Common_Unit, ....

type

  TForm2 = class(TForm)
    DBGrid1: TDBGrid;
    Button1: TButton;
    FDConnection1: TFDConnection;
    DataSource1: TDataSource;
    edServer: TLabeledEdit;
    edDatabase: TLabeledEdit;
    edUserName: TLabeledEdit;
    edPassword: TLabeledEdit;
    Button2: TButton;
    Button3: TButton;
    FDTable1: TFDTable;
    ...

With the above in place, I can assign the BeforeOpen event of FDTable1 at runtime like so, and everything works as expected:

FDTable1.BeforeOpen := myMethodHolder.FDTableBeforeOpen;

However, I cannot assign the BeforeOpen event of FDTable1 at design-time (to e.g. myMethodHolder.FDTableBeforeOpen). The IDE complains that it is not a valid identifier.

Even if I drop a TMyMethodHolder component onto the Form as myMethodHolder1 (which rather defeats my purpose), I cannot assign the BeforeOpen event to myMethodHolder1.FDTableBeforeOpen. Again, not a valid identifier.

I assume what I am trying to do is possible, and I have just missed something basic. Help please.

TomB
  • 750
  • 4
  • 17
  • 1
    AFAIK, the Object inspector only allows methods of Form/Frame/DataModule objects to be assigned to component events at design-time, not methods of other components. And part of that has to do with the way the DFM streams event handlers, looking up event handlers by name relative to the `Root` component that the DFM belongs to. – Remy Lebeau Jun 15 '20 at 22:13
  • @Remy Thanks for that. Perhaps I can stop beating my head against the wall. – TomB Jun 15 '20 at 22:37
  • 1
    Why not just create an interposer class named `TFDTable` that derives from `FireDAC.Comp.Client.TFDTable`? It can override the virtual `DoBeforeOpen()` method, and you don't have to install it into the IDE if it is in another unit, just make sure that unit is in the Form/DataModule's `uses` clause after the `FireDAC.Comp.Client` unit, so that your `TFDTable` is the last one in scope so the DFM will stream it instead. – Remy Lebeau Jun 15 '20 at 22:41
  • @Remy I was thinking of doing something like that but subclassing it as e.g. TmyFDtable - which would require wholesale changes. I did not realize I could use the same name in the descendant class. That does look very promising. – TomB Jun 15 '20 at 23:25
  • As an alternative: Maybe this is fixed in 10.4 and you can upgrade to that? – Jan Doggen Jun 16 '20 at 15:26
  • @Jan Yes I was always hoping that this would be an interim fix. I dont believe it has been fixed in 10.4 yet, as it ws only introduced in 10.3. I have a QC report in FWIW. – TomB Jun 16 '20 at 17:22

1 Answers1

1

As per Remy Lebeau's comment, this looks like the best avenue of attack:

Why not just create an interposer class named TFDTable that derives from FireDAC.Comp.Client.TFDTable? It can override the virtual DoBeforeOpen() method, and you don't have to install it into the IDE if it is in another unit, just make sure that unit is in the Form/DataModule's uses clause after the FireDAC.Comp.Client unit, so that your TFDTable is the last one in scope so the DFM will stream it instead

Jan Doggen
  • 8,799
  • 13
  • 70
  • 144
TomB
  • 750
  • 4
  • 17