Wie teilt man diese Bibliothek in Entwurfszeit und Laufzeit auf?

[himitsu]

Für Boolean (AutoSize/Centre/Stretch/Active) gibt es bereits einen fertigen Standard-PropertyEditor, welcher auch mit MultiSelection klar kommt.
siehe TCheckBox.Checked uvm.

Ebenso für Integer (Colours/BitmapHeigh/BitmapWidth).

Fazit: Für die gezeigten Property wäre garkein eigener Property-Editor nötig.




Runtime-Package:
* Requires:
* * RTL, VCL und was noch nötig ist
* rein kommt :
* * die Komponente (deine BITVIEW.PAS)

Design-Time-Package
* Requires:
* * das Runtime-Package (also hat man hier Zugriff auf alles in der BITVIEW.PAS)
* rein kommt:
* * die Design-Komponenten und so
* * RegisterComponent
* * der Property-Editor


Wird die Anwendung niemals mit Packages kompiliert, also niemals das Package verwendet, könnte mman auch alles in ein Package packen, da dann eh nur die PAS/DCU verwendet werden und das DesignZeugs nicht in der EXE landen würde, aber sowas macht man dennoch besser nicht. (nicht dass es raucht, wenn doch mal wer mit Packages kompiliert)



Bezüglich des Beispiels von Borland/Embarcadero,
da hätte ich gedacht, dass es bereits einen fertigen Property-Editor für TFileName gäbe,
property FileName : TFileName read FFileName write FFileName;
aber TMediaPlayer.Filename hat einen Editor, aber TOpenDialog.Filename nicht. Also es gibt einen Editor, aber er hängt nicht nur am Typ, sondern auch an der Klasse

[neumimnemecky]

Zitat von himitsu:

Runtime-Package:
Wird die Anwendung niemals mit Packages kompiliert, also niemals das Package verwendet, könnte mman auch alles in ein Package packen, da dann eh nur die PAS/DCU verwendet werden und das DesignZeugs nicht in der EXE landen würde, aber sowas macht man dennoch besser nicht. (nicht dass es raucht, wenn doch mal wer mit Packages kompiliert)

Und wie löst man diesen speziellen Code der Klassen-property-Deklaration für die Schreib- oder Lesemethode?

[himitsu]

Es gibt hier keine DesignTime-Komponente und Runtime-Komponente.
Es ist die selbe Komponente.

Die DesignTime-Funktionen greifen auf die "richtige" Komponente zu.
Die Property werdem nicht nochmals deklariert, in keiner anderen Klasse.





TMixedComponent kommt ins Runtime-Package (MixedComponent)
und TMixedFileNameProperty kommt ins DesignTime-Package (MixedComponentReg).

Oder eben einfach billig so, wie es anfangs in dem Artikel aussieht ... also alles ins selbe Package/Unit.

[neumimnemecky]

Zitat von himitsu:

Es gibt hier keine DesignTime-Komponente und Runtime-Komponente.
Es ist die selbe Komponente.

Die DesignTime-Funktionen greifen auf die "richtige" Komponente zu.
Die Property werdem nicht nochmals deklariert, in keiner anderen Klasse.

Aber wie man so etwas deklariert (Split):

Code:

private
 procedure SetActive (Value : boolean);
public
property Active : boolean read FActive write SetActive default false;

Ich kann mir die Aufteilung hier nicht vorstellen.
Ich werde braten

Code:

 procedure SetActive (Value : boolean);
public

und
Ich erhalte eine Fehlermeldung, dass SetActive nicht deklariert ist.
Ich lösche die Active-Eigenschaft,
und ich werde das ganze Objekt stören.

[himitsu]

Das wird auch nicht aufgeteilt.
Es gehört alles zur Komponente. Also nicht ins DesignTime-Package.



Im PropertyEditor greift man "normal" garnicht direkt auf das Property/Getter/Setter/Objekt/Klasse zu, sondern nutzt die gegebenen Funktionen für den Zugriff auf das Property. (z.B. SetStrValue/SetStrValueAt/GetStrValue/GetStrValueAt ... intern via RTTI)
Alternativ bietet der PropertyEditor eine Methode an, um das Objekt zu bekommen und dann selber via RTTI oder mit einem Cast zu Typen und da kann man dann auch direkt mit dem Objekt arbeiten.