Wahlweise eines von zwei Formularen verwenden

[Matthias Hanft]

Hallo,

blödes Subject, aber ich weiß es nicht besser auszudrücken...

Angenommen, ich habe in einem Delphi-Projekt zwei ganz normale
Formulare Form1 und Form2, die beide wie üblich von TForm ab-
stammen. Auf beiden befinden sich die gleichen statischen
Controls (z.B. ein "Memo1"), lediglich an anderen Positionen
und mit anderem Inhalt (also z.B. ist in einem Bild, das auf
Form2 weiter rechts steht als auf Form1, ein anderes BMP
geladen, oder im Memo1 steht ein anderer Text).

Nun möchte ich in einer Prozedur (anderswo) abhängig von bestimmten
Umständen eine dieser beiden Forms zur Bearbeitung auswählen und z.B.
an die StringList im (jeweils gleichnamigen) Memo1 etwas anfügen.

Im Prinzip also so:

if (irgendwas) then
myForm:=Form1
else
myForm:=Form2;
myForm.Memo1.Lines.Append('Bla.');
[...viele weitere myForm.IrgendeineControl.TuWas...]

Das geht so natürlich nicht, weil das ja andere Klassen sind: myForm
muß, damit man sowohl Form1 als auch Form2 zuweisen kann, vom Vater-Typ
TForm sein, und dort gibts natürlich kein Memo1.

Natürlich ginge nun rein syntaktisch

(myForm as TForm1).Memo1.Lines.Append('Bla.');

aber falls myForm zufällig nicht Form1, sondern Form2 zugewiesen wäre,
gehe ich davon aus, daß das gehörig kracht (auch wenn es in Form2 ein
ebensolches Memo1 gibt). Ist das so? Oder gibt das einen Laufzeitfehler,
wenn in myForm an dieser Stelle TForm2 drinsteht? Egal wie - richtig
und elegant sieht es mir jedenfalls nicht aus :-)

Ich habe schon ein bißchen mit "class of TForm" etc. herumexperimen-
tiert, aber ohne Erfolg. In meinem Hinterkopf spukt herum, daß die
beiden Forms wohl einen gemeinsamen Vater haben müßten (der wiederum
von TForm abstammen dürfte), aber wie geht sowas mit Formularen mit
visuellen Controls (falls überhaupt)?! Oder muß man dazu eine neue
Komponente entwickeln? Diesen Aufwand wollte ich eigentlich vermeiden
(anderer Ausdruck für "habe ich noch nie gemacht, und weil das Projekt
morgen fertig werden muß, habe ich auch keine Zeit, das zu lernen").

Irgendwie denke ich, daß das mit den geeigneten "class of"- und "as"-
Konstrukten relativ simpel gehen müßte, aber anscheinend ist das
Brett vor meinem Kopf momentan einfach noch zu dick - könnte das
bitte jemand entfernen? :-)

Danke & Gruß Matthias.

[Andreas Koch]

Post by Matthias Hanft
Ich habe schon ein bißchen mit "class of TForm" etc. herumexperimen-
tiert, aber ohne Erfolg. In meinem Hinterkopf spukt herum, daß die
beiden Forms wohl einen gemeinsamen Vater haben müßten (der wiederum
von TForm abstammen dürfte), aber wie geht sowas mit Formularen mit
visuellen Controls (falls überhaupt)?!

Datei\Neu\Weitere, Reiter Project1. Da sollten deine existierenden
Formulare drin sein.

Post by Matthias Hanft
Irgendwie denke ich, daß das mit den geeigneten "class of"- und "as"-
Konstrukten relativ simpel gehen müßte, aber anscheinend ist das
Brett vor meinem Kopf momentan einfach noch zu dick - könnte das
bitte jemand entfernen? :-)

Alternativ könntest du mit

TMemo(myform.FindComponent('Memo1')).Add('foo') arbeiten.

[Marian Aldenhövel]

Hi,

Post by Matthias Hanft
Angenommen, ich habe in einem Delphi-Projekt zwei ganz normale
Formulare Form1 und Form2, die beide wie üblich von TForm ab-
stammen.
Nun möchte ich in einer Prozedur (anderswo) abhängig von bestimmten
Umständen eine dieser beiden Forms zur Bearbeitung auswählen und z.B.
an die StringList im (jeweils gleichnamigen) Memo1 etwas anfügen.

