Handling Input Events

When an input event occurs inside the web page, it not only triggers events inside the web page, but also triggers the corresponding events in the host application. This section describes the manner these events are triggered and how to customize the event flow.

Event Order

When user input occurs inside the web page in an EO.Wpf.WebControl or EO.WinForms.WebControl, the corresponding input events are raised on multiple objects in the following order:

  1. First Stage: Platform Specific Host Application Events

    Events are first raised for controls/objects in the host application in a platform specific manner --- depending on whether the Windows Form version of the WebControl class or the WPF version of the WebControl is used. For example, when user presses down a key inside a WebControl:

    • In a WPF application (thus the WPF version of the WebControl is used), then this key down event would first trigger a PreviewKeyDown tunneling event that travels from the Window object down to the WebControl, then trigger a KeyDown bubbling event that travels from the WebControl back to the Window.

      Note that certain events do not bubble up from the WebControl. For example, MouseWheel event does not bubble from the WebControl up. This is to avoid both the web page and the containing control (such as a ScrollViewer) responding mouse wheel event and cause double scrolling.

    • In a Windows Form application (thus the Windows Forms version of the WebControl is used), then this key down event usually would trigger the WebControl's KeyDown event directly. However it will also go through other Windows Form event handling mechanism. For example, if it matches a menu item shortcut, then that menu item's Click event will be triggered instead.

    An event may be "consumed" during this stage. For example, shortcut for menu item will consume the specific keyboard combination thus prevents such keyboard events from reaching the next stage. In WPF, Any preview events that are marked as handled will also not reach the next stage.

  2. Second Stage: Platform Neutral WebView

    After the event travel through the first stage and if it is not consumed, it will reach the WebView class. This class is platform neutral. It exposes a set of events whose behavior do not change regardless whether Windows Forms or WPF is used. If you wish to handle event in platform neutral manner, you can use events on this class instead.

  3. Third Stage: Web page

    After the corresponding events are raised in the first and second stage, it will reach the web page and be processed by the browser engine. JavaScript event handler will be triggered in this stage.

Custom Input Filter

You can implement IInputMsgFilter to customize the above event flow. The following example demonstrates how to prevent F10 from reaching the application. By default, pressing F10 activates the menu. The following code disables this behavior by preventing F10 event from reaching the host application.

//Implements IInputMsgFilter to filter input message
class InputMsgFilter: IInputMsgFilter
{
    private const int WM_SYSKEYDOWN = 0x105;
    private const int VK_F10 = 0x79;

    //Intercept F10 key and bypass the normal message processing
    //flow for this message
    public InputMsgTarget PreDispatchMsg(int Msg, IntPtr wParam, IntPtr lParam)
    {
        if ((Msg == WM_SYSKEYDOWN) && (wParam.ToInt32() == VK_F10))
            return InputMsgTarget.None;
            
        return InputMsgTarget.Application;
    }
}

//Install the input message filter
webView.InputMsgFilter = new InputMsgFilter();