Wozu haben Komponenten Namen?

[Der schöne Günther]

So wie es aussieht, kann man problemlos

Delphi-Quellcode:

TComponent

-Instanzen erzeugen und verwenden, ohne ihnen über ihre

Delphi-Quellcode:

Name

-Property jemals etwas zugewiesen zu haben. Gibt man ihnen allerdings einen, muss er für ihren

Delphi-Quellcode:

Owner

eindeutig sein. Hat sie keinen, ist das auch egal.

Sehe ich das bis hierhin richtig?

Wenn ja, welchen Sinn hat der Name überhaupt? Ist das nur für die Delphi-Innereien (wenn er sich aus der DFM ein Formular zusammenbastelt) interessant?

[DeddyH]

Über den Namen kannst Du eine Komponente gezielt und ohne viel Gedöns direkt ansprechen.

Delphi-Quellcode:

lblName.Caption := 'Hanswurst';

ist nunmal deutlich komfortabler als

Delphi-Quellcode:

(Components[21] as TLabel).Caption := 'Hanswurst';

Zumal sich die Position im Components-Array ja auch noch verschieben kann, da wird es dann ganz eklig. Der Name ist eben eindeutig, da muss man sich um solche Dinge keinen Kopf machen.

[Perlsau]

Namen dienen grundsätzlich der Identifizierbarkeit.

Vor allem aber machen Komponentenbezeichner einen Quellcode lesbarer und verständlicher, insbesondere wenn es sich um Fremdcode handelt. Natürlich brauchst du keine Namen, wenn du eine Komponente zusammen mit anderen Komponenten zu einem Objekt verbindest, das du in einer Objektliste Record verbindest und alles in einem Array verwaltest, wie ich das z.B. in einer SoftCash-Anwendung mache:

Delphi-Quellcode:

Type
  PArtikel = ^TArtikel;
  TArtikel = Record
               A_Index   : Integer;  // Artikelindex in DB 
               A_Num     : String;   // Artikelnummer
               A_Name    : String;   // Artikelname
               A_Einkauf : Currency; // Einkaufspreis
               A_Verkauf : Currency; // Verkaufspreis
               A_Icon    : TImage;   // Artikelbild klein
               A_Anzeige : Boolean;  // Artikel wird als Shortcut angezeigt
               A_X       : Integer;  // X-Position der linken oberen Ecke
               A_Y       : Integer;  // Y-Position der linken oberen Ecke
             End;

Zum Auffinden bzw. Identifizieren des gesuchten Objekts benötige ich kein Namensproperty in der TImage-Komponente, das läuft über Artikelnummer oder Artikelindex, je nachdem. Das sieht dann z.B. so aus:

[DeddyH]

Ohne Namen dürfte es auch zur Designtime zumindest schwierig werden, einer Komponente eine andere per OI zuzuweisen (z.B. die FocusControl-Property von TLabel oder die Dataset/Datasource-Beziehungen).

[Der schöne Günther]

Zitat:

Zitat von DeddyH (Beitrag 1233401)

Über den Namen kannst Du eine Komponente gezielt und ohne viel Gedöns direkt ansprechen.

Delphi-Quellcode:

lblName.Caption := 'Hanswurst';

Ich verstehe nicht. Wenn ich bsp. nun einen Button erzeuge

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
   newButton := TButton.Create(self);
   newButton.Name := 'Testbutton';
   newButton.Parent := self;
end;

Dann ermöglicht mir das doch später nicht zu sagen

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin
   testButton.Click();
end;

Die Referenz "Button1" die automatisch von der IDE zu meiner Klasse TForm1 hinzugefügt wird, hat doch (zumindest nach der Erstellung des Formulars) nichts mit dem tatsächlichen Namen der Komponente zu tun?

Natürlich möchte man zur Designzeit den Komponenten schöne Namen geben können und damit auch steuern, wie die Referenzen genannt werden. Aber wozu brauche ich das zur Laufzeit noch?

[Perlsau]

Sorry, aber ich verstehe deine Frage nicht. Was soll das sein: der "tatsächliche Name" einer Komponente? Sowas wie "die Essenz der Dinge"? Wenn dir das mit den Bezeichnern nicht gefällt, solltest du auf Assembler umsatteln, aber auch da gibt es Bezeichner, jedoch längst nicht so komfortabel wie in einer Visual-Design-Umgebung.

