简化Delphi应用的Chromium浏览器集成：CEF4Delphi

需积分: 46 113 浏览量更新于2024-07-18 1 收藏 2.73MB PDF 举报

"CEF4Delphi 是一个由 Salvador Díaz Fau 开发并开源的 Delphi 和 Lazarus/FPC 应用程序开发框架，其目标是简化在基于 Delphi 的应用中嵌入 Chromium 基础的浏览器的过程。这个项目源于 Henri Gourvest 的 DCEF3，但鉴于 DCEF3 在过去的几个月里没有更新，Salvador 决定创建 CEF4Delphi 以适应最新版本的 Chromium（特别指 2623 版本）。 CEF4Delphi 的核心在于提升与 Chromium 最新版的兼容性和易用性。为了实现这一目标，项目团队采取了以下关键步骤： 1. 减少冗余：将 OSRT Chromium 组件整合到 TChromium 类中，避免了重复代码和潜在的维护问题。 2. 精简代码：移除了来自 CEF3 的代码注释，因为 CEF3 的注释随代码更新频繁，开发者可以直接查阅 CEF3 的相关文件获取最新信息，而不是依赖于过时的注释。 3. 模块化设计：将代码拆分成多个小型单元，使得代码结构更加清晰，便于管理和扩展。 4. 类型和类的映射：提供了新的注释，帮助开发者理解 CEF4Delphi 中的类和类型与 CEF3 的对应关系，方便开发者在迁移项目时参考。 5. 最新版本支持：CEF4Delphi 的最新版本利用了最新的 Chromium 特性，确保了应用程序能够享受到最新的浏览器功能和性能优化。使用 CEF4Delphi 可以简化 Delphi 开发者的工作流程，让他们能够在不频繁更新底层库的情况下，快速集成高性能的浏览器功能到自己的应用程序中。这对于需要处理复杂 web 功能的桌面应用尤其有价值，因为它降低了技术门槛，提高了开发效率。然而，开发者仍需关注项目的更新频率，以确保与最新版 Chromium 的兼容性。"

MacOS/

cefclient <= cefclient application executable

Pkginfo

Resources/

binding.html, ... <= cefclient application resources

The "Chromium Embedded Framework.framework" is an unversioned framework that contains all CEF binaries and resources. Executables (cefclient, cefclient Helper,

etc) are linked to libcef.dylib using install_name_tool and a path relative to @executable_path.

The "cefclient Helper" app is used for executing separate processes (renderer, plugin, etc) with different characteristics. It needs to have a separate app bundle and

Info.plist file so that, among other things, it doesn’t show dock icons.

Application Structure

Every CEF3 application has the same general structure.



Provide an entry-point function that initializes CEF and runs either sub-process executable logic or the CEF message loop.



Provide an implementation of CefApp to handle process-specific callbacks.



Provide an implementation of CefClient to handle browser-instance-specific callbacks.



Call CefBrowserHost::CreateBrowser() to create a browser instance and manage the browser life span using CefLifeSpanHandler.

Entry-Point Function

As described in the “Processes” section a CEF3 application will run multiple processes. The processes can all use the same executable or a separate executable can be

specified for the sub-processes. Execution of the process begins in the entry-point function. Complete platform-specific examples for Windows, Linux and Mac OS-X

are available in cefclient/cefclient_win.cc, cefclient/cefclient_gtk.cc and cefclient/cefclient_mac.mm respectively.

When launching sub-processes CEF will specify configuration information using the command-line that must be passed into the CefExecuteProcess function via the

CefMainArgs structure. The definition of CefMainArgs is platform-specific. On Linux and Mac OS X it accepts the argc and argv values which are passed into the main()

function.

CefMainArgs main_args(argc, argv);

On Windows it accepts the instance handle (HINSTANCE) which is passed into the wWinMain() function. The instance handle is also retrievable via

GetModuleHandle(NULL).

CefMainArgs main_args(hInstance);

Single Executable

When running as a single executable the entry-point function is required to differentiate between the different process types. The single executable structure is

supported on Windows and Linux but not on Mac OS X.

// Program entry-point function.

int main(int argc, char* argv[]) {

// Structure for passing command-line arguments.

// The definition of this structure is platform-specific.

CefMainArgs main_args(argc, argv);

// Optional implementation of the CefApp interface.

CefRefPtr<MyApp> app(new MyApp);

// Execute the sub-process logic, if any. This will either return immediately for the browser

// process or block until the sub-process should exit.

int exit_code = CefExecuteProcess(main_args, app.get());

if (exit_code >= 0) {

// The sub-process terminated, exit now.

return exit_code;

}

// Populate this structure to customize CEF behavior.

CefSettings settings;

// Initialize CEF in the main process.

CefInitialize(main_args, settings, app.get());

// Run the CEF message loop. This will block until CefQuitMessageLoop() is called.

CefRunMessageLoop();

// Shut down CEF.

CefShutdown();

return 0;

}

