BriskBard, CEF4Delphi, WebView4Delphi, WebUI4Delphi and WebUI4CSharp

It´s taking a long time for the application to close when you have a reference to TDBNavigtor or TDBGrid.

To reproduce the problem, just add an instance of TDBNavigator or TDBGrid in the mainform of the SimpleBrowser demo app.
Start the application and close it. Now remove the control and do the same. You´ll see the shutdown time difference...

In fact it´s not necessary to create a instance of those classes. You just need to reference it so I believe that there is something incompatible inside one of those classes constructors/destructors in Vcl.DBCtrls. Debbuging the CEF component I found that "cef_shutdown" is taking a loooonnnngggg time to complete when you use one of these components.

Instead of creating an instance, you may force a reference to the class.

procedure TForm1.Button1Click(Sender: TObject);
begin
// you don´t neeed to execute this code!
// It´s just to create a reference to this class and force the compiler to initialize/finalize the class constructor/destructor.
// The incopatibility is not in the instance code but in the class constructor/destructor code.

TDBNavigator.Create(self).free;
end;

I using Delphi 10.4.2 and CEF 94.0.4606.61
Is there anything we can do besides using subprocess? Thanks a lot.

Hi,

Vcl.DBCtrls and several other units in that folder have a initialization and finalization section used to create some global instances needed for those controls.

Delphi executes all the initialization sections before executing the first code line in the DPR file and sometimes this can cause problems with the CEF subprocesses. This is specially important if those initialization sections include code that open some resource (file, ddbb, etc.) because all the CEF processes will try to open the same resource when they are created.

I haven't checked which initialization section is causing this slowdown but the easiest solution for this problem would be to use a different EXE for the CEF subprocesses.