AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Problem mit Komponentennamen bei abgeleiteten Formularen
Thema durchsuchen
Ansicht
Themen-Optionen

Problem mit Komponentennamen bei abgeleiteten Formularen

Ein Thema von fkf · begonnen am 5. Apr 2012 · letzter Beitrag vom 9. Apr 2012
Antwort Antwort
Seite 1 von 3  1 23      
fkf

Registriert seit: 23. Jan 2008
Ort: Dietmannsried
14 Beiträge
 
Turbo Delphi für Win32
 
#1

Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 15:24
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.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#2

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 17:06
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.993 Beiträge
 
Delphi 12 Athens
 
#3

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 17:22
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. )
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
shmia

Registriert seit: 2. Mär 2004
5.508 Beiträge
 
Delphi 5 Professional
 
#4

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 17:27
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
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.993 Beiträge
 
Delphi 12 Athens
 
#5

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 17:33
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)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu ( 5. Apr 2012 um 17:36 Uhr)
  Mit Zitat antworten Zitat
shmia

Registriert seit: 2. Mär 2004
5.508 Beiträge
 
Delphi 5 Professional
 
#6

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 18:46
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.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.993 Beiträge
 
Delphi 12 Athens
 
#7

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 22:01
Und dann kannst du damit keinen FormDesigner nutzen.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Benutzerbild von Bummi
Bummi

Registriert seit: 15. Jun 2010
Ort: Augsburg Bayern Süddeutschland
3.470 Beiträge
 
Delphi XE3 Enterprise
 
#8

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 5. Apr 2012, 23:32
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).
Thomas Wassermann H₂♂
Das Problem steckt meistens zwischen den Ohren
DRY DRY KISS
H₂ (wenn bei meinen Snipplets nichts anderes angegeben ist Lizenz: WTFPL)
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#9

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 6. Apr 2012, 04:13
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.
Gruß
Hansa

Geändert von TBx ( 7. Apr 2012 um 10:18 Uhr) Grund: Zitat formatiert
  Mit Zitat antworten Zitat
Alt 6. Apr 2012, 09:13     Erstellt von himitsu
Dieser Beitrag wurde von TBx gelöscht. - Grund: OT
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#10

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 6. Apr 2012, 21:16
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.
Gruß
Hansa
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:54 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz