Fragen zu OOP und Klassen: published, protected, ...

[Gonzo2]

Weiter in Verständnisfragen zu Klassen: private, public, published und protected

Siehe auch vorherige Verständnisfragen: Fragen zu inherited

Kommen wir zu private, public, published und protected. Einige der Attribute sind in Bedeutung bekannt, vor allem private und public, da sie unter anderem aus der Arbeit mit Formularen bekannt sind. Sie steuern ob Elemente nur innerhalb der aktuellen oder auch in anderen Units bekannt sind. Neu beim Erstellen von eigenen Klassen sind published und protected Attribute. Außerdem ist mir nicht ganz klar welche Vorteile es mir bringt etwas in public zu packen wenn es auch ohne ein Attribut funktioniert. Aber gehen wir die Punkte einzeln durch.

private: hier sind Felder und Methoden innerhalb der eigenen Unit sichtbar. private schützt also nicht in der eigenen Unit vor Zugriffen. Aus klassenfremden Prozeduren und Funktionen kann in der eigenen Unit auch auf Inhalte von private zugegriffen werden. Anders sieht es bei einer fremden Unit aus. Hier sind die Inhalte von private unsichtbar. Beim Zugriff gibt es eine Fehlermeldung.

public: hier sind Felder und Methoden innerhalb der eigenen und fremden Unit sichtbar. Bei public kann man innerhalb der eigenen Klasse, fremden Klasse, eigenen Unit und fremden Unit zugegriffen werden.

Bei published können anscheinend keine Felder deklariert werden. Es gibt eine Fehlermeldung. Bei protected kann man Felder deklarieren. Bei published kann man eine property (Eigenschaft) definieren die in eigener und fremden Unit abrufbar ist. Eine property kann man aber auch unter private, public, published und protected definieren. Bei protected ist eine property in einer fremden Unit nicht sichtbar. Verwende ich kein Sichtbarkeitsattribute am Anfang einer Klassendeklaration, ist mein Element in der eigenen und fremden Unit abrufbar.

Etwas Kopfzerbrechen bereitete mir eine kurze Zeit dieser Satz aus der Hilfe:

Zitat:

Ein Element ohne Attribut erhält automatisch die Sichtbarkeit des vorhergehenden Elementes in der Deklaration

Bis ich rausgefunden habe, daß private, public, published und protected keine Bereiche sind, sondern vor jedes Feld, Prozedur, Funktion, Property usw. vorangestellt werden können. Man kann sich das aber sparen und es nur vor das erste Element stellen. Alle folgende Elemente erhalten dann das Attribut des vorhergehenden Elements. Aber da muß man erst drauf kommen. Vor allem weil private, public, published und protected in automatisch erstellten Units so angeordnet sind als ob sie Bereiche bilden würden. Diese Information ist definitiv zuviel des Guten. Sie verwirrt mehr als sie informiert.

Soviel habe ich schon zu den Sichtbarkeitsattributen selbst rausgefunden. Das einzige was mehr oder weniger klar ist, sind private und public. Irgendwo habe ich gelesen, daß Elemente am Anfang einer Klassendeklaration ohne Sichtbarkeitsattribute published bzw. public deklariert werden. Dann frage ich mich aber wann was genommen wird. Wäre es public, könnte ich es verstehen, aber published bzw. public sind zwei Möglichkeit. Wenn ich also ein Element an den Anfang stelle, was ist es dann? published oder public? Wann ist es was? Und wozu etwas dann in public stellen wenn es auch ohne geht. Nur wegen der Übersicht?

Dann sind mir noch published und protected nicht ganz klar, bis auf die Punkte die ich oben erwähnt habe. In Büchern und Tutorials steht, daß publisched Methoden Laufzeitinformationen für den Objektinspektor erhalten. Das verstehe ich jetzt nicht genau. Erstens benutze ich bei Klassen doch keinen Objektinspektor, nur bei Komponenten, und zweitens welche Informationen sind das und wozu dienen sie? Bei protected steht, daß es wie private ist, nur daß der Zugriff auf Methoden hinter protected nur aus der eigenen Klasse oder über Methoden der Nachfolger erfolgen kann, die nicht unbedingt aus der eigenen Unit erfolgen müssen. Wie ist das zu verstehen?

[Tyrael Y.]

Zitat:

Zitat von Gonzo2

Etwas Kopfzerbrechen bereitete mir eine kurze Zeit dieser Satz aus der Hilfe:

Zitat:

Ein Element ohne Attribut erhält automatisch die Sichtbarkeit des vorhergehenden Elementes in der Deklaration

Ok ein Beispiel dazu:

Delphi-Quellcode:

 TMyObject = class(TObject)
   private
     FFeld: EinTyp;
   public
    property FNurHierDeklariertAberInAllenNachfahrenTrotzdemVorhanden: EinTyp read FFeld write FFEld; 
   
  end;
  
  TMyAnderesObj = class(TMyObject)
   private
    FEinFeld: NochEinType;
  end;

Auch wenn in der zweiten Klasse die public property nicht explizit definiert ist, kannst du über ein Objekt der zweiten Klasse auf diese property zugreifen, da sie diese property vom Vorfahren erbt.

[Gonzo2]

Zitat:

Zitat von Tyrael Y.

Zitat:

Zitat von Gonzo2

Etwas Kopfzerbrechen bereitete mir eine kurze Zeit dieser Satz aus der Hilfe:

Zitat:

Ein Element ohne Attribut erhält automatisch die Sichtbarkeit des vorhergehenden Elementes in der Deklaration

Ok ein Beispiel dazu:

Siehst Du, der Satz verwirrt, auch dich. Ich brauchte auch paar Minuten um zu merken was hier gemeint ist. Es hat nichts mit erben zu tun. Gemeint ist das hier

Delphi-Quellcode:

  TMeineKlasse = class
  private FFeld1: String;
  private FFeld2: String;
  private FFeld3: String;
  private FFeld4: String;
  end;

Das geht auch so

Delphi-Quellcode:

  TMeineKlasse = class
  private FFeld1: String;
          FFeld2: String;
          FFeld3: String;
          FFeld4: String;
  end;

Ein Element ohne Attribut erhält automatisch die Sichtbarkeit des vorhergehenden Elementes in der Deklaration. Das ist üblicher

Delphi-Quellcode:

  TMeineKlasse = class
  private
    FFeld1: String;
    FFeld2: String;
    FFeld3: String;
    FFeld4: String;
  end;

Es geht bei dem Satz oben nur um die Sichtbarkeitsattribute. Muß man erst drauf kommen. Ist glaube ich aus der Delphihilfe.

[Phoenix]

Zitat:

Zitat von Gonzo2

Dann sind mir noch published und protected nicht ganz klar, bis auf die Punkte die ich oben erwähnt habe.

1.) Private
Nur sichtbar in der eigenen Klasse (und, aber das finde ich persönlich unschön, in anderen Klassen in der gleichen unit).
Eine abgeleitete Klasse kann auf ein private - Element nicht zugreifen.

2.) Protected
Sichtbar in der eigenen Klasse und in davon abgeleiteten Klassen. Eine Klasse kann also auf ein protected Element der Eltern zugreifen.

3.) Public
Klar: Das ist öffentlich, da können auch fremde Klassen drauf zugreifen.

4.) Published
Published = public, und für den Objektinspektor veröffentlicht.
Eigentlich nur dann Sinnig, wenn diese Klasse irgendwie im Objektinspektor verwendet werden soll. Published - Eigenschaften kann man eben dann im Objektinspektor verändern, 'nur' public Eigenschaften nicht.

[Gonzo2]

Interessante Ausführung

Zitat:

Zitat von Phoenix

1.) Private
Nur sichtbar in der eigenen Klasse (und, aber das finde ich persönlich unschön, in anderen Klassen in der gleichen unit).
Eine abgeleitete Klasse kann auf ein private - Element nicht zugreifen.

