Jedi-VCL Fehler: kein übergeordnetes Fenster

[meierotto]

Ich habe folgendes Problem :wall: :

Wenn ich eine Jedi-Komponente (z.B. JvMemo) auf ein Form platziere erhalte ich zur Laufzeit beim Beenden/Zerstören des Programmes die Exception EInvalidOperation mit der Meldung: Element 'JvElement' hat kein übergeordnetes Fenster.

Kennt jemand dieses Problem und vor allem weiß jemand eine Lösung? :gruebel:

[edit=sakura] Jedi->Jedi-VCL; zur Verdeutlichung angepasst. Mfg, sakura[/edit]

[shmia]

Zitat:

Zitat von meierotto

Wenn ich eine Jedi-Komponente (z.B. JvMemo) auf ein Form platziere erhalte ich zur Laufzeit beim Beenden/Zerstören des Programmes die Exception EInvalidOperation mit der Meldung: Element 'JvElement' hat kein übergeordnetes Fenster.

Du musst beim Erzeugen folgendes beachten:

Delphi-Quellcode:

   // der Owner der Komponente muss das Formular sein, damit
   // beim Zerstören des Formulars das Memo automatisch mitzerstört wird
   tmpMemo := TJvMemo.Create(self);
   tmpMemo.left := ...
   ....
   // den Owner zuweisen
   // das muss nicht das Formular sein, sondern ein Control, dass SubControls akzeptiert
   tmpMemo.Parent := Panel17;

[meierotto]

Danke shmia,

aber leider ist es das nicht.
Erstens gehe ich davon aus, wenn ich ein Objekt auf dem Form platziere, das die Parentzuweisung damit geklärt ist.
Zum anderen, selbst wenn ich nachträglich z.B. das Formular als Parent zuweise

Delphi-Quellcode:

mem.Parent:=FrmLnwBearbeiten;

kommt immer noch der gleiche Fehler.

Übrigens passiert das nicht bei allen Jedi-Komponenten, JvSpinEdit funktioniert zum Beispiel
:shock:

[generic]

ein ähnliches problem hab ich mit dem virtualstringtree von mike lischke.
in den projekten arbeite ich mit mdi-formularen.

vieleicht gibt es gemeinsamkeiten und ein bug in der vcl?

[meierotto]

Mmh, auch das hilft nicht weiter, meins ist keine MDI-Anwendung.

Trotzdem Danke

[shmia]

Zitat:

Zitat von meierotto

Danke shmia,

aber leider ist es das nicht.
Erstens gehe ich davon aus, wenn ich ein Objekt auf dem Form platziere, das die Parentzuweisung damit geklärt ist.

Ich dachte du würdest das Control zur Laufzeit erzeugen. (Miss Verständnis)
Du hast ja den Sourcecode zu dem fehlerhaften Control. ;-)
Dann kannst du ja mal nachschauen, was im Destruktor Destroy noch so alles passiert.
Im Destruktor darf dann keinerlei Zugriff mehr auf den Parent stattfinden, da der Parent ja gerade auch zerstört wird!!
Man darf im Destruktor nur eigene Resourcen freigeben und muss aber damit rechnen, dass diese Resourcen unvollständig erzeugt wurden.
Man darf auch nicht auf Dinge zugreifen, die vom Parent abstammen und zwischengespeichert wurde (z.B. ein Handle).

Ebenfalls sollte man die Procedure Notification überprüfen (falls diese in der Komponente überschrieben wurde).

[jbg]

Du hast wohl MaxLines > 0 gesetzt. Da habe ich gerade einen Fehler im Destruktor entdeckt. Jetzt muss ich erstmal schauen warum der Fehlerhafte Code da ist.

[jbg]

Der Code

Delphi-Quellcode:

if MaxLines > 0 then
  Lines.Assign(FOrgLines);

muss weg. Der ist an der Stelle völlig unnötig, da das Control zu diesem Zeitpunkt nicht mehr existent ist.
Bugfix ist auch im CVS.

[meierotto]

Vielen Dank jbg :-D ,

da ich mich in letzter Zeit erholt und Urlaub gemacht habe :sharkylinchen: , kann ich erst jetzt reagieren.
Ich werde den Destruktor gleich anpassen. Das gleiche Problem habe ich übrigens mit der Assistenten-Komponente, ich werde mal nachsehen, ob ich auch dort den Destruktor modifizieren muss.

Wie funktioniert das eigentlich mit dem CVS? :gruebel:

[jbg]

Zitat:

Zitat von meierotto

Das gleiche Problem habe ich übrigens mit der Assistenten-Komponente, ich werde mal nachsehen, ob ich auch dort den Destruktor modifizieren muss.

Mich würde mehr interessieren, welche Eigenschaften du umgestellt hast, so dass der Fehler auftritt. Denn bei mir (und dem JVCL Installer) funktioniert der JvWizard ohne Probleme.

Zitat:

Wie funktioniert das eigentlich mit dem CVS? :gruebel:

Lesen oder Schreiben?

Lesen:
1. TortoiseCVS installieren
2. Und dann Rechtklick im Explorer und auf "CVS Auschecken" klicken
3. Bei CVSROOT ":pserver:[e-mail]:/cvsroot/jvcl" eintragen
4. Bei Modul "dev/JVCL3" eintragen und OK.
Jetzt zieht er den gesamten JVCL3 Quellcode aus dem CVS und man kann mit rechtslick "CVS Lokal aktualisieren" / "CVS Update" auf dem aktuellen Stand bleiben und mit makemodified.bat die Änderungen übernehmen. Man braucht dabei aber auch immer eine aktuelle JCL (:pserver:[e-mail]:/cvsroot/jcl - Modul: jcl)

Schreiben
Das dürfen nur JVCL Entwickler. Und das kann man nur durch öftere Contributions und/oder Bugfixes werden.

[meierotto]

Zitat:

Lesen oder Schreiben?

Gut, lesen für CVS reicht mir :zwinker:

Zitat:

Mich würde mehr interessieren, welche Eigenschaften du umgestellt hast, so dass der Fehler auftritt.

Ich weiß im Moment nicht mehr welche Eigenschaften ich für den Wizard geändert hatte (ist schon ein Weilchen her), aber vielleicht löst es sich ja mit dem nächsten Update.

Kurz noch Out Of Topic: Wird beim Update via CVS eigentlich alles oder nur die installierten Komponenten überschrieben? Ich habe ein neueres UIB-Paket installiert und möchte nicht, dass es überschrieben wird.

Vielen Dank für die Hilfe

[jbg]

Zitat:

Zitat von meierotto

Kurz noch Out Of Topic: Wird beim Update via CVS eigentlich alles oder nur die installierten Komponenten überschrieben?

Das CVS Update aktualisiert alle Dateien die im JVCL Ordner sind. Persönlich aktualisiere ich immer nur \design, \common \run \packages \resources. "Alles" nur alle heilige Zeit mal, weil es einfach zu lange dauert.
Und das makemodified.bat kompiliert nur neu, ändert aber nicht die Registry-Werte.

Zitat:

Ich habe ein neueres UIB-Paket installiert und möchte nicht, dass es überschrieben wird.

So lange du das nicht in den JVCL Ordner schmeist, und keine Unit-Namen-Probleme auftreten, sollte da nichts passieren.