Problem mit Komponentennamen bei abgeleiteten Formularen

[fkf]

Hallo,

wenn man selbst erstellte (Standard)formulare über die Objektablage vererbt, erhält man auch die Komponenten und deren Namen im neuen Formular.
Wie handhabt man dann die Komponentenbezeichnungen?
Das Ganze mal als Beispiel mit Edits.
Ich sehe momentan nur die Möglichkeit im Vorfahrformular die Edits mit allgemeinen Namen zu versehen, wie Edit1, Edit2, Edit3,... usw. Dadurch wird der Sourcecode nicht gerade übersichtlich.
Sobald "sprechende" Namen vergeben werden habe ich quasi eine kleine Dokumentation im Vorfahrformular (edKDNR, edKDName, edKDOrt,...).
Wenn mein Nachfahrformular dann eine Artikelstammdatenverwaltung ist heißt mein Edit für die Artikelnummer nicht edARTNr sondern auch edKDNR!
Muss ich mit einer der beiden Methoden leben oder kann man die Namen im Nachfahrformular ändern?

F.F.

[Sir Rufo]

Dann klatsch auf den Vorfahr nur das drauf, was auch wirklich in den Nachfahren benutzt wird.

Unterscheiden sich die Edit-Felder in der Benennung, dann unterscheiden diese sich zumeist auch in den anderen Eigenschaften, wie Breite, Maximale Stellenanzahl, erlaubte Zeichen etc.

[himitsu]

Man kann sich auch eigene Variablen erstellen.

Delphi-Quellcode:

private
  edKDNR: TEdit;

und dann im OnCreate edKDNR := edARTNr; Oder

Delphi-Quellcode:

published
  edKDNR: TEdit;

und im OnCreate edARTNr.Name := 'edKDNR'; .
Man wird vielleicht erschrecken, aber Delphi hat da einen Automatismuß, welcher auf published-Felder losgeht.



Danach kann man dann ganz einfach edKDNR.Text verwenden.




Sobald ein Feld im Owner einer TComponent genauso heißt, wie die Komponente (um)benannt wird, dann wird dieses Feld (egal welchen Types - Delphi prüft da leider nicht) gesetzt.

Die Variable mit dem alten Komponentennamen wird auf nil gesetzt und in die andere Variable kommt die Instanz dieser Komponente.
( Auf diese Weise befüllt die VCL auch die Variablen/Felder mit den Komponenten, welcher über eine DFM erstellt werden. )

[shmia]

Also das Vererben von Formularen wird allgemein überschätzt.
In der Praxis sind die Formulare so unterschiedlich und so speziell an ihre Aufgabe angepasst,
dass es kaum etwas zu vererben gibt.

Wenn du also ein Basis-Formular hast und dann auf dem abgeleiteten Formular feststellst, dass dir die Namen der Controls nicht so richtig in Konzept passen, dann stimmt das Konzept der Vererbung eben nicht.

Neben Formularen gibt es ja auch noch Frames.
Ein Frame ist nur ein Teilstück eines Formulars.
Es macht wesentlich mehr Sinn Teile eines Formulars in mehreren Formularen wiederverwenden zu können.

Zusammengefasst
Vererben von Formularen -> schlechte Technik für die Praxis, don't use it
Frames -> korrekt angewandt zu empfehlen

[himitsu]

Wir haben so im Programm ein paar vererbte Formulare.
Da sind aber fast nie irgendwelche Eingabekomponenten drinnen, sondern nur Grundfunktionen dieser Formulare,
wie z.B. das Speichern der Fensterposition oder die Darstellung/das Aussehn und bei Einem ist eine Menüleiste drin, welche in allen Nachfahren enthalten ist.

Ansonsten sind nahezu alle Formulare und Komponenten (Edits und Co.) erstml grundsätzlich vererbt, falls man mal was Grundsätzliches an allen Formularen ändern will/muß und dafür wäre dann nur eine einzige Änderung an einer Stelle nötig.
(bei über 100 Formularen, welche sich hier und da verstecken, ist das schon eine Erleichterung ... abgesehn von doppeltem/mehrfachem Code, wenn man das überall einzeln verbauen würde)

[shmia]

Zitat von himitsu:

Ansonsten sind nahezu alle Formulare und Komponenten (Edits und Co.) erstml grundsätzlich vererbt, falls man mal was Grundsätzliches an allen Formularen ändern will/muß

Kann man machen; ich würd's aber nicht tun.
Um das Look & Feel zu beeinflussen gibt es auch die Möglichkeit eine zentrale Komponenten-Factory zu verwenden:

Delphi-Quellcode:

TComponentFactory = class(TObject)
public
  class function CreateComponent(AClass:TFormClass; Owner:TComponent):TComponent;virtual;
  class function CreateForm(AClass:TFormClass; Owner:TComponent):TCustomForm;virtual;
  class function CreateMdiForm(AClass:TFormClass; Owner:TComponent):TCustomForm;virtual;
  class function CreateModalForm(AClass:TFormClass; Owner:TComponent):TCustomForm;virtual;
  class function CreateGlobalForm(AClass:TFormClass):TCustomForm;virtual;  // Owner ist Application
end;

Man spart sich so den Ballast der abgeleiteten Formulare und kann flexibler reagieren.

[himitsu]

Und dann kannst du damit keinen FormDesigner nutzen.

[Bummi]

Ich bin ein glühender Verfechter von Templates, auch wenn diese zu Projektbeginn noch manchmal recht mager ausgestattet sind. Im Laufe der Projekts kommt alles was für alle Nachfahren zu gebrauchen ist alles dort hinein, Imagelisten, allgemein gehaltene Popupmenus, die erwähnten Speicher- und Wiederherstellungsfunktionen für Form und Komponenten etc.
Edit und ähnliches tauchen erst in später als hiervon abgeleitete speziellere Templates auf, dann zum Beispiel wenn Angebote, Auftragsbestätigungen, Lieferscheine und Rechnungen so ähnlich sind dass alles gemeinsame auf diesem Template abgefackelt werden kann.
Angenehm wird ein solches vorgehen wenn im Nachhinein Änderungen im Verhalten oder Layout gewünscht sind, und sei es dass über ein for i := ... Componentcount Aussehen oder Verhalten umgestellt werden. (Eine nachträglich gewünschte Mehrsprachigkeit zur Laufzeit über eine Datenbank umschaltbar wird dann zu einen 2 Stunden Aufwand).

[Hansa]

Zitat von Shmia:

"In der Praxis sind die Formulare so unterschiedlich und so speziell an ihre Aufgabe angepasst, dass es kaum etwas zu vererben gibt. Vererben von Formularen -> schlechte Technik für die Praxis, don't use it"

Die Formulare können NIEMALS so unterschiedlich sein, dass sich nicht lohnt, diese zu vererben. Wer solche Formulare hat, die immer anders auf Tastendruck reagieren, immer anders aussehen usw., der macht echt was verkehrt.

P.S.: zu "schlechter Technik" sage ich nur : absoluter Blödsinn.