Also möchtest Du eigentlich eine Klasse haben, die zwischen TForm und
TForm1 und TForm2 liegt. Die soll das Memo, bzw. die Stringliste in ihrer
Schnittstelle haben. Überall wo Du nicht weißt, welches der beiden
Formulare wirklich vorliegt verwendest Du dann die Zwischenklasse.

Dieses OO-Prinzip nennt man Polymorphismus falls Du wichtige Worte magst
oder es nachschlagen willst. Also ohne IDE-Unterstützung:


type TMemoForm=class(TForm)
protected
procedure SetMemoText(S:TString); virtual; abstract;
function GetMemoText:TStrings; virtual; abstract;
public
property MemoText:TStrings read GetMemoText write SetMemoText;
end;

Das kannst Du so in eine eigene Unit schreiben. Die verwendest Du dann in
den anderen beiden Units, editierst einfach das class(TForm), das die IDE
für Dich dahingeschrieben hat, und machst dann:

type TForm1=class(TMemoForm);
procedure SetMemoText(S:TStrings); override;
function GetMemoText:TStrings; override;
end;

procedure TForm1.SetMemoText(S:TStrings);
begin
Memo1.Lines.Assign(S);
end;

function TFOrm1.GetMemoText:TString;
begin
REsult:=Memo1.Lines;
end;

Dasselbe in Form2. Daß die Komponenten vielleicht in beiden Fällen "Memo1"
heißen und deshalb der Code für Get und Set gleich aussieht musst Du in diesem
Modell hinnehmen. Dafür kannst Du auf Form2 auch eine Listbox nehmen, oder
ein TSuperTollesMemo, dessen Text vielleicht nicht in der Lines-Eigenschaft
steht, sondern in einer namens seniL. Oder so.

Post by Matthias Hanft
if (irgendwas) then
myForm:=Form1
else
myForm:=Form2;
myForm.Memo1.Lines.Append('Bla.');
[...viele weitere myForm.IrgendeineControl.TuWas...]

Wird dann:

var MyForm:TMemoForm;
begin
if (irgendwas) then
myForm:=Form1
else
myForm:=Form2;
myForm.MemoText.Append('Bla');

Das funktioniert, weil jetzt im OO-Sinne sowohl TForm1 und TForm2 TMemoForms
sind. Genau wie sie TForms, TCustomForms, und schließlich sogar TObjects sind.

Das ist die Fußgängermethode.

Post by Matthias Hanft
Auf beiden befinden sich die gleichen statischen Controls (z.B.
ein "Memo1"), lediglich an anderen Positionen und mit anderem Inhalt
(also z.B. ist in einem Bild, das auf Form2 weiter rechts steht als
auf Form1, ein anderes BMP geladen, oder im Memo1 steht ein anderer
Text).

Du entwirfst in der IDE ein TMemoForm mit all' den statischen Komponenten.

Dann sagst Du "Datei/Neu", wählst die Lasche mit Deinem Projekt und das
TMemoForm. Du sagst außerdem "erben" oder wie auch immer das Steuerelement
bei Dir heißt. Ergebnis ist ein Formular im Designer, daß von TMemoForm
erbt und alle Steuerelemente enthält. Die kannst Du nun verschieben,
verändern, und mehr damit anstellen.

Wieder gilt: Der so erzeugte Nachkomme hat alles und kann alles, was seine
Vorgängerklassen auch haben und können.

Zu guter Letzt kannst Du Dir auch noch überlegen, ob Du überhaupt zwei
Formularklassen haben willst oder nicht lieber eine, die sich in
verschiedenen Weisen präsentiert. Also etwas wie:

type TFormMode=(fmSimple,fmComplex);

TForm1=class(TFOrm);
private
FMode:TFormMode;
procedure SetFormMode(aFormMode:TFormMode);
public
property Mode:TFormMode read FMode write SetFormMode;
end;

procedure SetFormMode(aMode:TFormMode);
begin
FMode:=aMode;
Image1.Visible:=(aMode=fmSimple);
Image2.Visible:=(aMode=fmComplex);
case aMode of
fmSimple: Memo1.Left:=200;
fmComplex: Memo1.Left:=99;
else raise Exception.Create('Gier gfehlt was.');
end;
..
end;

Das hängt davon ab, wieviele Unterschiede es gibt, und wie gut Du die
nicht-visuell in den Griff bekommst.

