platzierte visuelle Objekte nachträglich ableiten

[mschnell]

Etwas, das ich bei Delphi immer vermisst und nicht gefunden habe. Geht das vielleicht in Lazarus:

Ich platziere eine visuelle Komponente aus der Komponenten Library auf einem Form.
Für diese Komponente möchte ich zusätzliche Funktionalitäten definieren.
Ich möchte also von dieser Klasse eine neue ableiten und die neue statt der ursprünglichen aus der Komponenten Library verwenden, ohne extra die neue Klasse in der Library installieren zu müssen.
Das sollte möglich sein, da die neu definierten Funktionalitäten nicht "published" sind und keinen design-time Code enthalten, der Form-Editor also nicht betroffen ist.

Gibt's da was ?

-Michael

[theo]

Dafür ist ein "Bounty" ausgesetzt

http://wiki.lazarus.freepascal.org/index.php/Bounties

Siehe: Visual Form Inheritance (VFI) - $400

[Christian]

Ne, der designer muss die komponenten kennen mit denen er arbeitet egal ob die propertys für ihn ne rolle spielen oder nicht.
Was es ansatzweise gibt und geben wird ist Visual Form Inherence, da kannst du dir eine Form basteln und andere davon ableiten Visuell.

[Christian]

@theo das was er da beschrieben hat ist aber kein VFI

[theo]

@theo das was er da beschrieben hat ist aber kein VFI

Joh, stimmt. Da hatt ich wohl zu schnell gelesen.

[mschnell]

"Im Prinzip" müsste man, wenn die Unit mit der abgeleiteten Klasse im Projekt ist, doch nur im lfm und im pas File die Typen der Instanz-Definition ändern und neu übersetzten.

Delphi weigert sich, wenn man so etwas tut. Bei Lazarus habe ich es noch nicht probiert.

-Michael

[Christian]

wpher soll die ide denn wissen das deine neuen eigenschaften keine alten der komponente verändern das ist schlichtweg unmöglich

[mschnell]

woher soll die ide denn wissen das deine neuen eigenschaften keine alten der komponente verändern das ist schlichtweg unmöglich

Und was ist die IDE ?

Die visuellen Komponenten bringen ihre eigenen Routinen mit, die ablaufen, wenn ein auf einem Form an ihnen gebastelt wird. Die abgeleitete Komponente erbt diese von der
Standard-Komponente. Also "im Prinzip" kein Problem.

Und woher bezieht die IDE ihr "Wissen" über die Eigenschaften einer Komponente ?

Die "visuellen" Eigenschaften der Komponenten werden im "published" Bereich definiert und dann in der lfm-Datei gespeichert. Wie gesagt, soll beim Ableiten der published-Bereicht nicht verändert werden. Die nicht "published"-Eigenschaften der Komponente interessieren die IDE nicht. Also auch hier "im Prinzip" kein Problem.

Das sollte also irgendwie möglich sein.

-Michael

[Christian]

Nein die komponenten haben keine extra routinen für den designer.
Der designer überschreibt die Narichtenschleife der Komponenten und kann so bestimmern welche narichten an die komponente weitergeleitet werden ausserdem sendet er eigene Narichten zum verschieben oder ähnliches.

Damit er die Schleife überschreiben kann muss die komponente dynamisch oder statisch eingelinkt werden (unter delphi mit packages, unter lazarus (noch) nativ).
Du magst das villeicht so hanedeln das du bestehende Möglichkeiten nicht modifizierst. Aber wenn es das feature wirklich geben würde würde irgendjemand garantiert mal auf die alten eigenschaften der komponente zugreifen oder die Narichtenschleife selbst benutzen wollen und das alles funktioniert dann plötzlich nicht weil lazarus mit einer veralteten version der komponente arbeitet. Das macht mehr ärger als das es nutzen bringt. Fpc 2.2.x wird packaging mitbringen damit können dann komponenten "on-the-fly" eingebunden werden wie bei delphi und wenn ne komponente mal ärger macht stürzt nicht gleich die ganze ide ab sondern nur das package und kann entfernt werden. ich denke es macht mehr sinn auf den fpc 2.2.x zu warten ist ja auch nicht mehr in so weiter ferne.

Nebenbei die 0.9.22 wird in den nächsten tagen freigegeben werden und da sind schöne neue sachen drin wie z.b. die cursors funktionieren usw

[mschnell]

(...für zur Designzeit laufenden Code in visuellen Komponenten gibt es extra csdesigning...)

Aber wenn es das feature wirklich geben würde würde irgendjemand garantiert mal auf die alten eigenschaften der komponente zugreifen

Ah, verstehe,

Das ist aber auch nicht das, worauf ich hinaus will.

