Wozu haben Komponenten Namen?

**Der schöne Günther**

Über den Namen kannst Du eine Komponente gezielt und ohne viel Gedöns direkt ansprechen.
lblName.Caption := 'Hanswurst';

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

markieren

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

markieren

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?

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.

**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:
object Label1: TLabel hiermit verknüpft werden soll:

markieren

Delphi-Quellcode:

			TForm1 = class(TForm)

  Label1: TLabel;

**Uwe Raabe**

Zitat von 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:
object Label1: TLabel hiermit verknüpft werden soll:

markieren

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:

markieren

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.

**Uwe Raabe**

Zitat von Stevie:

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.

zusammenfalten · markieren

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.

**Meflin**

Zitat von Perlsau:

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.

Zitat von Meflin:

Zitat von Perlsau:

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 von Meflin:

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.