Zur Laufzeit brauchst du nichts davon, denn zur Laufzeit ist bereits alles verwurstelt, was man in Fachkreise auch als compiliert bezeichnet. Die Namensgebung dient der komfortableren Entwicklung. Daher solltest du auch nicht bei Button1 bleiben, sondern in der Tat "schönere" oder auch häßlichere, vor allem aber aussagekräftige Komponenten- und Variablenbezeichner wählen.

[stahli]

Über die Komponentennamen kann der Compiler erkennen, welche Formularcontrols Du im Quelltext oder Objektinspektor adressieren willst.

Auch nach dem Laden einer Anwendungen können die Bezüge wieder hergestellt werden (die eigentlichen Objekte liegen dann an einem anderen Speicherplatz und die Zuordnungen müssen neu aufgelöst werden).

Nachtrag: Die Komponentennamen ermöglichen die Beziehungen zwischen Quelltext und Formular. Zur Laufzeit sind sie nicht mehr erforderlich, ermöglichen aber weiterhin das Finden von Controls anhand deren Namen.

[Meflin]

Zitat:

Zitat von Perlsau (Beitrag 1233414)

Zur Laufzeit brauchst du nichts davon, denn zur Laufzeit ist bereits alles verwurstelt, was man in Fachkreise auch als compiliert bezeichnet. Die Namensgebung dient der komfortableren Entwicklung.

Schonmal von Metaprogramming und Reflection gehört?

Zur Frage: Es geht Günther doch offensichtlich einzig um die Property namens "Name" die alle Komponenten haben, die aber keinen offensichtlichen Sinn erfüllt. So ähnlich wie die "Tag"-Property. Es geht nicht um die Namen der Variablen, in denen Referenzen auf Instanzen dieser Komponenten gespeichert werden.

Ich kann da keine endgültige Antwort geben, aber ich vermute, dass es tatsächlich dazu dient, Komponenten zur Laufzeit identifizieren zu können.

[Daniel]

Die Frage ist, welchen Nutzen der Name einer Komponente zur Laufzeit hat.

Der Nutzen besteht genau dann, wenn man eine Komponente über ihren Namen auffinden möchte. Siehe hierzu auch "FindComponent()". Wenn man all das nicht tut, dann hält sich der Nutzen eines Komponenten-Name zur Laufzeit in Grenzen.

[Union]

Ich glaube hier findet ständig eine Verwechselung statt zwischen den Komponenten-Namen und den Variablen-Namen. Der Komponenten-Name dient ausschließlich der Zuordnung von gestreamten Resourcen zu den korrekten Variablen beim Laden der Formulare.

Im dfm wird dann vom Reader erkannt, dass:

Delphi-Quellcode:

  object Label1: TLabel

hiermit verknüpft werden soll:

Delphi-Quellcode:

TForm1 = class(TForm)
  Label1: TLabel;

[Popov]

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    //...
  private
    { Private-Deklarationen }
    procedure NewButonOnClick(Sender: TObject);
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.NewButonOnClick(Sender: TObject);
begin
  ShowMessage('Schön langsam mit Gefühl und über neuen Namen');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  newButton: TButton;
begin
  newButton := TButton.Create(self);
  newButton.Name := 'Testbutton';
  newButton.Parent := self;
  newButton.OnClick := NewButonOnClick;
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  newButton: TButton;
begin
  newButton := TButton(FindComponent('Testbutton'));
  newButton.OnClick(nil);
end;

[Perlsau]

Zitat:

Zitat von Meflin (Beitrag 1233419)

Zitat:

Zitat von Perlsau (Beitrag 1233414)

Zur Laufzeit brauchst du nichts davon, denn zur Laufzeit ist bereits alles verwurstelt, was man in Fachkreise auch als compiliert bezeichnet. Die Namensgebung dient der komfortableren Entwicklung.

Schonmal von Metaprogramming und Reflection gehört?

Nein. Muß man das als einfacher Delphi-Entwickler kennen?

Zitat:

Zitat von Meflin (Beitrag 1233419)