Separate Sub-Process Executable

When using a separate sub-process executable you need two separate executable projects and two separate entry-point functions.

Main application entry-point function:

// Program entry-point function.

int main(int argc, char* argv[]) {

// Structure for passing command-line arguments.

// The definition of this structure is platform-specific.

CefMainArgs main_args(argc, argv);

// Optional implementation of the CefApp interface.

CefRefPtr<MyApp> app(new MyApp);

// Populate this structure to customize CEF behavior.

CefSettings settings;

// Specify the path for the sub-process executable.

CefString(&settings.browser_subprocess_path).FromASCII(“/path/to/subprocess”);

// Initialize CEF in the main process.

CefInitialize(main_args, settings, app.get());

// Run the CEF message loop. This will block until CefQuitMessageLoop() is called.

CefRunMessageLoop();

// Shut down CEF.

CefShutdown();

return 0;

}

Sub-process application entry-point function:

// Program entry-point function.

int main(int argc, char* argv[]) {

// Structure for passing command-line arguments.

// The definition of this structure is platform-specific.

CefMainArgs main_args(argc, argv);

// Optional implementation of the CefApp interface.

CefRefPtr<MyApp> app(new MyApp);

// Execute the sub-process logic. This will block until the sub-process should exit.

return CefExecuteProcess(main_args, app.get());

}

Message Loop Integration

CEF can also integrate with an existing application message loop instead of running its own message loop. There are two ways to do this.

Call CefDoMessageLoopWork() on a regular basis instead of calling CefRunMessageLoop(). Each call to CefDoMessageLoopWork() will perform a single iteration of the

CEF message loop. Caution should be used with this approach. Calling the method too infrequently will starve the CEF message loop and negatively impact browser

performance. Calling the method too frequently will negatively impact CPU usage.

Set CefSettings.multi_threaded_message_loop = true (Windows only). This will cause CEF to run the browser UI thread on a separate thread from the main application

thread. With this approach neither CefDoMessageLoopWork() nor CefRunMessageLoop() need to be called. CefInitialize() and CefShutdown() should still be called on

the main application thread. You will need to provide your own mechanism for communicating with the main application thread (see for example the message window

usage in cefclient_win.cpp). You can test this mode in cefclient on Windows by running with the “--multi-threaded-message-loop” command-line flag.

CefSettings

The CefSettings structure allows configuration of application-wide CEF settings. Some commonly configured members include:



browser_subprocess_path The path to a separate executable that will be launched for sub-processes. See the “Separate Sub-Process Executable” section for more

information.



multi_threaded_message_loop Set to true to have the browser process message loop run in a separate thread. See the “Message Loop Integration” section for more

information.



command_line_args_disabled Set to true to disable configuration of browser process features using standard CEF and Chromium command-line arguments. See the

“Command Line Arguments” section for more information.



cache_path The location where cache data will be stored on disk. If empty an in-memory cache will be used for some features and a temporary disk cache will be

used for others. HTML5 databases such as localStorage will only persist across sessions if a cache path is specified.



locale The locale string that will be passed to Blink. If empty the default locale of "en-US" will be used. This value is ignored on Linux where locale is determined using

environment variable parsing with the precedence order: LANGUAGE, LC_ALL, LC_MESSAGES and LANG. Also configurable using the "lang" command-line switch.



log_file The directory and file name to use for the debug log. If empty, the default name of "debug.log" will be used and the file will be written to the application

directory. Also configurable using the "log-file" command-line switch.



log_severity The log severity. Only messages of this severity level or higher will be logged. Also configurable using the "log-severity" command-line switch with a

value of "verbose", "info", "warning", "error", "error-report" or "disable".



resources_dir_path The fully qualified path for the resources directory. If this value is empty the cef.pak and/or devtools_resources.pak files must be located in the

module directory on Windows/Linux or the app bundle Resources directory on Mac OS X. Also configurable using the "resources-dir-path" command-line switch.



locales_dir_path The fully qualified path for the locales directory. If this value is empty the locales directory must be located in the module directory. This value is

ignored on Mac OS X where pack files are always loaded from the app bundle Resources directory. Also configurable using the "locales-dir-path" command-line

switch.



remote_debugging_port Set to a value between 1024 and 65535 to enable remote debugging on the specified port. For example, if 8080 is specified the remote

debugging URL will be http://localhost:8080. CEF can be remotely debugged from any CEF or Chrome browser window. Also configurable using the "remote-

debugging-port" command-line switch.

CefBrowser and CefFrame

The CefBrowser and CefFrame objects are used for sending commands to the browser and for retrieving state information in callback methods. Each CefBrowser

object will have a single main CefFrame object representing the top-level frame and zero or more CefFrame objects representing sub-frames. For example, a browser

that loads two iframes will have three CefFrame objects (the top-level frame and the two iframes).

