Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rackle]

I've mentioned in another thread my desire for a way to retrieve devices from the input manager.  This is important when subclassing the Windows message loop to respond to some operating system inputs.  Previously I had to resort to a static variable to retrieve the mouse.  Here's what I changed:

OISInputManager.h
before #include "OISPrereqs.h
#include <vector>

public:
virtual Object* getDevice(Type iType, int iID);

protected
//List to hold the various instances of the devices
std::vector<Object*> mouseDevices;
std::vector<Object*> keyboardDevices;
std::vector<Object*> joystickDevices;

OISInputManager.cpp
at the end of the file
Object* InputManager::getDevice(Type iType, int iID)
{
   // These .at() functions throw an stl out of range exception
   switch( iType )
   {
      case OISKeyboard:
         return keyboardDevices.at(iID);
      case OISMouse:
         return mouseDevices.at(iID);
      case OISJoyStick:
         return joystickDevices.at(iID);
   }

   return NULL;
}

win32InputManager.cpp
within Object* Win32InputManager::createInputObject( Type iType, bool bufferMode ), before return obj;
   switch( iType )
   {
      case OISKeyboard:   keyboardDevices.push_back(obj); break;
      case OISMouse:      mouseDevices.push_back(obj);   break;
      case OISJoyStick:   joystickDevices.push_back(obj); break;
   }

within Object* Win32InputManager::destroyInputObject( Object* obj ), before delete obj;
   // Remove the device from the appropriate list of devices
   switch( obj->type() )
   {
      case OISKeyboard:
         {
            std::vector<Object*>::iterator it;
            for (it = keyboardDevices.begin(); it != keyboardDevices.end(); ++it)
            {
               if(*it == obj)
               {
                  keyboardDevices.erase(it);
                  break;
               }
            }
         }
         break;
      case OISMouse:
         {
            std::vector<Object*>::iterator it;
            for (it = mouseDevices.begin(); it != mouseDevices.end(); ++it)
            {
               if(*it == obj)
               {
                  mouseDevices.erase(it);
                  break;
               }
            }
         }
         break;
      case OISJoyStick:
         {
            std::vector<Object*>::iterator it;
            for (it = joystickDevices.begin(); it != joystickDevices.end(); ++it)
            {
               if(*it == obj)
               {
                  joystickDevices.erase(it);
                  break;
               }
            }
         }
         break;
   }



So far this works nicely within my message loop.  The code within Win32InputManager::destroyInputObject() looks iffy to me; it is not pretty.

I've destroyed the current mouse and created a new one, in an attempt to test my implementation of the vector of mouse devices with this code:

bool keyPressed( const OIS::KeyEvent &arg )
{
if( arg.key == OIS::KC_E )
      {
         OIS::InputManager* im = OIS::InputManager::getSingletonPtr();
         im->destroyInputObject(mMouse);
         mMouse = NULL;
         mMouse = static_cast<OIS::Mouse*>(im->createInputObject( OIS::OISMouse, true ));
         mMouse->setEventCallback(this);
      }
      return true;
   }

My vector seems to work.  I can press another key to release/unacquire the mouse and when I click I reacquire the mouse, from within my message handler, I can reacquire the mouse.

What do you think of this?

[pjcast]

I'll have to look more thoroughly at the code changes you posted.. Though, for a quick reply right now (gotta get a paper written tonite), I do not really want to maintain a list of the created Input Devices (I do in the case of JoySticks, for various reasons.. but not really by choice). My reasoning is the same as not wanting to have multiple Event Listeners per device.. It complicates the removal process when you are removing the same device from the callback event (ie.. in response to a keypress). As far as the static variable for the Win32 WinProc, I state in the other thread, that my intents on the new OIS WinProc (and other OS wrapper) class was to completely take over the event procedure. So, it will hold it's own data in the custom data area (probably a pointer to the Win32InputManager). It will also call your Window Listener, so you do not need to do any fudgery yourself :wink: - at least, in theory, this sounds like it will work to me?

Also, in regards to the mouse aquire stuff, I do not want to make any of these changes until the next version... I want to get version 0.4.0 out the door this weekend first (Includes numerous bug Fixes and FF Support). Then, for 0.5.0 will be looking at adding the Win32 Message Loop wrapper class for better handling of Dead Key combinations.. and add some of the mouse changes you out in your patch - acquire being the main.

[Rackle]

Yeah, having an OS message handler/listener would allow me to access the mMouse variable directly rather than going through a device list.

>> some of the mouse changes you out in your patch - acquire being the main.

acquire() is the only good thing in that patch.  The rest was the override of the message handler in order to receive notifications of events which then call this acquire() function.  This would be rewritten in the OS listener.  My patch listed the relevant messages.