Ciao, MM

[Matthias Hanft]

Hi,

Post by Marian Aldenhövel
type TMemoForm=class(TForm)
protected
procedure SetMemoText(S:TString); virtual; abstract;
function GetMemoText:TStrings; virtual; abstract;
public
property MemoText:TStrings read GetMemoText write SetMemoText;
end;

Danke. Das war die "mittlere Vererbungsschicht", die ich irgendwie auf
dem Brett vor meinem Kopf deutlich stehen hatte, auf die ich aber nicht
selbständig gekommen bin :-) (Polymorphismus kenne und verwende ich selber,
aber in diesem speziellen Fall bin ich einfach nicht draufgekommen, wer
da in welcher Reihenfolge was von wem erben muß).
[...]

Post by Marian Aldenhövel
Dann sagst Du "Datei/Neu", wählst die Lasche mit Deinem Projekt und das
TMemoForm. Du sagst außerdem "erben" oder wie auch immer das Steuerelement
bei Dir heißt. Ergebnis ist ein Formular im Designer, daß von TMemoForm
erbt und alle Steuerelemente enthält. Die kannst Du nun verschieben,
verändern, und mehr damit anstellen.

Uff. Daß man bei "Datei/Neu" auch _eigene_ Formulare als Vorlage nehmen
kann, hatte ich bis heute noch nicht bemerkt. Unglaublich. Ja, ich denke,
das wäre in diesem Fall die beste Lösung. Danke.

Nun habe ich allerdings schon die abgeleiteten Formulare gebaut. Aber
mit etwas manuellen Rumkratzen am automagisch erzeugten Sourcecode
kriegt man die passende Vererbungsreihenfolge sicher auch noch nach-
träglich hin.

Post by Marian Aldenhövel
Zu guter Letzt kannst Du Dir auch noch überlegen, ob Du überhaupt zwei
Formularklassen haben willst oder nicht lieber eine, die sich in

[...]

Post by Marian Aldenhövel
fmSimple: Memo1.Left:=200;
fmComplex: Memo1.Left:=99;

[...]

Post by Marian Aldenhövel
Das hängt davon ab, wieviele Unterschiede es gibt, und wie gut Du die
nicht-visuell in den Griff bekommst.

Hatte ich auch schon dran gedacht, aber das wäre in dem Fall einiger-
maßen ekelhaft: Es handelt sich um Briefbögen verschiedener Firmen,
die mit PowerPdf erzeugt werden (und deren Textfelder dann dynamisch
mit Rechnungstexten gefüllt werden). Ich bin zwar sonst kein großer
Mäuseschubser, aber das Anordnen der ganzen Logos, Absenderangaben,
Bankverbindungen etc., damit dem Kunden sein Briefbogen gefällt, ist
visuell dann doch etwas einfacher :-)

Gruß Matthias.

[Matthias Hanft]

Post by Matthias Hanft
Nun habe ich allerdings schon die abgeleiteten Formulare gebaut. Aber
mit etwas manuellen Rumkratzen am automagisch erzeugten Sourcecode
kriegt man die passende Vererbungsreihenfolge sicher auch noch nach-
träglich hin.

Nach etwas Herumexperimentieren sehe ich keine andere Möglichkeit,
als die Formulare nochmal zu bauen, da die formularabhängigen
Positionen nur dann im abgeleiteten Formular gespeichert werden,
wenn sie vom "Vaterformular" abweichen.

Anders ausgedrückt:

Ich habe jetzt eine TForm1(TForm) und eine TForm2(TForm), auf denen
viele Controls millimetergenau positioniert sind.

Daraus möchte ich eine TFormCommon(TForm), eine TForm1(TFormCommon)
und eine TForm2(TFormCommon) machen, und zwar ohne daß ich die müh-
sam plazierten Controls auf TForm1 und TForm2 nochmal genauso mühsam
an die richtigen Stellen schieben muß.

Geht das? Wie?

Danke & Gruß Matthias.

[NineBerry Schwarz]

Post by Matthias Hanft
Daraus möchte ich eine TFormCommon(TForm), eine
TForm1(TFormCommon) und eine TForm2(TFormCommon) machen, und zwar
ohne daß ich die müh- sam plazierten Controls auf TForm1 und
TForm2 nochmal genauso mühsam an die richtigen Stellen schieben
muß.
Geht das? Wie?

