Jump to content
  • Advertisement
Sign in to follow this  
Anri

A higher priority app preventing acquire and restore?

This topic is 5414 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm having trouble setting up DirectInput. With DirectInput( I'm using Directx9 ), I can initialize the interface alright without any errors returned. So I can only assume that there is nothing wrong in that department. But during my basic "Game loop", I attempt to retrieve keyboard data via ->GetDeviceState() but it fails. I traced the problem to it needing to Reacquire the device, and so I then used ->Acquire() to do so before the call to ->GetDeviceState. But ->Acquire() fails as well! Retreiving the error message from the acquire() call, I recieve the return value "S_FALSE" for a few loop iterations, and then - more worringly - "DIERR_OTHERAPPHASPRIO". Now I know that this is telling me that another app has priority, but the only other app that is running is Visual Studio C++.NET 2003 - and I need that to test the damn thing! I've also tried to change the cooperative settings such as back/foreground and non/exclusive, but only changing it to background makes any difference - the device is acquired, but the keyboard still appears to be dissabled... I'm sticking rigidly to the DirectX9 SDK's tutorials here, but I get the feeling that I may have a problem with the app's priority level. Also, I've noticed that when I close the app down with the window's standard close item, the program is still running in the processes tab in the Windows Task manager - and I must terminate the process from there...strange. Anyone else had trouble with this?

Share this post


Link to post
Share on other sites
Advertisement
A few thoughts:
1. This probably won't fix the problem, but you should (maybe you already do?) know that Acquire() and GetDeviceState() are never gauranteed to succeed, even if you're code is perfect; you can't get the device state or reacquire the deivce until your progrma is passed input focus again. Therefore, you should check the results of Acquire() and GetDeviceState() each time you updat the input buffer and not have a heart attack if they fail. Don't call Acquire() unless GetDeviceState() fails.

LPDIRECTINPUTDEVICE8 m_pDevice;
BYTE m_iKeyBuffer[256];
...
if(m_pDevice != NULL)
{
HRESULT Code = m_pDevice->GetDeviceState (sizeof(BYTE)*256, (LPVOID)&m_iKeyBuffer); // try to get the device state
if(FAILED(Code))
{
if(Code == DIERR_INPUTLOST || Code == DIERR_NOTACQUIRED) // if the device is not acquired anymore,
{
m_pDevice->Acquire(); // try to acquire it
}
else // if there was an error, but it wasn't one of those codes, then something has actually gone wrong
{
// handle the error
}
}
}


2. Again, this probably won't help, but... I have had a similar problem with DirectInput and Visual C++ .NET 2003. When I start the program from inside the compiler, a box pops up from the bottom of the screen displaying compilation output and the like. It interferes with input and output for full screen applications. I found that if I use ALT-TAB to switch back to the VC++ window and then click in the source code window, the box will go away and I can switch back to my program with no problems. I think the problem has something to do with the fact that the box scrolls into view.
3. In the window procedure, do you have a PostQuitMessage(0) command under WM_DESTROY? Clicking on the X button is only supposed to close the window, not the program (because the program might have many windows, or, like some tray apps, run in the background and possibly create more windows later). The program must respond to the WM_DESTROY message by calling PostQuitMessage(0) if it wants the program to exit when the window is closed.

LRESULT CALLBACK WindowProcedure(HWND hWnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
switch(uiMsg) // handle the messages
{
case WM_DESTROY:
{
PostQuitMessage(0); // send a WM_QUIT to the message queue
} break;
default: // for messages that we don't deal with specifically
{
return DefWindowProc(hWnd, uiMsg, wParam, lParam);
} break;
}

return 0;
}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!