Zur Frage: Es geht Günther doch offensichtlich einzig um die Property namens "Name" die alle Komponenten haben, die aber keinen offensichtlichen Sinn erfüllt. So ähnlich wie die "Tag"-Property. Es geht nicht um die Namen der Variablen, in denen Referenzen auf Instanzen dieser Komponenten gespeichert werden. Ich kann da keine endgültige Antwort geben, aber ich vermute, dass es tatsächlich dazu dient, Komponenten zur Laufzeit identifizieren zu können.

Aha, er möchte also wissen, wozu das Property Name auch zur Laufzeit noch verfügbar ist. Wieso sollte es das nicht sein? Die Frage lautete zwar anders, nämlich "wozu haben Komponenten Namen", aber wenn du nun irgendwie erfahren hast, daß er genau das meint, dann würde ich mal sagen: weil die Entwickler bei Borland, Codegear und Emba das so geschrieben haben, nicht wahr? Warum hat ein Graf noch seinen Titel, wenn es doch offiziell keine derartigen Titel mehr gibt? Tja, da ist guter Rat teuer ...

Mir ist noch immer nicht klar, worauf die Frage eigentlich abzielt, sollte es sich nicht einfach um eine nach Gutdünken konstruierte Fragestellung handeln. Vielleicht auf die Abschaffung dieses Properties?

[Daniel]

Frank, es ist wieder eine wahre Freude, von Dir lesen zu dürfen. Und dass Du die Frage nicht erkannt hast, wurde offensichtlich. Das ist nicht schlimm - geht mir selbst auch oft genug so. In diesem Fall rate ich jedoch zur Zurückhaltung - manchmal kann man einfach die anderen erstmal machen lassen.

[Uwe Raabe]

Zitat:

Zitat von Union (Beitrag 1233421)

Ich glaube hier findet ständig eine Verwechselung statt zwischen den Komponenten-Namen und den Variablen-Namen. Der Komponenten-Name dient ausschließlich der Zuordnung von gestreamten Resourcen zu den korrekten Variablen beim Laden der Formulare.

Im dfm wird dann vom Reader erkannt, dass:

Delphi-Quellcode:

  object Label1: TLabel

hiermit verknüpft werden soll:

Delphi-Quellcode:

TForm1 = class(TForm)
  Label1: TLabel;

Das hat eigentlich gar nichts mit dem Streaming zu tun. Wenn du eine Klasse von TComponent ableitest und darin ein Feld mit einem ebenfalls von TComponent abgeleiteten Typ mit der passenden Sichtbarkeit (published) deklarierst, dann wird dieses Feld bei einem Aufruf von InsertComponent mit einer Instanz als Parameter, deren Name dem Feldnamen entspricht, genau auf diese Instanz gesetzt. Deshalb dürfen die Komponentennamen der Child-Komponenten auch nur eindeutig innerhalb der Parent-Komponente oder leer sein (weil ein Leerstring ja kein Variablenname ein kann).

Insofern würde das obige Beispiel:

Delphi-Quellcode:

   newButton := TButton.Create(self);
   newButton.Name := 'Testbutton';
   newButton.Parent := self;

...


   testButton.Click();

durchaus funktionieren, wenn testButton entsprechend als Feld im Form deklariert ist.

[Stevie]

Um es noch etwas zu verdeutlichen:
Wenn du eine Komponente zur Designzeit plazierst, generiert die IDE dafür eine Feldvariable im published Teil deines Forms (Frames, Datamodules, ...).
Diese wird so genannt, wie du im ObjektInspektor in der Eigenschaft Name einstellst. Somit kannst du deiner Komponente einen vernünftigen Namen verpassen (die IDE sorgt dafür, dass die Feldvariable auch passend umbenannt wird), um dich nicht hinterher im Sourcecode zu fragen, wofür nochmal Button24 oder TListbox17 waren.

Fun fact:
Wenn du niemals auf deinen Button im Sourcecode zugreifst, kannst du sogar die Feldvariable entfernen (nicht empfohlen) und dein Programm funktioniert noch - mit der kleinen Einschränkung, dass diese Klasse mit RegisterClass registriert werden muss, da sonst der dfm Streaming Mechanismus fehlschlagen würde, weil in diesem Fall aus dem Klassennamen, die in der dfm steht, eine Instanz der entsprechenden Klasse erzeugen muss.