2.) Protected
Sichtbar in der eigenen Klasse und in davon abgeleiteten Klassen. Eine Klasse kann also auf ein protected Element der Eltern zugreifen.

Kann ich das jetzt so zusammenfassen, daß der Unterschied zwischen private und protected der ist, daß alles aus private nicht geerbt werden kann und erst mit protected, soweit es sich um nicht öffentliche Elemente handelt, das System der Vererbung greift? Aus private wird nichts geerbt, aus protected wird geerbt? Somit kann ich steuern was mein Nachfahre erben kann und was nicht?

Zitat:

3.) Public
Klar: Das ist öffentlich, da können auch fremde Klassen drauf zugreifen.

Das ist soweit klar. Da hier die Elemente sowieso sichtbar sind, kann hier nichts oder kaum gesteuert werden.

Zitat:

4.) Published
Published = public, und für den Objektinspektor veröffentlicht.
Eigentlich nur dann Sinnig, wenn diese Klasse irgendwie im Objektinspektor verwendet werden soll. Published - Eigenschaften kann man eben dann im Objektinspektor verändern, 'nur' public Eigenschaften nicht.

Der Punkt ist mir noch nicht ganz klar. Ich verstehe das irgendwie mit dem Objektinspektor, aber sehe nicht den großen Sinn darin, da Klassen nicht den OI nutzen. Außer, daß ist im Zusammenhang mit Komponenten gemeint. Komponenten nutzen auch Klassen. Hinter Items von ListBox steht die Klasse TStrings. Somit würde das Ganze wieder einen Sinn ergeben, da hier eine Klasse im Objektinspektor angezeigt wird.

Was mir aber noch nicht ganz klar ist, inwieweit können die published Eigenschaften im OI verändert werden und public nicht? Werden die public Eigenschaften nicht gezeigt oder können sie nicht verändert werden oder fehlen da einige Informationen?

Ich glaube das mit public und published jetzt zumindest ansatzweise verstanden zu haben, aber beherrschen tue ich es noch nicht. Was passiert wenn Items von ListBox public und nicht published ist?

[Phoenix]

Genau: Das ist hauptsächlich für Komponenten interessant bzw. für Klassen, die von Komponenten verwendet werden.
Public werden im OI nicht angezeigt, Published eben schon.

Zu private / protected:
Es wird logischerweise beides vererbt. Aber die abgeleitete Klasse kann nicht direkt auf die private Elemente zugreifen.

Beispiel:

Delphi-Quellcode:

TMyClass = class
private
  fCreated: TDateTime;
protected
  function getCreated:TDateTime;
public
  constructor Create();
end;

constructor TMyClass.Create();
begin
  fCreated := now;
end;

function TMyClass.getCreated:TDateTime;
begin
  result := fCreated;
end;

In jeder abgeleiteten KLasse kannst Du auf getCreated zugreifen und bekommst das Datum der Erstellung. Das Feld fCreated wird also mit vererbt. Du kannst aber NICHT auf fCreated einen anderen Wert zuweisen.

[Luckie]

Hm, also ich dachte, das wäre in meinem Tutorial deutlich geworden. :gruebel:

[guidok]

Ich häng mich mal ganz kurz mit ran:

Was ist mit den Deklarationen, die ohne Attribut angelegt werden?

z.B.

Delphi-Quellcode:

TMyClass = class 
  fCreated: TDateTime; 
protected 
  function getCreated:TDateTime; 
public 
  constructor Create(); 
end;

"fCreated" steht jetzt direkt unterhalb der Klassenableitung, wie wird das behandelt?

[Tyrael Y.]

Zitat:

Zitat von guidok

Ich häng mich mal ganz kurz mit ran:

Was ist mit den Deklarationen, die ohne Attribut angelegt werden?

z.B.

Delphi-Quellcode:

TMyClass = class 
  fCreated: TDateTime; 
protected 
  function getCreated:TDateTime; 
