Rank: Advanced Member Groups: Member
Joined: 2/11/2015 Posts: 122
|
With the latest version of EO.WebBrowser IInputMsgFilter was introduced
I wanted to know if creating an Implementation of this where you always return InputMsgTarget.WebView, does that basically put you on the old Event Model?
If it doesn't, but is close, is it possible to explain the differences between the old model and this new setup that mimics it?
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,218
|
Hi,
Returning WebView from IInputMsgFilter is the closest you can get to the behavior of the previous version, but they are not exactly the same.
In the previous version when the browser engine receives an input message, it does NOT route this message through the host application. Instead it duplicates the message and sends a copy to the host application. This works fine most of the time because:
1. The original copy is still processed by the browser engine as if no host application existed. So there is practically no impact on how things occurs inside the browser engine; 2. The duplicate copy that is sent to the host application usually dead end on the host application's WebControl class and does nothing; 3. The duplicate copy while usually does nothing by default, it is used to trigger input events (such as MouseDown) on the WebControl/WebView class so that your application get a chance to respond to these events. A "side effect" of this is that it can also trigger certain application wide events such as menu items, which is in fact desired;
Needless to say this approach has problems. there are two main issues with this approach:
1. There is no way for the host application to consume a message and prevent it from reaching the browser engine's default input handler; 2. The duplicate copy can cause the same input to appear on both side. For example, while pressing a menu item's mnemonic key would trigger the menu item (which is desired), the same letter also appears in the web page (which is not desired);
The new version attempts to address these issues by giving the host application a chance to respond to every input message first and ability to consume it. This includes your custom IInputMsgFilter as well as the built-in Windows Forms/WPF input handling mechanism. The message will only travel back to the browser engine if it is not consumed during this stage. So no duplication occurs in the current version. When you return WebView from IInputMsgFilter, you chose to send this message right back to the browser engine. In theory this should be better than what the old version does.
Of course as you have already discovered nothing is perfect, especially at the beginning mistakes/overlooks almost surely always happen. What we are doing here is to catch them and address them as fast as we can (with your help of course).
Hope this gives you a good idea of what has been changed. Please feel free to ask if you still have any more questions.
Thanks!
|