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.

[Hansa]

Bei mir sieht die Form Hierarchie z.B. so aus: TForm ->

1. Ableitung :

Damit alle Forms ISO-konform sind wird hier direkt eingebaut, dass ESC jede Form schliesst. Und die Koordinatn sollen im FormClose gespeichert und im FormCreate gelesen werden. Das ist die 1. Ableitung von TForm.

nächste Ableitungen : hier setzt die erste Verzweigung ein. Je nachdem, ob das ein reines Ausgabe-Form ist oder auch Eingaben gemacht werden können, werden nach und nach weitere Eigenschaften eingebaut. Z.b. Edit für Ku.Nr.

Mit der Einführng des Ku.Nr.-Edits im Programm-Kontext wird natürlich direkt gleich schon die Logik für das Auffinden eines Kunden eingebaut. D.h. die Taste, die die Suchfunktion aufruft, einen Suchbutton für die Maus-Bevorzuger, das Lesen der entspr. Datensätze aus der DB in den geeigneten Events etc.

Nun brauche ich z.B. eine Kunden-Statistik, eine Kundenrechnung, eine Kunden-Rechnungsliste usw. Für alle diese Fälle habe ich dann eben diverse Formulare, die einen gemeinsamen Vorfahr haben. Und sogar dieser Vorfahr weiss ja bereits von seinem entfernten Vorfahr, wie und wann er seine Koordinaten abzuspeichern hat. Es wäre Wahnsinn, all das bei jeder Form extra zu machen.

Positiver Nebeneffekt : wenn ich einen Tipfehler mache, dann ist der sehr schnell aufzufinden, weil eben je nachdem wo der sich bemerkbar macht, ziemlich schnell klar ist, wo der sein muss. Oder bei Änderungen : sagen wir mal, irgendwem gefällt die Formfarbe nicht und er will schwarz auf Lila. Jetzt hiesse es : alle Forms von Hand einzeln ändern, bei mir würde es reichen, die allererste Form dementsprechend zu ändern.

Das Letzte ist auch der entscheidende Unterschied : TForm ist TForm und Basta. Das unterliegt normalerweise nicht meinem Einfluss. Eine einzige dazwischengeschaltete Form-Ableitung (selbst wenn sie nichts macht) hebelt das komplett aus und gibt einem die volle Kontrolle (siehe Bsp. Form-Farbe). Shmia soll mal bitte irgendein Szenario nennen, wo die Form-Vererbung sich negativ bemerkbar macht.

Zumal es ja auch noch inherited; +Co. gibt. Will ich irgendetwas vom Vorfahr nicht in abgeleiteter Form haben, dann lasse ich das eben weg.