public 
  constructor Create(); 
end;

"fCreated" steht jetzt direkt unterhalb der Klassenableitung, wie wird das behandelt?

...es wird als published angesehen

...nimm mal eine Form, packe einfach paar Komponenten drauf und schau mal wo sie in der Form-Klasse eingefügt werden

[Muetze1]

Nein, nicht explizit. Es kann published oder auch public sein!

Zitat:

Zitat von Delphi Hilfe

Ein Element ohne Attribut erhält automatisch die Sichtbarkeit des vorhergehenden Elements in der Deklaration. Die Elemente am Anfang einer Klassendeklaration ohne explizite Sichtbarkeitsangabe werden standardmäßig als published deklariert, wenn die Klasse im Status {$M+} compiliert oder von einer mit {$M+} compilierten Klasse abgeleitet wurde. Andernfalls erhalten sie das Attribut public.

[Gonzo2]

@Phoenix

Ich hab ein wenig mit deiner Klasse experimentiert. Du hast Recht, es ist so, daß die private Variable in der Nachfolgeklasse nicht angesprochen werden kann, die protected schon. Allerdings gilt das nicht wenn man die Nachfolgeklasse in der gleichen Unit ableitet. Dann kann man auch auf die Variablen in private zugreifen. Böse Falle. Vor allem für Anfänger die dann kein Unterschied sehen. Also kann man für jeden Anfänger der üben will die goldene Regel geben:

Beim üben von Klassen, immer mit zwei Units arbeiten und den Nachfahren immer in einer zweiten extra Unit ableiten, sonst sieht man in der gleichen Unit Elemente die man eigentlich nicht sehen sollte.

Delphi-Quellcode:

//==== Unit1 ====
type
  TMyClass = class
  private
    fCreated: TDateTime; //mal private, mal protected
  protected
    //fCreated: TDateTime; //mal private, mal protected
  public
    constructor Create();
  end;

constructor TMyClass.Create();
begin
  fCreated := now;
end;

Delphi-Quellcode:

//==== Unit2 ====
type
  TMyClass2 = class(TMyClass)
  public
    constructor Create();
  end;

constructor TMyClass2.Create();
begin
  inherited;

  //fCreated := now-1; //versuchen Wert zu ändern, mal mit private, mal protected
end;

Bei einer Unit kann man bei der zweiten Klasse immer auf die Variable zugreifen, bei zwei Units klappt das nur bei protected.

Zitat:

Zitat von Luckie

Hm, also ich dachte, das wäre in meinem Tutorial deutlich geworden. :gruebel:

Ja, es ist sonderbar, aber wenn man es verstanden hat, dann ergibt Deine Beschreibung wirklich Sinn. Vorher ist aber nicht klar wie das genau gemeint ist. Für den Wissenden ist das alles logisch, für den Unwissenden etwas unklar.

Zitat:

Zitat von Muetze1

Nein, nicht explizit. Es kann published oder auch public sein!

Zitat:

Zitat von Delphi Hilfe

Ein Element ohne Attribut erhält automatisch die Sichtbarkeit des vorhergehenden Elements in der Deklaration. Die Elemente am Anfang einer Klassendeklaration ohne explizite Sichtbarkeitsangabe werden standardmäßig als published deklariert, wenn die Klasse im Status {$M+} compiliert oder von einer mit {$M+} compilierten Klasse abgeleitet wurde. Andernfalls erhalten sie das Attribut public.

Acha, das ist die Erklärung. Es ist public, aber mit {$M+} ist es published.

Irgendwo habe ich gelesen, daß man selbst selten den Status {$M+} setzten muß, da in der Regel schon der Vorfahr den {$M+} Status gesetzt hat und damit wären Elemente ohne Sichtbarkeitsattribute published.


Abschließend will ich nochmal kurz auf public und published eingehen und ihre Wechselwirkung mit Komponenten. Das mit der Komponente testen ist etwas schwieriger, da hier dann erst die Komponente installiert werden muß usw. Werde ich noch machen, ist aber ein etwas größerer Aufwand.

