Wozu TCaption und TComponentName?

[3_of_8]

Ich hab mir grad mal wieder ein bissel die OH angeschaut und mich was gefragt: Warum ist TLabel.Caption eine TCaption und kein String? Gleiches fragte ich mich auch bei TComponent.Name, das ein TComponentName ist.

Die Deklaration ist ja einfach nur TCaption = type String; bzw. TComponentName = type String;

Wozu ist das gut?

[Bernhard Geyer]

Es könnte ja mal sein das TCaption was anderes als ein String ist. Und dann könnte man (theoretisch) dies ganz einfach ändern können.
Ich denke Du kannst kein C/C++. Dann hättest Du diese Frage nicht gestellt. Dort ist es üblich das jede Bibliothek einen Integer 50 mal neu für irgendwelche eigenen Typen als Basisklasse nimmt.

[3_of_8]

Ich habe mich bisher tatsächlich noch nicht sehr stark mit C und C++ beschäftigt.

Das Argument, dass sich das mal ändern könnte, ist tatsächlich gut. Daran hatte ich nicht gedacht.

[Hawkeye219]

Durch diese Deklaration werden vom Compiler eigene Laufzeit-Typinformationen (RTTI) für TCaption und TComponentName erzeugt. Damit sind die Typen 'String', 'TCaption' und 'TComponenName' z.B. in einem Propertyeditor unterscheidbar.

Gruß Hawkeye

[3_of_8]

Ja, das war mir klar, nur ist es notwendig, dass man das unterscheidet?

[SirThornberry]

bei Captions ist es auf jeden fall Sinnvoll. Man kann sich einen Property-Editor für TCaption bauen der unter anderem berücksichtigt das aus "&" ein "_" wird.
Bei ComponentName kann man sich ebenso einen Propertyeditor bauen der bereits vorhandene Komponentennamen berücksichtigt etc.

[3_of_8]

Stimmt - das ist allerdings sinnvoll. Wenn man statt TCaption = type String; schreiben würde TCaption = String; würde das nicht mehr gehen, oder?

[Dax]

TCaption = string erzeugt nur einen Alias. TCaption = type string erzeugt einen Typen.

[3_of_8]

Aha. Dacht ichs mir doch.