Die IDE soll ruhig weiter mit der ursprünglichen Komponente arbeiten. Erst zur Runtime soll der neue Typ verwendet werden. Also erst Application.CreateForm muss den neuen Typ kennen. Die zugehörige Information steht in der lfm-Datei und kommt dann als Ressource in's Programm. Die Veränderung müsste also vorgenommen werden, wenn die Ressource erzeugt wird (dann müsste man das Compile-System entsprechend erweitern), wenn die Ressource verarbeitet wird (Runtime-System), oder der Typ wird nachträglich ausgetauscht, wenn alles schon läuft.

Das letzte kommt mir am leichtesten vor, weil (wenn's denn geht) nur user-Code nötig ist. Man kann eine Komponente doch in eine andere kopieren. Wenn die neue nun den abgeleiteten Typ hat, sollten wir doch fast da sein.

Ich probier's 'mal.

-Michael

[Christian]

(...für zur Designzeit laufenden Code in visuellen Komponenten gibt es extra csdesigning...)

das ist nur dafür da damit die komponente weiss on sie im designer läuft, so wissen kommerzielle delphi komponenten z.b. das sie jetzt keinen nag screen anzeigen müssen oder komponenten die in der ide noch nicht funktionieren sollen wie z.b. ne videocapturekomponente o.ä.

Das ist aber auch nicht das, worauf ich hinaus will.

du verstehst aber anscheinend auch nicht worauf ich hinaus will.
das feature ist sehr verwirrend für leute die das komponentensystem nicht oder nur schlecht kennen. Ausserdem bringt es keine vorteile ausser das du die ide im moment noch neu kompilieren musst was dann entfällt. sobals das packaging system fertig ist wäre dieses feature also volkommen überflüssig.

[mschnell]

Mit "if csdedigning in Componentstate" z.B. in der Set-Funktion einer Property kann man feststellen, ob die Property zur Runtime vom User-Programm gesetzt wird oder zur Design-Time durch die IDE. Hierdurch kann man das Verhalten der Komponente in der IDE bestimmen. Die IDE (wie die User-Software) "macht" nämlich nichts mit den Komponenten, sondern sagt ihnen, was sie mit sich selbst machen sollen (setzt z.B. die Property Left, damit sich die Komponente selbst an der entsprechenden Posution darstellt). csdesigning wird benötigt, wenn das verhalten zur Design-Zeit anders sein soll als im Programm. Ich könnte also die Komponente in der IDE rot darstellen, wenn Left ungerade ist, im Normalbetrieb aber allse beim alten lassen. (So ist das zumindest in Delphi, In Lazarus habe ich mir das noch nicht angeschaut.) Die IDE weiß von der Komponente also auch nicht mehr als im Sourcecode steht.

>>Fpc 2.2.x wird packaging mitbringen damit können dann komponenten "on-the-fly" eingebunden werden

Heißt das, mit Lazarus muss eine visuelle Komponente "global" installiert werden, projektspezifisch geht im Moment nicht ? (OK kein Problem, wenn Verbesserung in Sicht ist.)

Wie installiert man bei Lazarus denn überhaupt neue visuelle Komponenten ?

Gruß,
-Michael

[Christian]

Heißt das, mit Lazarus muss eine visuelle Komponente "global" installiert werden, projektspezifisch geht im Moment nicht ? (OK kein Problem, wenn Verbesserung in Sicht ist.)

Seit wann kann denn Delphi Projektspezifisch komponenten einbinden ?
und wie läuft das dann muss ich in dem projekt einstellen wo die komponenten liegen und mit dem projekt in diesem verzeichnis mitliefern ?
ich kenn Delphi nur bis zur version 7 und dort muss man alle komponenten installiert haben die ein projekt benötigt.

Wie installiert man bei Lazarus denn überhaupt neue visuelle Komponenten ?

Genau wie bei Delphi Komponenten->Package Datei öffnen->Installieren

[mschnell]

Habe ich wohl schlecht ausgedrückt. Bei Projekt->Optionen kannst Du Packages aktivieren oder deaktivieren.

...Dann versuche ich 'mal eine visuelle Komponente in Lazarus zu installieren.

-Michael

[af0815]

ch kenn Delphi nur bis zur version 7 und dort muss man alle komponenten installiert haben die ein projekt benötigt.

Nei war auch bei Delphi nicht nötig. Du hast dort auch jederzeit visuelle Komponeneten ohne Einbindung in die IDE verwenden können. Die Komponeneten Unit mit uses einbinden, dann die Komponenete zur Laufzeit erzeugen und richtig parameterisieren. Mit der IDE ist es ja viel bequemer, deshalb ist der Weg oft in Vergessenheit geraten. Aber wenn probierst eine Komponente selbst zu entwickeln, dann wirst du auf das Erzeugen zur Laufzeit nicht verzichten wollen.