Du musst die abgeleiteten Formulare als Text-DFM bearbeiten und bei der
Form-Klasse das Schlüsselwort "inherited" statt "object" einsetzen.

Neun

[Matthias Hanft]

Post by NineBerry Schwarz
Du musst die abgeleiteten Formulare als Text-DFM bearbeiten und bei der
Form-Klasse das Schlüsselwort "inherited" statt "object" einsetzen.

Danke, hat funktioniert. Warnung an alle, die sowas nachmachen möchten:

- unbedingt vorher ein dauerhaftes Backup aller beteiligten Dateien/
Formulare machen
- _zuerst_ im Source das class(TCommonForm) ersetzen und _dann_ die
Formular-inheriteds einfügen
- bei irgendwelchen Warnungen beim Speichern und/oder Compilieren, daß
irgendetwas fehlt, niemals auf "Ignorieren" oder "Weiter" klicken,
sondern immer auf "Abbrechen" und das Problem näher untersuchen,
sonst können Formulare/Komponenten/Dateien unwiederbringlich ver-
loren sein
- ob sich Formulare als Text anzeigen lassen, hängt davon ab, ob andere,
davon abhängende Formulare bereits als Text geöffnet sind - also
diese ggf. auf Formularanzeige umschalten (die Fehlermeldung bei
Alt-F12 "Formular kann nicht geschlossen werden" ist dabei Unsinn)
- bei absolut nicht nachvollziehbaren Fehlermeldungen ("Komponente
fehlt" o.ä.) einfach mal "Alles schließen" machen und dann das
Projekt neu öffnen
- nicht vergessen, am Schluß in der automagischen Sektion der abge-
leiteten Formulare die Definitionen der geerbten Komponenten zu
entfernen.

Uff. Schweiß-von-der-Stirn-wisch. Nichts, was ich jeden Nachmittag
machen möchte :-)

Danke nochmal & Gruß Matthias.

[Andreas Koch]

Ich würde noch hinzufügen : Die Arbeiten möglichst nicht in Delphi
sondern in einem Texteditor machen ;-)

[Matthias Hanft]

Post by Andreas Koch
Ich würde noch hinzufügen : Die Arbeiten möglichst nicht in Delphi
sondern in einem Texteditor machen ;-)

Stimmt, das wäre auch eine gute Idee - allerdings sieht man dann das
Ergebnis hinterher nur im "Alles-oder-nichts-Modus" :-)

Innerhalb von Delphi konnte ich so wenigstens ein paar Schritt-
für-Schritt-Ergebnisse sehen, das hat schon ein bißchen geholfen.

Gruß Matthias.

[Marian Aldenhövel]

Hi,

Post by Matthias Hanft
Nach etwas Herumexperimentieren sehe ich keine andere Möglichkeit,
als die Formulare nochmal zu bauen

Nach Deiner Beschreibung bin ich nicht mehr sicher, ob die visuelle
Vererbung für Dich richtig ist. Du baust sozusagen Reports, die nehmen
Daten und präsentieren diese irgendwie.

Die Chance ist groß, daß dort wo Du heute zwei verschiedene Formulare
hast, morgen sieben stehen und davon fünf total anders aufgebaut sind.
Dann stehst Du dauernd vor der Entscheidung wo in Deiner visuellen
Vererbung Du die Änderungen machst. Es kann Dir sogar passieren, daß Du
Dinge an der Wurzel änderst und das dann _ungewollt_ auf die Nachkommen
durchschlägt. Du musst dann dauernd alle Versionen prüfen.

Ich würde hier jedes Layout unabhängig von den anderen lassen. Also das
implementieren, was ich in meiner ersten Antwort als ersten Fall aufgeführt
habe: Die gemeinsame Basisklasse ohne visuelle Unterstützung einführen.

Du kannst das auch noch ein wenig variieren und so die Code-Unterschiede
zwischen den verschiedenen Layout-Formularen an einer Stelle konzentrieren
(anstatt sie auf mehrere Set-Handler zu verteilen, im Beispiel war es ja
nur einer, aber jetzt wo wir mehr wissen sehen wir, daß es mehrere werden):

Führe eine Klasse ein, die die Daten des Briefes repräsentiert:

type TReportContent=class(TObject)
private
FAdressZeile1:string;
FBody:TStrings;
public
property AdressZeile1:string read FAdressZeile write FAdresszeile;
..
end;

