Wie teilt man diese Bibliothek in Entwurfszeit und Laufzeit auf?

[neumimnemecky]

Wie wird diese Bibliothek (
Big Bitmap Viewer v.1.01
) gemäß diesem Artikel in Entwurfszeit und Laufzeit aufgeteilt?
https://edn.embarcadero.com/article/27717
Ich benutze D7 und die Komponente ist in der alten D2(?).

Der Artikel enthält ein Beispiel:

Code:

unit MixedComponent;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;

type
  { TMixedComponent }
  TMixedComponent = class(TComponent)
  private
    FFileName: String;
  published
    property FileName : String read FFileName write FFileName;
    { Published declarations }
  end;

implementation

end.

Wie Sie sehen können, gibt es keine Funktionsdeklaration, aber die BitView-Komponente verwendet einen einfachen Ein-Element-Eigenschaftseditor, und die Klasse hat Eigenschaften, auf die über eine Methode zugegriffen wird.

Daher kann ich die Eigenschaften, die Teil der Klasse sein sollten, nicht deklarieren:

Code:

{    property AutoSize : boolean read FAutoSize write SetAutoSize default false;
// bitmap centred
    property Centre : boolean read FCentre write SetCentre default false;
// filename of bitmap
    property Filename : TBMPFilename read FFilename write SetFilename;
// stretch bitmap
    property Stretch : boolean read FStretch write SetStretch default false;
// READ-ONLY PROPS
    property Colours : integer read FColours write SetDummyInt stored false;
    property BitmapHeight : integer read FBitmapHeight write SetDummyInt stored false;
    property BitmapWidth : integer read FBitmapWidth write SetDummyInt stored false;
    property Active : boolean read FActive write SetActive default false;
}

property Active : boolean read FActive write SetActive default false;

Und ich kann diese Methoden nicht deklarieren, weil ich sie nicht in dieser Datei implementieren kann. Und der Artikel ist einfach nicht erklärend genug, es wird nicht erklärt, wie es geht.

Danke.

[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.