Fastreport TfrxReport ableiten

[smudo]

Hallo,

wir leiten vom TfrxReport eine Komponente mit erweiterter Funktionalität ab

Code:

TfrxKuvertierReport = class(TfrxReport)
private
  FOnStartKC: TNotifyEvent;
public
  procedure ShowKuvertierReport(ClearLastReport: Boolean = True);
published
  property OnStartKC: TNotifyEvent read FOnStartKC write FOnStartKC;
  property KuvertierFont : TFont read FKuvertierFont write FKuvertierFont;
end;

Die Komponente haben wir installiert, das läuft auch prima.
Einziges Problem: Die published-properties.
Die Eigenschaft KuvertierFont wird zwar im Objectinspector des Designers angezeigt, es kann aber im Code des Reports nicht darauf zugegriffen werden. Grund: Beim Zugriff auf Report erscheint der Fehler Unknown type: 'TfrxKuvertierReport'
Das Event taucht erst gar nicht im OI auf.

Kann jemand helfen?

[Furtbichler]

Also ich würde das nicht machen. Lieber ein TFrxReport auf ein Datenmodul, dann die Funktionalität dazupacken.

Den Font bekommst du vielleicht noch mit einer Variablendeklaration in FastReport hin, aber das Event...? Willst Du im Script-Code darauf zugreifen?

[smudo]

Wieso würdest du das nicht machen?
Unsere Komponente sieht natürlich etwas umfangreicher aus, als hier dargestellt und wie gesagt, sie läuft seit Jahren problemlos. Wir würden nur gern eigene Events auslösen und darauf im Scriptcode reagieren.

[sx2008]

Ich würde das auch nicht von TFrxReport ableiten.
Stattdessen würde ich eigene "PrintJob"-Klassen schreiben:

Delphi-Quellcode:

TPrintJob = class(TObject)
private
  FReport : TFrxReport;
protected
  procedure BeforePrint;virtual;
public
  constructor Create(report:TFrxReport); // Report wird im Konstruktor übergeben
  procedure ShowKuvertierReport(ClearLastReport: Boolean = True);
  property Demo:Boolean;
  property CopyCount:Integer;
  property Script:TScriptExecuter;
end;

procedure TPrintJob.ShowKuvertierReport(ClearLastReport: Boolean = True);
begin
  // hier werden die Datenfelder für das Kuvert befüllt
  // und dazu Scripts aufgerufen
  ....
  ....
  FReport.Preview; // oder so ähnlich
end;

Das ist im Prinzip ähnlich wie der Vorschlag von Furtbichler, nur dass man die Klasse TPrintJob relativ allgemein halten kann und damit mehrfach verwenden kann.
Ich habe mit dieser Technik z.B. einen "Demo"-Schriftzug dynamisch zur Laufzeit erzeugt, falls das Programm keine Lizenz gefunden hat.
Man kann auch von TPrintJob ableiten und so mehrere problemangepasste Klassen erzeugen. z.B. TLabelPrintJob, TKuvertPrintJob, TListenPrintJob

[smudo]

Das mit der Printjob-Klasse ist natürlich grundsätzlich richtig, aber wir müssen zur Laufzeit in die Reportpage eigene frx-Komponenten zeichnen, das macht sich einfach besser mit der Ableitung.
Außerdem sehe ich darin keine Lösung bezüglich der auszulösenden Ereignisse.
Wenn eine eigene frx-Komponente gezeichnet wird, soll der Report bestimmte Ereignisse auslösen.