#define wxACTION_NONE _T("") // no action to perform
// ----------------------------------------------------------------------------
#define wxACTION_NONE _T("") // no action to perform
// ----------------------------------------------------------------------------
// wxControl and wxTopLevelWindow).
// ----------------------------------------------------------------------------
class WXDLLEXPORT wxInputConsumer
{
public:
// wxControl and wxTopLevelWindow).
// ----------------------------------------------------------------------------
class WXDLLEXPORT wxInputConsumer
{
public:
// get the window to work with (usually the class wxInputConsumer was mixed into)
virtual wxWindow *GetInputWindow() const = 0;
// get the window to work with (usually the class wxInputConsumer was mixed into)
virtual wxWindow *GetInputWindow() const = 0;
+ // this function must be implemented in any classes process input (i.e. not
+ // static controls) to create the standard input handler for the concrete
+ // class deriving from this mix-in
+ //
+ // the parameter is the default input handler which should receive all
+ // unprocessed input (i.e. typically handlerDef is passed to
+ // wxStdInputHandler ctor) or it may be NULL
+ //
+ // the returned pointer will not be deleted by caller so it must either
+ // point to a static object or be deleted on program termination
+ virtual wxInputHandler *DoGetStdInputHandler(wxInputHandler *handlerDef);
+
+
EVT_SET_FOCUS(classname::OnFocus) \
EVT_KILL_FOCUS(classname::OnFocus) \
EVT_ACTIVATE(classname::OnActivate)
EVT_SET_FOCUS(classname::OnFocus) \
EVT_KILL_FOCUS(classname::OnFocus) \
EVT_ACTIVATE(classname::OnActivate)
-// (We can't use them directly, because wxIC has virtual methods, which forces
-// the compiler to include (at least) two vtables into wxControl, one for the
-// wxWindow-wxControlBase-wxControl branch and one for the wxIC mix-in.
-// Consequently, the "this" pointer has different value when in wxControl's
-// and wxIC's method, even though the instance stays same. This doesn't matter
-// so far as member pointers aren't used, but that's not wxControl's case.
-// When we add an event table entry (= use a member pointer) pointing to
-// wxIC's OnXXX method, GCC compiles code that executes wxIC::OnXXX with the
-// version of "this" that belongs to wxControl, not wxIC! In our particular
+// (We can't use them directly, because wxIC has virtual methods, which forces
+// the compiler to include (at least) two vtables into wxControl, one for the
+// wxWindow-wxControlBase-wxControl branch and one for the wxIC mix-in.
+// Consequently, the "this" pointer has different value when in wxControl's
+// and wxIC's method, even though the instance stays same. This doesn't matter
+// so far as member pointers aren't used, but that's not wxControl's case.
+// When we add an event table entry (= use a member pointer) pointing to
+// wxIC's OnXXX method, GCC compiles code that executes wxIC::OnXXX with the
+// version of "this" that belongs to wxControl, not wxIC! In our particular
// case, the effect is that m_handler is NULL (probably same memory
// area as the_other_vtable's_this->m_refObj) and input handling doesn't work.)
#define WX_FORWARD_TO_INPUT_CONSUMER(classname) \
// case, the effect is that m_handler is NULL (probably same memory
// area as the_other_vtable's_this->m_refObj) and input handling doesn't work.)
#define WX_FORWARD_TO_INPUT_CONSUMER(classname) \