Enhancement: Windows Message Callback

[GoogleCodeExporter]

Patch adds a callback when a windows message is recieved

Original issue reported on code.google.com by lodle...@gmail.com on 5 Sep 2010 at 8:41

Attachments:

• winproc_101_cef.patch

[GoogleCodeExporter]

What kinds of messages are you listening for? What is your use case for this?

Original comment by magreenb...@gmail.com on 6 Sep 2010 at 6:59

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Mouse and keyboard events

Original comment by lodle...@gmail.com on 7 Sep 2010 at 7:08

[GoogleCodeExporter]

    if (message == WM_XBUTTONDOWN)
    {
        int fwButton = GET_XBUTTON_WPARAM(wparam);

        if (fwButton == XBUTTON1)
            browser->GoBack();
        else if (fwButton == XBUTTON2)
            browser->GoForward();
    }

Original comment by lodle...@gmail.com on 7 Sep 2010 at 9:19

[GoogleCodeExporter]

Let's make sure we completely understand how Windows message routing is 
occurring in WebViewHost and WebWidgetHost.

1. WebViewHost extends WebWidgetHost. WebViewHost instances are used for 
browser windows. WebWidgetHost instances are used for popup menus via 
WebViewClient::createPopupMenu().
2. WebViewHost and WebWidgetHost both use the static 
WebWidgetHost::WndProc(HWND,UINT,WPARAM,LPARAM) method as the WndProc for their 
respective registered window classes.
3. WebWidgetHost::WndProc(HWND,UINT,WPARAM,LPARAM) handles messages only if the 
virtual WndProc(UINT,WPARAM,LPARAM) method returns false.
4. The virtual method for WebViewHost always returns false.
5. The virtual method for WebWidgetHost closes the window when an WM_ACTIVATE 
message of type WA_INACTIVE is received and otherwise returns false.

So, there are a few problems with your patch.

1. The virtual WebViewHost::WndProc method should not call 
WebWidgetHost::WndProc.
2. The virtual WebViewHost::WndProc method should always return false or 
something important might not happen in 
WebWidgetHost::WndProc(HWND,UINT,WPARAM,LPARAM).

Original comment by magreenb...@gmail.com on 23 Sep 2010 at 4:53

[GoogleCodeExporter]

I think it is very useful to export HandleWndProc interface to user.

Original comment by ShenHui...@gmail.com on 20 Apr 2011 at 1:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have a customized version of CEF with the support for the Chromium 
MessagePumpWin::Dispatcher like interface that handles window messages. You can 
pass this interface in the CefDoMessageLoopWork/CefRunMessageLoop.
Should I put a patch here?

Original comment by igor.ara...@gmail.com on 20 Apr 2011 at 9:03

[GoogleCodeExporter]

Go for it

Original comment by lodle...@gmail.com on 21 Apr 2011 at 1:16

[GoogleCodeExporter]

Here it is. Please include it in the trunk.

Original comment by igor.ara...@gmail.com on 21 Apr 2011 at 10:54

Attachments:

• msg_dispatcher.patch

[GoogleCodeExporter]

@comment#9:

I would consider your patch for inclusion with the following changes:

1. CefMsgDispatcher should extend CefBase and use CefRefPtr as with all other 
CEF classes.

2. Define a CefMsgHandle type in cef_types_*.h platform files and use that as 
the argument to Dispatch() instead of "struct Msg {}".

3. Dispatch is only supported on Windows and some versions of Linux. The 
related functionality needs to be placed behind a platform guard so that it 
compiles correctly and people don't try to use it on other platforms. The best 
way to do this is likely with separate CefDoMessageLoopWork() an 
CefRunMessageLoop() functions. The cef_parser.py tool will need to be updated 
to understand this concept.

Original comment by magreenb...@gmail.com on 21 Apr 2011 at 7:02

[GoogleCodeExporter]

1. I don't agree. The CefMsgDispatcher is just an interface for users, it's not 
a CEF object and it's never stored in the CEF internals. So the refcounting is 
useless for it. And it's wrong to extend the project's ideology so deep in the 
space of the user's application.

2. Ok, I will try tomorrow.

3. I don't have access to the Linux/Mac environment to test it. Anyway, the 
CefMsgDispatcher is completly optional. By default all should work as usual 
(except c-api). Maybe some minor modifications would be needed. Anybody want to 
help with this part?

Original comment by igor.ara...@gmail.com on 21 Apr 2011 at 7:53

[GoogleCodeExporter]

@comment#11:

You're correct that in this particular case reference counting isn't strictly 
necessary. However, all CEF interfaces follow a consistent style that extends 
CefBase. The use of reference counting is an intentional design choice to 
enforce a contract with the user. This contract states that all objects will be 
implicitly deleted when no longer needed. By using raw pointers and bypassing 
the C/C++ translation layer you are breaking this contract and introducing 
inconsistencies in the API that make it harder for both the maintainers of this 
project and for the users.

Original comment by magreenb...@gmail.com on 21 Apr 2011 at 8:17

[GoogleCodeExporter]

1,2 - Done.

Original comment by igor.ara...@gmail.com on 22 Apr 2011 at 12:41

Attachments:

• msg_dispatcher.patch

[GoogleCodeExporter]

I've updated patch for CEF r514.

Original comment by igor.ara...@gmail.com on 5 Mar 2012 at 9:59

Attachments:

• base_msg_dispatcher.patch
• cef_msg_dispatcher.patch

[GoogleCodeExporter]

CEF1 has entered bug-fix-only maintenance mode. See 
http://magpcss.org/ceforum/viewtopic.php?f=10&t=10647 for details. If this 
issue applies to the current version of CEF3 please create a new issue.

Original comment by magreenb...@gmail.com on 11 Oct 2013 at 1:48

• Changed state: WontFix