some shortcomings on assigning events after creation

[salvadordf]

Hi,

If you need to assign events after the browser creation create a new class that inherits from TChromium and override the following functions :

• MustCreateLoadHandler
• MustCreateFocusHandler
• MustCreateContextMenuHandler
• MustCreateDialogHandler
• MustCreateKeyboardHandler
• MustCreateDisplayHandler
• MustCreateDownloadHandler
• MustCreateJsDialogHandler
• MustCreateDragHandler
• MustCreateFindHandler
• MustCreateAudioHandler

Set the returned value to True and the handlers will be created even if you don't use any of its events.

CEF applications usually create handlers only when really needed because creating some of them can decrease the performance of your app and in general it's more efficient.

For example, the audio handler triggers its events many times per second even when there's no sound and that means one CPU core is constantly working.

[salvadordf]

CEF checks what handlers are available only once when the browser is initializing.
It saves that handler reference and uses it until the browser is destroyed.

If we create a handler when the browser is already initialized it won't be used and the events won't be triggered.

[salvadordf]

You're right. CEF calls the functions to get the custom handlers more than once for most of them. I should've check all of them before stating that CEF only checks them once.

However, I'm still reluctant to accept those code changes because that's an unexpected behavior for the CEF libraries.

The official samples create a Client class which only implements the handlers that they need :
https://bitbucket.org/chromiumembedded/ ... h#lines-28
https://bitbucket.org/chromiumembedded/ ... h#lines-57

That class returns "this" (equivalent to "self" in Delphi) every time CEF checks if a custom handler is available. The client class is used to create the browser and it's not modified while the browser is alive.

This may seem an unusual reason to accept or decline code changes but my experience fixing CEF4Delphi bugs in the last 2 years made me realize that many issues are caused by Delphi code that do something in a different way than the official CEF applications.

This is an old example : CEF4Delphi used to create all the handlers in TCustomClientHandler just in case an event was assigned after the browser creation. That seemed to work fine but then CEF 3.3239.1700.g385b2d4 was released with a bug in the JS Dialogs handler.
https://www.briskbard.com/forum/viewtopic.php?f=8&t=234

That bug caused many more crashes in CEF4Delphi than other wrappers because we were always creating the JS Dialogs handler.

Some other shutdown crashes and memory leaks were also caused by Delphi code releasing interfaces differently than the official CEF application. TCustomClientHandler, TCefApplication, TChromium and many other classes have been modified several times for that reason.

I'm sorry but I have to suggest you to create a your own custom classes inheriting from TChromium and TCefClientOwn. You would only need to add a new procedure to create the browser using your own client handler.