Aber kann man das jetzt so sagen, daß der einzige Unterschied ist, daß public im OI nicht sichtbar ist und published schon. Ist das der einzige Unterschied? Oder gibt es da noch etwas mehr?

[Tyrael Y.]

Zitat:

Zitat von Gonzo2

Aber kann man das jetzt so sagen, daß der einzige Unterschied ist, daß public im OI nicht sichtbar ist und published schon. Ist das der einzige Unterschied? Oder gibt es da noch etwas mehr?

Nicht ganz, nur published Elemente beinhalten RTTI-Informationen udn können aus diesem Grund auch im OI angezeigt werden.
Die RTTI-Informationen kann man aber auch selber nutzen, um in einem Objekt die vorhandenen Felder durchzugehen.

-> published und public unterscheiden sich dadurch, daß published RTTI-Informationen enthält, public nicht

[Gonzo2]

Also gut, noch weiß ich nicht 100% was RTTI ist, bis auf, daß es Laufzeit-Typinformationen sind, aber soweit kann ich vorerst damit leben. Bei published werden eben einige Informationen mitgeliefert die der OI braucht, bei public nicht.

Kann man somit sagen, daß published mit der Sicht auf Komponenten da ist? Oder nur für den OI?

Wie auch immer, gilt immer noch die Aussage, daß der OI keine public Eigenschaften zeigt, sondern nur published?

[Tyrael Y.]

Zitat:

Zitat von Gonzo2

Kann man somit sagen, daß published mit der Sicht auf Komponenten da ist? Oder nur für den OI?

Wie auch immer, gilt immer noch die Aussage, daß der OI keine public Eigenschaften zeigt, sondern nur published?

Der OI kann nur published Eigenschaften zeigen, da es nur diese aus den RTTI-Informationen extrahieren kann. Man hat keine Möglichkiet durch public Eigenschaften einer Klasse zu iterieren und diese wie auch immer zu verarbeiten.

Erst durch das published sind Informationen in der Klasse vorhanden.


Man kann sich das so vorstellen, daß durch das published diese Felder in eine Art Liste landen und somit auch aus dieser Liste abgerufen werden können, alles was nicht published ist, ist auch nicht in der Liste und kann daher auch nicht abgerufen werden.

Das published ist also nicht nur für den OI da, sondern um Feldinformationen abfragen zu können, wer diese Informationen abfragt ist egal, es steht jedem zur Verfügung.

[taaktaak]

Moin, Moin!
Da möchte ich mal einhaken; Phoenix schreibt

Zitat:

Private
Nur sichtbar in der eigenen Klasse (und, aber das finde ich persönlich unschön, in anderen Klassen in der gleichen unit).
Eine abgeleitete Klasse kann auf ein private - Element nicht zugreifen.

Das habe ich vor einigen Tagen bei TSplitter schmerzlich erfahren. Ich benötige einen Splitter, in dem ich nicht nur den MinWert, sondern auch den MaxWert setzen kann. Dieser Wert existiert als FMaxSize - und ist als private deklariert.

Ich wusste mir nicht anders zu helfen, und habe den gesamten Quelltxte in eine "neue" Komponente kopiert und eben das gewünschte Verhalten "eingebaut" - aber ehrlich, das hat ja nun mit Vererben überhaupt nix zu tun. Die "eigene" Komponente in die Original-Unit zu packen erscheint mir irgendwie auch zweifelhaft.

Gibt es da wirklich keinen anderen Weg?????
Gruß Ralph

[Tyrael Y.]

Zitat:

Zitat von taaktaak

Moin, Moin!
Gibt es da wirklich keinen anderen Weg?????