Um einen Brief zu definieren füllst Du eine Instanz von dieser Klasse
mit den Daten.

Die Basisklasse der Reportformulare bekommt eine einzige Methode um die
Daten zu übernehmen:

type TCustomReportForm=class(TForm)
public
procedure FillReport(aContent:TReportContent); virtual; abstract;
end;

Jeder Report ist ein Nachkomme von TCustomReportForm (nicht visuell, deswegen
reicht es einfach TForm im Sourcecode eines "normal" neu erzeugten Formulars
durch TCustomReportForm zu ersetzen). Und jeder überschreibt FillReport um
die Daten an die richtige Stelle zu schubsen.

var C:TReportContent;
Report:TCustomReportForm;

C:=TReportContent.Create;
try
C.AdressZeile1:=...;
..
if Kunde1 then
Report:=TForm1.Create(NIL)
else if Kunde2 then
Report:=TForm2.Create(NIL)
else Report:=TDefaultReportForm.Create(NIL);
Report.FillReport(C);
Report.ShowModal;
finally
C.Free;
end;

Oder Du verwendest einen fertigen Reportgenerator. Je nachdem was Du da
nimmst kannst Du den Kunden die Mausschubserei dann selber übernehmen
lassen...

Post by Matthias Hanft
Ich habe jetzt eine TForm1(TForm) und eine TForm2(TForm), auf denen
viele Controls millimetergenau positioniert sind.
Daraus möchte ich eine TFormCommon(TForm), eine TForm1(TFormCommon)
und eine TForm2(TFormCommon) machen, und zwar ohne daß ich die müh-
sam plazierten Controls auf TForm1 und TForm2 nochmal genauso mühsam
an die richtigen Stellen schieben muß.
Geht das?

Nicht mit den Mitteln der IDE.

Post by Matthias Hanft
Wie?

Du kannst höchstens TForm1 zur Basis ernennen. Dazu speicherst Du es als
TFormCommon und benennst es um. Dann leitest Du davon visuell ein neues
TForm1 ab. Das passt dann schon. TForm2 schmeißt Du weg und leitest neu
nochmal ein TForm2 von TFormCommon ab, das musst Du dann aber wieder
manuell hinbiegen.

Mit anderen Worten: Du kannst nur eines der Layouts retten. Und zwar indem
Du es zum Default erklärst.

Ciao, MM

[Matthias Hanft]

Hi,

Post by Marian Aldenhövel
Nach Deiner Beschreibung bin ich nicht mehr sicher, ob die visuelle
Vererbung für Dich richtig ist. Du baust sozusagen Reports, die nehmen
Daten und präsentieren diese irgendwie.

Nur im weitesten Sinne. Es gibt für unterschiedliche Firmen unter-
schiedliche Formulare mit PowerPdf-Briefbögen (Logo, Firmenname,
Bankverbindung etc.), aber in allen befülle ich "dynamisch" nur die
beiden Felder "PRTextAnschrift" und "PRTextMain" (beide String-
List), wo die Anschrift und der Rechnungstext reinkommt. Weiter nix.

Insofern stimme ich Dir dazu, daß...

Post by Marian Aldenhövel
Die Chance ist groß, daß dort wo Du heute zwei verschiedene Formulare
hast, morgen sieben stehen und davon fünf total anders aufgebaut sind.

...aber zumindest die beiden dynamisch zu füllenden Felder (Anschrift
und Rechnungstext) wären auch in siebenhundert verschiedenen Formularen/
Briefbögen die gleichen :-)

Post by Marian Aldenhövel
Dann stehst Du dauernd vor der Entscheidung wo in Deiner visuellen
Vererbung Du die Änderungen machst. Es kann Dir sogar passieren, daß Du
Dinge an der Wurzel änderst und das dann _ungewollt_ auf die Nachkommen
durchschlägt. Du musst dann dauernd alle Versionen prüfen.

Das allerdings. Und einen Nachteil habe ich auch schon bemerkt: Was
in der Wurzel da ist, ist dann auch in allen Kindern da, auch wenn
man es dort gar nicht braucht (Notlösung: Visible=False).

Post by Marian Aldenhövel
Ich würde hier jedes Layout unabhängig von den anderen lassen. Also das
implementieren, was ich in meiner ersten Antwort als ersten Fall aufgeführt
habe: Die gemeinsame Basisklasse ohne visuelle Unterstützung einführen.