[Popov]

Ich glaube er meint das:

Delphi-Quellcode:

var
  newButton: TButton;
begin
  newButton := TButton.Create(self);
  newButton.Left := 0;
  newButton.Caption := '1';
  newButton.Parent := self;
  newButton.OnClick := NewButonOnClick;

  newButton := TButton.Create(self);
  newButton.Left := 100;
  newButton.Caption := '2';
  newButton.Parent := self;
  newButton.OnClick := NewButonOnClick;
end;

Das scheint zu gehen, ist mir bisher noch nicht aufgefallen, denn zur Entwicklungszeit meckert die IDE, bei zwei Komponenten ohne Namen. Und wenn man im Beispiel oben die Buttons einzig mit einer Prozedur (z. B. OnClick) direkt verknüpft, brauch man anscheinend auch keine Namen.

Problematisch wird es nur wenn man später - wie im ersten Beispiel - auf die Komponente zugreifen will. Will man es nicht, scheint es kein Problem zu sein.

[DeddyH]

Zur Laufzeit erstellte Komponenten werden ja auch nicht in der *.dfm hinterlegt, das ist ein entscheidender Unterschied.

[Der schöne Günther]

Fast artete es in eine echte Wildwest-Kneipenschlägerei aus, aber jetzt ist doch gut erklärt. Die Parallele zur

Delphi-Quellcode:

Tag

-Property fand ich sehr passend ;-)

Meine Intention war nur zu sehen, ob ich irgendeinen tollen Mehrwert verpasse, wenn ich einer zur Laufzeit erstellten Komponente (ohne andere Komponente als Owner) keinen Namen gebe oder ich mir gar Sorgen machen muss, dass mir irgendwann alles um die Ohren fliegt.

[DeddyH]

Das hättest Du vielleicht dazu schreiben sollen, dann hätte ein einfaches "Nein" als Antwort genügt :lol:

[Der schöne Günther]

"Instanzen ... erzeugen" hatte für mich schon so einen beschwingenden, schöpferischen und aktiven Klang, da dachte ich es sei klar, dass es um die Laufzeit geht :oops:

Das nächste mal versuche ich besser drauf zu achten.

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1233430)

Fun fact:
Wenn du niemals auf deinen Button im Sourcecode zugreifst, kannst du sogar die Feldvariable entfernen (nicht empfohlen) und dein Programm funktioniert noch - mit der kleinen Einschränkung, dass diese Klasse mit RegisterClass registriert werden muss, da sonst der dfm Streaming Mechanismus fehlschlagen würde, weil in diesem Fall aus dem Klassennamen, die in der dfm steht, eine Instanz der entsprechenden Klasse erzeugen muss.

Fun Fact 2:
Der Typ der Feldvariablen muss nicht mal der Klasse in der dfm entsprechen, solange beide von TComponent abgeleitet sind.

Delphi-Quellcode:

program FunFact2;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  System.Classes;

type
  TChild1 = class(TComponent)
  private
    FValue: Integer;
  public
    property Value: Integer read FValue write FValue;
  end;

  TChild2 = class(TComponent)
  private
    FValue: Boolean;
  public
    property Value: Boolean read FValue write FValue;
  end;

  TParent = class(TComponent)
  published
    Child: TChild1;
  end;

procedure Main;
var
  parent: TParent;
  child: TChild2;
begin
  parent := TParent.Create(nil);
  try
    child := TChild2.Create(nil);
    child.Name := 'Child';
    child.Value := true;
    parent.InsertComponent(child);
    Writeln(Parent.Child.Value);
    child.Value := false;
    Writeln(Parent.Child.Value);
  finally
    parent.Free;
  end;
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

[jaenicke]

Delphi selbst benötigt den Namen nicht. Viele nutzen ihn aber z.B. um die Komponente über den Namen als String zu finden, mit FindComponent.

[uligerhardt]

Zitat:

Zitat von jaenicke (Beitrag 1233452)

Delphi selbst benötigt den Namen nicht. Viele nutzen ihn aber z.B. um die Komponente über den Namen als String zu finden, mit FindComponent.

Oder einfach, um beim Debuggen zu wissen, mit welcher Komponente man es gerade zu tun hat.