To load a URL in the browser main frame:

browser->GetMainFrame()->LoadURL(some_url);

To navigate the browser backwards:

browser->GoBack();

To retrieve the main frame HTML contents:

// Implementation of the CefStringVisitor interface.

class Visitor : public CefStringVisitor {

public:

Visitor() {}

// Called asynchronously when the HTML contents are available.

virtual void Visit(const CefString& string) OVERRIDE {

// Do something with |string|...

}

IMPLEMENT_REFCOUNTING(Visitor);

};

browser->GetMainFrame()->GetSource(new Visitor());

CefBrowser and CefFrame objects exist in both the browser process and the render process. Host behavior can be controlled in the browser process via the

CefBrowser::GetHost() method. For example, the native handle for a windowed browser can be retrieved as follows:

// CefWindowHandle is defined as HWND on Windows, NSView* on Mac OS X

// and GtkWidget* on Linux.

CefWindowHandle window_handle = browser->GetHost()->GetWindowHandle();

Other methods are available for history navigation, loading of strings and requests, sending edit commands, retrieving text/html contents, and more. See the

documentation for the complete list of supported methods.

CefApp

The CefApp interface provides access to process-specific callbacks. Important callbacks include:



OnBeforeCommandLineProcessing which provides the opportunity to programmatically set command-line arguments. See the “Command Line Arguments” section

for more information.



OnRegisterCustomSchemes which provides an opportunity to register custom schemes. See the “”Request Handling” section for more information.



GetBrowserProcessHandler which returns the handler for functionality specific to the browser process including the OnContextInitialized() method.



GetRenderProcessHandler which returns the handler for functionality specific to the render process. This includes JavaScript-related callbacks and process messages.

See the JavaScriptIntegration Wiki page and the “Inter-Process Communication” section for more information.

An example CefApp implementation can be seen in cefsimple/simple_app.h and cefsimple/simple_app.cc.

CefClient

The CefClient interface provides access to browser-instance-specific callbacks. A single CefClient instance can be shared among any number of browsers. Important

callbacks include:



Handlers for things like browser life span, context menus, dialogs, display notifications, drag events, focus events, keyboard events and more. The majority of handlers

are optional. See the documentation in cef_client.h for the side effects, if any, of not implementing a specific handler.



OnProcessMessageReceived which is called when an IPC message is received from the render process. See the “Inter-Process Communication” section for more

information.

An example CefClient implementation can be seen in cefsimple/simple_handler.h and cefsimple/simple_handler.cc.

Browser Life Span

Browser life span begins with a call to CefBrowserHost::CreateBrowser() or CefBrowserHost::CreateBrowserSync(). Convenient places to execute this logic include the

CefBrowserProcessHandler::OnContextInitialized() callback or platform-specific message handlers like WM_CREATE on Windows.

// Information about the window that will be created including parenting, size, etc.

// The definition of this structure is platform-specific.

CefWindowInfo info;

// On Windows for example...

info.SetAsChild(parent_hwnd, client_rect);

// Customize this structure to control browser behavior.

CefBrowserSettings settings;

// CefClient implementation.

CefRefPtr<MyClient> client(new MyClient);

// Create the browser asynchronously. Initially loads the Google URL.

CefBrowserHost::CreateBrowser(info, client.get(), “http://www.google.com”, settings, NULL);

The CefLifeSpanHandler class provides the callbacks necessary for managing browser life span. Below is an extract of the relevant methods and members.

class MyClient : public CefClient,

public CefLifeSpanHandler,

... {

// CefClient methods.

virtual CefRefPtr<CefLifeSpanHandler> GetLifeSpanHandler() OVERRIDE {

return this;

}

// CefLifeSpanHandler methods.

void OnAfterCreated(CefRefPtr<CefBrowser> browser) OVERRIDE;

bool DoClose(CefRefPtr<CefBrowser> browser) OVERRIDE;

void OnBeforeClose(CefRefPtr<CefBrowser> browser) OVERRIDE;

剩余59页未读，继续阅读

jl303304

粉丝: 1
资源: 4

简化Delphi应用的Chromium浏览器集成：CEF4Delphi

cef_binary_3.3071.1611.g4a19305_windows64.rar

CEF4Delphi包括VCL、FireMonkey（FMX）和Lazarus组件

MFC通过CEF封装Chrome浏览器内核

CEF4Delphi-master.zip_CEF4Delphi_cef4_delphi cef4_panu85

CEF4Delphi-master.zip_CEF4Delphi_chromium_delphi_delphi Chromium

CEF4Delphi-master.zip_CEF -4_CEF+delphi_DCef3_cef delphi_delphi

CEF4Delphi-master.zip_CEF_CEF4Delphi_chromium_delphi Cefv8_want1

CEF4Delphi

CEF4Delphi200524

CEF4Delphi控件

最新资源