[...]

Post by Marian Aldenhövel
Jeder Report ist ein Nachkomme von TCustomReportForm (nicht visuell, deswegen
reicht es einfach TForm im Sourcecode eines "normal" neu erzeugten Formulars
durch TCustomReportForm zu ersetzen). Und jeder überschreibt FillReport um
die Daten an die richtige Stelle zu schubsen.

Das wäre natürlich die flexibelste Lösung, aber dann bräuchte _jede_
Form ihre Override-Methode. Sowas müßte ich ohnehin machen, wenn
jede Firma ihren Rechnungstext unterschiedlich dargestellt haben
wollte (z.B. auf unterschiedlich viele Textboxen aufgeteilt), aber
zumindest solange die beiden dynamisch befüllten Textfelder (also
Adresse+Text) auf allen Briefbögen identisch sind, spare ich mir
durch die "visuelle Vererbung" in jedem Formular die (gleiche!)
Implementierung der abstrakten Schubsmethode.

[Geht das Formularvererbenändern?]

Post by Marian Aldenhövel
Nicht mit den Mitteln der IDE.
Du kannst höchstens TForm1 zur Basis ernennen. Dazu speicherst Du es als
TFormCommon und benennst es um. Dann leitest Du davon visuell ein neues
TForm1 ab. Das passt dann schon.

Bis hierhin: ACK (habe ich auch so gemacht), aber...

Post by Marian Aldenhövel
TForm2 schmeißt Du weg und leitest neu
nochmal ein TForm2 von TFormCommon ab, das musst Du dann aber wieder
manuell hinbiegen.

...ohne hinbiegen geht's wie folgt (dank Neun's Anleitung): Im Sourcecode
von TForm2 ändert man class(TForm) in class(TFormCommon) und ändert im
Text-DFM von TForm2 alle "object" in "inherited". Dann stehen die gleich-
gelassenen (nun geerbten) Kompomentan quasi "override-mäßig" unnötiger-
weise nochmal drin, aber das stört nicht. Weitere Änderungen im TForm2
erfolgen dann rein lokal.

Im Moment klappt das ausgezeichnet. Deine Methode zur Trennung von Daten
und Präsentation ist natürlich eleganter und flexibler, würde aber -
zumindest momentan unnötige - etliche Schreibarbeit erfordern. Ich werde
auf jeden Fall spätestens dann dazu übergehen, wenn der erste Kunde seine
Rechnungen im 45-Grad-Winkel, kopfstehend und mit roter Schrift auf grünem
Hintergrund haben will :-)

Gruß Matthias.

[Marian Aldenhövel]

Hi,

Post by Matthias Hanft
...ohne hinbiegen geht's wie folgt (dank Neun's Anleitung): Im Sourcecode
von TForm2 ändert man class(TForm) in class(TFormCommon) und ändert im
Text-DFM von TForm2 alle "object" in "inherited". Dann stehen die gleich-
gelassenen (nun geerbten) Kompomentan quasi "override-mäßig" unnötiger-
weise nochmal drin, aber das stört nicht.

Stimmt. Das ist wahrscheinlich sogar noch eher das, was Du haben willst. Denn
so stehen auch solche Eigenschaften als "overriden", die das eigentlich gar
nicht sind. "Edit1.Left=10" auch dann wenn der Vorgänger da auch eine 10 hat.

So verrutscht auf dem Nachkommen nix, wenn Du Edit1 im Vorgänger verschiebst.
Ohne die Angabe würde es sich mitbewegen.

Ciao, MM

[Hans-Peter Diettrich]

Post by Matthias Hanft
Ich habe jetzt eine TForm1(TForm) und eine TForm2(TForm), auf denen
viele Controls millimetergenau positioniert sind.
Daraus möchte ich eine TFormCommon(TForm), eine TForm1(TFormCommon)
und eine TForm2(TFormCommon) machen, und zwar ohne daß ich die müh-
sam plazierten Controls auf TForm1 und TForm2 nochmal genauso mühsam
an die richtigen Stellen schieben muß.
Geht das? Wie?

Anderer Vorschlag: laß die Forms das passende Interface implementieren.
Oder packe in TCommonForm nur eine neue virtuelle abstrakte Methode, die
das Memo liefert - wenn Du nicht mehr brauchst.

DoDi