How to override Render's wndProc

[salvadordf]

Have you tried adding an Application.OnMessage event to the subprocess where GlobalCEFApp.ProcessType is ptRenderer ?

[salvadordf]

I'm sorry.

I totally forgot that subprocesses don't execute "Application.Run" and you can't use the Application.OnMessage to intercept all the messages sent to that process.

[salvadordf]

The easiest way to intercept all those messages is to use the OSR mode.

In normal mode you can create a hook with SetWindowsHookEx to intercept mouse or keyboard messages :
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

I don't know the Blink implementation details and I don't know why your WndProc relacement has some problems.

[salvadordf]

I've never replaced a WndProc before but remember that you are replacing a WndProc from a different process.
Perhaps the reason why it has problems with events is that the old WndProc points to a function in a different process address space.

https://gopherproxy.meulie.net/sdf.org/ ... /ch22b.htm

[salvadordf]

In normal mode you can create a hook with SetWindowsHookEx to intercept mouse or keyboard messages :
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

Thanks for the advice but the hook isn't a good solution because it required a very high perfomance.

I use one in BriskBard to handle the web browser zoom when the user clicks control and moves the wheel mouse button.
There's no problem if you just send a custom message with all the information to your form and return immediately after that.

[salvadordf]

It's a low level mouse hook (WH_MOUSE_LL) and it needs to be global to receive the mouse messages for different processes.

This solution has been suggested several times in the official CEF forum to receive the missing mouse and keyboard events.

[salvadordf]

I think It may call unexpected erros. But if I only send a message there, maybe, it will work well. Honestly, I don't know, but all these functions can be debugged, i mean wndProcBrowser, wndProcWidget, wndProcRender. But why? I don't understand it completely, if it's a different process i can't debug it from delphi debugger, isn't it?
All these functions is called by CrBrowserMain thread.

If I understood it correctly, SetWindowLongPtr returns the old WndProc address but that address is meaningless if it comes from a different process address space.

The author in the last link states that it's still possible to do this by "injecting" a DLL into a process's address space but I wouldn't be surprised if this is seen as a threat by antivirus software.

I think it's much easier to use a simple hook.

[salvadordf]

You were right!

Reading your posts more carefully I realized I was talking about the render process when you were talking about the message loops in some components created by the CEF libraries.

I'll see if I can add your code to TChromium and TFMXChromium. This could be used to expose "OnMessage" events!

[salvadordf]

Hi,

There are many code examples in Internet. Just search "delphi setwindowshookex example" and you will find examples like these :

http://lazplanet.blogspot.com/2016/06/h ... -your.html
http://www.delphipages.com/forum/showthread.php?t=32700

When you detect a mouse wheel event you can send a custom message to your app to call TChromium.IncZoomStep or TChromium.DecZoomStep

[salvadordf]

I use it from a thread and I try to process the messages as fast as I can to call CallNextHookEx before the OS thinks that my app is not responding fast enough and removes my hook from the chain.

Read this :
https://docs.microsoft.com/en-us/window ... nmsg/hooks
https://docs.microsoft.com/en-us/window ... owshookexw
https://msdn.microsoft.com/en-us/librar ... s.85).aspx