3 The intent of this plugin is to demonstrate how to implement a
4 "real", native control as a plugin.
6 This sample shows how a plugin can sit "nicely" with the Mozilla event
7 framework - for example, getting and losing focus, and allowing keyboard,
8 mouse and resize events to be either consumed or passed on at the
11 In this sample, we create a standard "edit" control using the
12 platform's native edit widget. Obviously if you really needed a simple
13 edit control, you would use a standard HTML or XUL widget - but a native
14 edit control was chosen for this demonstration as it is generally a simple
15 native widget, and allows us to concentrate on the event interaction.
19 A standard Windows edit control is created and subclassed. All keyboard and
20 mouse messages are passed back to Mozilla itself rather than passed to the
21 edit control. These messages then wind themselves back around the event
22 framework, and end up as calls to nsIPlugin::HandleEvent() calls.
24 If we let the keyboard messages go directly to the edit control,
25 we have no way of allowing the keystrokes we _dont_ want to be passed back. If
26 we let the mouse messages go directly to the control, we don't interact correctly
30 * Plugins on Windows don't have event messages.
31 * Plugins on Windows don't have key-pressed messages (only keyup and down)
32 * Focus interaction is not correct (probably need a focus event)
37 A standard Gtk edit control is used.
40 * Focus has problems. If you click in the plugin window, then click in the
41 HTML edit widget, you get cursors in both places. Typing is still directed
42 at the plugin, even though focus was just set to the HTML widget. Using the
43 TAB key to change focus yields better results.