Fix up NSSlider code to not use class posing and instantiate the proper type (now...

[wxWidgets.git] / include / wx / univ / inpcons.h

diff --git a/include/wx/univ/inpcons.h b/include/wx/univ/inpcons.h
index a099652da6db1fd9c22ad703ac996616af9a8a01..874d2f9e864a897c60478cea25ec39274ac77006 100644 (file)
--- a/include/wx/univ/inpcons.h
+++ b/include/wx/univ/inpcons.h
@@ -6,18 +6,14 @@
 // Created:     14.08.00
 // RCS-ID:      $Id$
 // Copyright:   (c) 2000 SciTech Software, Inc. (www.scitechsoft.com)
-// Licence:     wxWidgets licence
+// Licence:     wxWindows licence
 /////////////////////////////////////////////////////////////////////////////
 
 #ifndef _WX_UNIV_INPCONS_H_
 #define _WX_UNIV_INPCONS_H_
 
-#if defined(__GNUG__) && !defined(NO_GCC_PRAGMA)
-    #pragma interface "inpcons.h"
-#endif
-
-class WXDLLEXPORT wxInputHandler;
-class WXDLLEXPORT wxWindow;
+class WXDLLIMPEXP_FWD_CORE wxInputHandler;
+class WXDLLIMPEXP_FWD_CORE wxWindow;
 
 #include "wx/object.h"
 #include "wx/event.h"
@@ -35,7 +31,7 @@ typedef wxString wxControlAction;
 #define wxACTION_NONE    _T("")           // no action to perform
 
 // ----------------------------------------------------------------------------
-// wxInputConsumer: mix-in class for handling wxControlActions (used by 
+// wxInputConsumer: mix-in class for handling wxControlActions (used by
 // wxControl and wxTopLevelWindow).
 // ----------------------------------------------------------------------------
 
@@ -43,6 +39,7 @@ class WXDLLEXPORT wxInputConsumer
 {
 public:
     wxInputConsumer() { m_inputHandler = NULL; }
+    virtual ~wxInputConsumer() { }
 
     // get the input handler
     wxInputHandler *GetInputHandler() const { return m_inputHandler; }
@@ -63,6 +60,19 @@ public:
     // 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);
+
+
 protected:
     // event handlers
     void OnMouse(wxMouseEvent& event);
@@ -71,10 +81,12 @@ protected:
     void OnFocus(wxFocusEvent& event);
     void OnActivate(wxActivateEvent& event);
 
-    // create input handler by name
+    // create input handler by name, fall back to GetStdInputHandler() if
+    // the current theme doesn't define any specific handler of this type
     void CreateInputHandler(const wxString& inphandler);
 
-    // input processor (never deleted, the theme deletes it itself)
+private:
+    // the input processor (we never delete it)
     wxInputHandler *m_inputHandler;
 };
 
@@ -102,18 +114,18 @@ private:
     EVT_SET_FOCUS(classname::OnFocus) \
     EVT_KILL_FOCUS(classname::OnFocus) \
     EVT_ACTIVATE(classname::OnActivate)
-    
+
 // Forward event handlers to wxInputConsumer
 //
-// (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) \