Leider nicht :(

...deshalb gehen viele Komponentenentwickler dazu über möglichst alle Felder als protected zu deklarieren und wirklich nur Felder, von denen man absolut annehmen kann, daß die von keinem Nachfolger mehr gebraucht werden könnten private zu machen

...ich mach das meist auch jetzt so, daß ich meistens Felder als protected deklariere

[Gonzo2]

Zuerst mal danke an alle. Meine Fragen sind zu den Punkten soweit geklärt.

Aber eine komische Kleinigkeit ist mir aufgefallen die eigentlich nicht sein sollte.

Hier eine Klasse und eine in einer exta Unit abgeleitete Klasse

Delphi-Quellcode:

//==== UNIT1 ====
type
  TMyClass = class
  protected
    fCreated: TDateTime;
    //function getCreated: TDateTime; //mal protected, mal public
  public
    constructor Create();
    function getCreated: TDateTime; //mal protected, mal public
  end;

  constructor TMyClass.Create();
  begin
    fCreated := now;
  end;

  function TMyClass.getCreated: TDateTime;
  begin
    result := fCreated;
  end;

Delphi-Quellcode:

//==== UNIT2 ====
type
  TMyClass3 = class(TMyClass)
  public
    constructor Create();
  end;

constructor TMyClass3.Create();
begin
  inherited;
  fCreated := now;
end; 

procedure TForm1.Button3Click(Sender: TObject);
var
  MyClass3: TMyClass3;
begin
  MyClass3 := TMyClass3.Create;
  try
    ShowMessage(DateToStr(MyClass3.getCreated));
    ShowMessage(DateToStr(MyClass3.fCreated));
  except
    MyClass3.Free;
  end;
end;

fCreated ist in TMyClass in protected, somit unsichtbar für Nutzung. Das stimmt auch soweit die Funktion getCreated in public ist. Verschiebe ich getCreated aber in protected, bietet meine abgeleitete TMyClass3 plötzlich auch fCreated an. Wie kann das sein? Ist doch protected.

[Tyrael Y.]

Du hast TForm und TMyClass3 in derselben Unit, deshalb klappt das auch.

Mach mal 2 verschiedene Units, eine für TMyClass, eine für TMyClass3, dabei aber TMyClass3 nicht wieder in dieselbe Unit wie die TForm packen, dann wird das nicht gehen.

[Gonzo2]

Über eine dritte Unit klappt das nicht.

Und wieso klappt das in Form1? Wird da alles zusammengeworfen?

Ist jetzt nicht so wichtig, interessiert mich nur so nebenbei.

[Gonzo2]

Nochmal kurz zu private, protected, public und published. Ich hab den Verwendungszweck mehr oder weniger verstanden. Allerdings hätte ich da noch eine Abschlußfrage, bzw. brauche ich eine Bestätigung.

Bei reinen Klassen kommen nur diese drei Schutzklassen zum Einsatz: private, protected und public. private wenn es privat sein soll und nur in der eigenen Klasse inc. der Unit sichtbar sein soll, später in abgeleiteten Klassen aber unsichtbar. protected wenn es privat sein soll und nur in der eigenen Klasse inc. der Unit sichtbar sein soll, später aber auch in abgeleiteten Klassen privat sichtbar bleiben soll. public wenn es öffentlich sein soll.

Soweit es ganz normale Klassen sind kommen nur diese drei Schutzklassen zum Einsatz. published spielt bei normalen klassen keine Rolle.

published, der ähnlich dem public ist, spielt erst dann eine Rolle wenn man Komponenten erstellt. Auf diese Weise kann man unter anderem steuern was im OI sichtbar sein soll.

Das ganze ist jetzt vereinfacht ausgedrückt, aber kann man das so in etwa sagen? Vor allem das mit published?

[Jelly]

Zitat:

Zitat von Gonzo2

Das ganze ist jetzt vereinfacht ausgedrückt, aber kann man das so in etwa sagen? Vor allem das mit published?

Das könnte man so sagen, ja. Im Motor selbst gibt es da aber noch Unterschiede, aber meist reicht es zu wissen, dass published Eigenschaften im ObjectInspector sichtbar (sofern sie eine Setter-Methode besitzen und so nicht readonly sind).

Ergänzend noch, dass es ab Delphi 2006 (glaub ich... Kann auch schon D2005 sein) noch strict private gibt. Dann sind die Methoden/Eigenschaften tatsächlich ausschliesslich innerhalb der Klasse sichtbar, und NICHT mehr innerhalb der anderen Klassen in der gleichen Unit.

[Luckie]

Ich habe mein Tutorial diesbezüglich über arbeitet. Eventuell wird es ja jetzt etwas klarer: http://www.delphipraxis.net/internal...ct.php?t=18769

[Gonzo2]

Zitat:

Zitat von Jelly

Zitat:

Zitat von Gonzo2

Das ganze ist jetzt vereinfacht ausgedrückt, aber kann man das so in etwa sagen? Vor allem das mit published?

Das könnte man so sagen, ja.

Ich glaube es jetzt verstanden zu haben. Nur stellt sich dann die Frage wieso man es den Leuten nicht mit diesen einfachen Worten sagt. Sicher, wenn man die ganzen Anleitungen liest und und das Ganze schon drauf hat, dann erscheint das Geschriebene auch logisch. Acha, Published steuert die Sichtbarkeit im Objektinspektor. Sicher, was kann das sonst bedeuten, es kann sich nur um ein Attribut für Komponenten handeln. Darauf muß man erst kommen. Auf der anderen Seite könnte man auch einen Wink mit der Komponente geben.

[sirius]

Hier sieht man mal, wozu man noch published Properties braucht ausser im OI.

[Christian Seehase]

Moin Sirius,

Zitat:

Zitat von sirius

Hier sieht man mal, wozu man noch published Properties braucht ausser im OI.

auf welchen Teil des Threads beziehst Du Dich da?
Ich kann da nichts entdecken.

[sirius]

Die Lösung des gesamten Problems in dem Thread geht nur über published Properties. Und das unabhängig davon ob es jetzt eine Komponente ist, die auch über den OI genutzt werden kann.

Und dann eben alle Funktionen aus der Unit TypInfo:
-IsPublishedProp
-SetPropValue
-GetPropValue
-SetOrdProp
-GetOrdProp
Die funktionieren nur für published Properties.

[Gonzo2]

Vielen Dank für die Antwort. Die Frage die sich nun stellt ist, war die Info wichtig oder war ihr einzige Zweck das Verständnis zu zerstören? Oder anders gefragt, wozu dienen diese Funktionen eigentlich? Ist ihr Zweck der, daß man mit ihnen lustige Texteditoren programmieren kann? Oder ist ihr Zweck der, daß man mit ihnen bestimmte Komponenteniformationen ermitteln kann? Also etwas was auch der OI macht. Auf gut Deutsch, ein Zimmermannshammer ist dazu da um Nägel irgendwo rein zu schlagen, aber man kann damit auch eine Bierflasche öffnen. Der OI ist letztendlich auch nur ein Programm und muß irgendwie an die Informationen kommen. Zaubern und Gedankenlesen kann er auch nicht. Es muß also Funktionen geben die ihm die Informationen liefern. Und natürlich ist es nicht verboten sie auch für eigene Zwecke zu verwenden, spricht, man kann damit auch die Bierflasche öffnen.

Manchmal haben einige Leute so ein mega großes Bedürfnis etwas klar zu stellen, daß sie es auch auf Kosten des Verständnisses machen. Wenn einer auf die Frage nach dem Zimmermannshammer erklärt, daß er für die Nägel da ist, kommen sie mit der Bierflasche an.

Da du dich also eingemischt hast und mein Verständnis über das published Attribut gerade das Klo runtergespült hast, wäre es nett wenn du mir mit deinem Worten ausführlich die Bedeutung von published erklären würdest. Wir haben gerade gesehen, daß die Informationen für den OI nur eine der Nutzungsmöglichkeiten sind. Ansonsten kann man die Informationen anscheinend auch in der täglichen Programmierung nutzen.