Komponente soll sich selbst zerstören

[Anke Pischon]

Hallo Leute!

Ich habe mir neue Basisklassen für TWinControl und TGraphicControl programmiert. Die "GraphicControls" zeichnen nicht direkt auf den DC sondern nutzen eine interne Bitmap des Host-Wincontrols. Daher macht es nur Sinn diese Compos auf "meinen" Wincontrols zu plazieren.
Nun möchte ich beim Initialisieren der Compo den Parent abfragen und falls dieses Control nicht meinem TWincontrol oder einer abgeleiteten Klasse entspricht soll sich die Compo mit einer Meldung selbst wieder freigeben / löschen. Es führt aber zu bösen Schutzverletzungen, wenn ich einfach Free aufrufe. Wie kann ich dieses realisieren?
Hab sowas schon mal irgendwo gesehen ... muß also möglich sein.
Außerdem kann man im OnClose Event eines Forms auch caFree als Rückgabe angeben.

Vielen Dank schon mal!

OLLI

[Jens Schumann]

Hallo Anke,<br>
Komponenten und Objekte sollte so weit wie möglich selbstständig sein und <b>nicht </b>vom Vorhandensein anderer<br>
Komponenten o. Objekte abhängig sein. D.h. Dein Problem ist, dass die TGraphicControls eine die interne Bitmap der TWinControls<br>
verwenden. Wenn die TGraphicControls nicht darauf angewiesen wären, könntest Du evt. auf ein Free verzichten.<br>
Jens Schumann<br&gt

[Anke Pischon]

Hallo Jens!

Mit objektorientiertem Programmieren bin ich bestens vertraut. Ich habe meine Frage bewußt so ausführlich formuliert, um rein qualitative Antworten auszuschließen.

Anke / OLL

[Hagen Reddmann]

pack Deine Überprüfung im .Loaded der Komponente rein. Beim .Create() hat ein TControl normalerweise noch garkeinen .Parent. Dieser kann erst nachdem das Object vollständig erstellt wurde dem Object zugewiesen werden. Ein constructor sollte auch nicht mit .Free beendet werden sondern mit einer Exception oder aber Fail.
Ansonsten gebe ich aber Jens recht, da es vom OOP Design her gesehen eben falsch im constructor ein .Free aufzurufen, bzw. ein TControl zu coden das nur mit speziellen Controls als Parent funktioniert.

Gruß hage

[Anke Pischon]

1. Mit "initialisieren" habe ich nicht den Constructor gemeint, sondern die vollständige Integration in das Formular. Also auch die Zuweisung des Parents.

2. Loaded wird nur aufgerufen, wenn die Properties der Compo vollständig aus dem Formularstream geladen worden sind. Das geschiet beim Öffnen des Fenstern in der IDE oder beim Programmstart.

3. Das Control funktioniert bisher sehr wohl ohne speziellen Parent. Durch dieses Feature kann ich aber auf den Canvas meines Controls ganz verzichten. Über die Performance der GDi Graphikfunktionen brauch ich sicher nichts zu erzählen!

4. Ich hab mir die Lösung eben selber erarbeitet. Die Lösung ist ein kleiner Komponenteneditor für die Kompo. Der welchselt mit dem Form-Designerinterface ein paar warme Worte und plaziert die Kompo dann gegebenfalls auf einem meiner Wincontrol Derivate oder löscht die Kompo gleich wieder.

5. Da das sicher sowieso niemanden interessiert, verziechte ich auf ein Beispiel. ;-

[Hagen Reddmann]

Anke, warum bist Du so aggressiv ??
Wenn ich Dich richtig verstehe dann treibst Du diesen Aufwand um verschiedene Zeichenroutinen untergeordneter Controls in eine Bitmap, die im Parent verwaltet wird, zu zeichnen. Das soll dann deiner Meinung nach schneller als die GDI Funktionen sein. Nun, dem ist leider nicht so. Falls eine untergeordnetes Control sich neuzeichnen soll, und nur dieses, so muß das Parent Control ja die komplette Bitmap neu ausgeben. Das ist natürlich langsammer.
Ansonsten empfehle ich Dir mal bei TWinControl.DoubleBuffered:Boolean in der Hilfe nachzuschauen.

Gruß Hage

[Anke Pischon]

Hallo Hagen!

1. Ich bin nicht aggressiv! Ich hatte nur nicht um Kritik sondern um konstruktive Hilfe gebeten.

2. Doublebuffered kenn ich. Zeichnet alles auf eine interne temporäre Bitmap und gibt dann den Spaß aus. Hab mir den Quellcode der VCL schon des öfteren vorm schlafengehen reingezogen.

3. Du hast leider unrecht, wenn Du sagst daß meine Methode langsamer ist:

3.1 Das Control wird nur neu gezeichnet, wenn sich die Grösse oder Darstellung ändern. Ansonsten wird NUR per BitBlt das fertige Bild neu auf den DC kopiert.

3.2. Es wird nur der Teil der Bitmap ausgegeben der nötig ist => GetClipRect(DC) bzw. nur die GraphicControls neu gezeichnet die sich im ClipRect befinden.

3.3. Beherrschen die GDI Funktionen Alphablending, Antialiasing, Gauss-Blur, etc. ... Hast Du schon mal versucht eine Bitmap mit Canvas Funktionen frei zu drehen? Nimm Dir vieeeel Zeit.

3.4 Alle meine Compos teilen sich EINE interne Bitmap => volle Transparenz auch bei Wincontrols ohne Klimmzüge.

4. Im Übrigen halte ich Dich anhand Deiner Beträge für einen der besten Entwickler in diesem Forum! Daher finde ich es schade, daß Du meine Methode so abtust, ohne die Einzelheiten zu kennen!

5. Im übrigen heiße ich Olli und nicht Anke. Bin nur zur Zeit bei meiner Freundin, und mußte zur Forum-Registrierung ihre Mail-Addi angeben *ggg*.

Viele Grüsse und nix für ungut

OLL

[Hagen Reddmann]

Tja Olli, aus Deiner Frage ging leider nicht hervor das Du noch Alphablending, Antialiasing usw. uvm. komplexere Berechnungen durchführen willst. Das ändert erheblich und berechtigt die Entwicklung vollständig neuer Basisklassen.

Eine Idee hätte ich noch, überschreibe .Setparent() und überprüfe VOR dem inherited Setparent() ob der neue Parent vom richtigen Klassentyp ist. So jedenfalls bin ich bei meinen Toolbars und Docks vorgegangen.

Gruß Hagen

PS: soll das eine Freeware werden ? würde mich schon interessieren