Tja, das HandleNeeded hats leider nicht gebracht.
Du solltest auch konsequent darin sein, welche Komponente Du als Owner für im Kode erzeugte Komponenten verwendest. Das hat einen Einfluß darauf, in welcher Reihenfolge die Komponenten später zerstört werden. Versuch mal, immer das Hostform als Owner zu verwenden, vielleicht funktioniert das besser.
Normalerweise verwende ich schon immer wo es geht die Hostform als Owner. Im Falle von TabSheets ist es aber durchaus sinnvoll, allen darin enthaltenen Komponente als Owner dieses zu gehen. Wenn man dann das Tabscheet freigibt, werden alle darin enthaltenen Komponenten ebenfalls freigegeben.
Aber ich habe es auch mit Self probiert.
Falls Du den Fehler so nicht in den Griff bekommst könnte es notwendig sein, die Chromium-Komponenten explizit zu free-en, bevor das Form geschlossen wird. Du hast da eine ziemlich tiefe Staffelung von Controls, da kann die Sequenz des Abbaus etwas unintuitiv werden
Ja, das denke ich auch. Diese Art der Hierarchie der verschiedenen PageControls ist leider notwendig, um die benötigte Darstellung zu realisieren. Leider ist das Beispiel TabbedBrowser, was den Demos der CEF4 beiliegt stark darauf ausgelegt, dass es eben nur ein PageControl gibt. Ich habe bereits versucht, das dahingehend umzubauen, aber das endet in einem heillosen Durcheinander, da immer das passsende PageControl gesucht werden muss. Eine richtig gute Möglichkeit fällt mir da zur Zeit nicht ein.
Im Moment überlege ich, den ganzen Chromium in einer Klasse zu kapseln, und alle entsprechenden Events darin unterzubringen. Der Vorteil wäre, dass alle notwendigen Referenzen dann in der Klasse zu finden wären, und ein "SearchChromium" oder "SearchWindowParent" möglicherwiese entfallen bzw. einfacher zu händeln wären.