Print

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

[blaat]

Hi , having the weirdest problem. I am doing everything according to the simple instructions but the call to createinputobject halts my program. It is not throwing an exception either.

I'm suspecting its got something to do with my calls being in a DLL. But as I am not very experienced with DLL's yet I wouldnt really know where to look. The DLL I build is in in MultiThreadedDebug and im linking OIS_d.lib. Both the version shipped with Ogre as well as the latest OIS release act the same. Some pointers would be greatly appreciated as I'd love to use OIS.

Some code, just in case its one of those 5 hour overlooking problems :

Code: [Select]


size_t windowHnd = 0;

Ogre::Root::getSingletonPtr()->getAutoCreatedWindow()->getCustomAttribute("WINDOW",&windowHnd);

std::cout<<"HWND: " << windowHnd << "\n";
std::ostringstream stream;
stream << (unsigned int) windowHnd;

OIS::ParamList params;

params.insert(std::make_pair("WINDOW",stream.str()));

inputManager = OIS::InputManager::createInputSystem(params);
std::cout<<boards:"<<inputManager->numKeyBoards()<<"\n"; // giving 1

inputManager->createInputObject(OIS::OISKeyboard,true);



[pjcast]

Hmm, I can't think of ny reason why it would halt execution. What version of Ogre are you using... can you step into that OIS method and determine what line exactly is OIS stuck at. (Your code looks correct)

[blaat]

Hi , I'm using the latest Ogre Eihort from the site (so not cvs). I'll try to step when I get home.

[pjcast]

You only need OIS source to step through OIS, not Ogre source

[blaat]

Hi, yes yes I understood , just to answer the question about the ogre version

I stepped it thru , unless im doing something wrong it seems to be halting at this piece of code inside a file called xmtx.c. Which seems to be relating to a locking mechanism which could explain the halting the behaviour ( waiting for something) I suppose a shared section in my dll is possibly the cause ?

I'm using the shared section to share a singleton between dlls

Code: [Select]


void  __CLRCALL_PURE_OR_CDECL _Mtxlock(_Rmtx *_Mtx)
{ /* lock mutex */
#ifdef _M_CEE
System::Threading::Thread::BeginThreadAffinity();
#endif
EnterCriticalSection(_Mtx);
}

_RELIABILITY_CONTRACT
void  __CLRCALL_PURE_OR_CDECL _Mtxunlock(_Rmtx *_Mtx)
{ /* unlock mutex */
LeaveCriticalSection(_Mtx);
#ifdef _M_CEE
System::Threading::Thread::EndThreadAffinity();
#endif
}
 #endif /* !_MULTI_THREAD */


the shared section:

Code: [Select]



#pragma data_seg(".SHARED")

MainController mc = MainController();

#pragma data_seg()

#pragma comment(linker, "/section:.SHARED,RWS")


[pjcast]

Hmm, well, that is a wierd error. I've never played around with trying to use that shared stuff, and if I were you, I would find another way to do that. Ogre shares singletons between DLL's in a cross platform mannor that does not cause odd errors like this.

[OvermindDL1]

That is one major point of dll's. so you can init one thing once inside that dll's memory space (or just a pointer to where-ever it is made) and you can access it from any other loaded module, thus doing all that is greatly unwarrented.