Direct Input: Mouse->Acquire

MSDN says to call the Acquire() function only once, and thereafter only when something causes my window to lose focus.

The problem is, I don't know what's causing my window to lose focus, so my main game loop consists of three functions: MessagePump(), ProcessMouse(), and Render().

At the start of the ProcessMouse() function, each time, I call:

Code:

---

if(pMouse)
{
        pMouse->Acquire();
}

---

Therefore, re-acquiring the mouse each frame (even if it hasn't necesserily been unaqcuired).

I'm just wondering if anyone out there knows if doing this will eventually cause me problems?

Your window if its full screen should not lose the focus unless the user presses ALT-TAB or CTRL ALT DEL. You could just intercept the lose focus message in your message loop and not respond to it, but that would probably have some nasty side effects not apparent to me at this time.

Acquireing the mouse every frame is not good, though, and you should find out at least why your window is losing the focus.

Hmm, okay, well I'm running windowed mode, but never do I click outside of the screen...

My Initialisation looks like:

Code:

---

MyGame->Initialise(gHwnd, pInstance);

ShowWindow(gHwnd, SW_SHOW);
UpdateWindow(gHwnd);
SetFocus(gHwnd);

MyGame->GameLoop();

---

It would be ridiculous for me to post all of the inner code of MyGame, but MyGame is just a class defined by me to do what I need (with heavy emphasis on ideas from DrunkenHyena and Andy Pike), but there's nothing in there that should be causing me to lose focus.

Is there a function of pMouse (My DI mouse variable) to see if it is currently acquired? Or you also spoke of intercepting the message, I'm assuming that would be with my main Message Handler window...I've been reading around a bit, and just out of curiosity, would that be the WM_ACTIVATE message you're speaking of?

Just a little tidbit to go along with this problem:

I threw in this code into my Default Windows Procedure message handling function:

Code:

---

case WM_ACTIVATE:
        if(wParam == WA_INACTIVE)
        {
                MessageBox(NULL, "NOW", "INACTIVE", MB_OK);
        }
break;

---

And the only time the MessageBox fires is when I press escape to close the window:

Code:

---

    case WM_KEYDOWN:
        switch (wParam)
        {
                case VK_ESCAPE:
                    MyGame->PostQuit();
                    return 0;
                break;
        }

---

(Also in the Message Handler Function)
And maybe this would be more apparent to you than it was to me before running the code, but that MessageBox will pop up over and over, refusing to let me quit my application once I pressed escape :)

OOOHHH!!! Is it because I'm calling the SetFocus and ShowWindow things AFTER I initialise DirectInput? Maybe! I'll go test it out!

WOOHOO!!!

(I know these last two posts could've probably been joined into one, but I'm just that excited) :)

I've changed the Message Handling function to include:

Code:

---

                case WM_ACTIVATE:
                        if((wParam == WA_INACTIVE) && (bMouseAcquired == true))
                        {
                                MyGame->AcquireMouse(false);
                                bMouseAcquired = false;
                        }
                        if((wParam == WA_ACTIVE) && (bMouseAcquired == false))
                        {
                                MyGame->AcquireMouse(true);
                                bMouseAcquired = true;
                        }
                break;

---

Where bMouseAcquired is a global variable and AcquireMouse() does what is necessery. And it's working fine. But now a new problem, when I try to "Right-Click" in my Taskbar at the bottom of the screen, normally a Windows Menu comes up, but it doesn't anymore.

I've been going through an MSDN article that deals with this problem, but DX9. (http://msdn.microsoft.com/archive/de...esstomouse.asp)

So far it's all helped, and it sayed that the fix to this menu problem is that when the menu is attempting to be launched, the WM_ENTERMENULOOP is fired in the message handler. And then, once the menu closes, the WM_EXITSIZEMOVE is fired.

I've added this code to try and deal with the menu problem:

Code:

---

case WM_ENTERMENULOOP:
        MyGame->AcquireMouse(false);
        bMouseAcquired = false;
break;
case WM_EXITSIZEMOVE:
        MyGame->AcquireMouse(true);
        bMouseAcquired = true;
break;

---

But still it doesn't come up. I'm thinking, that maybe it's too late to Unacquire the mouse AFTER the event has been fired? But from what I read, this was the fix that MSDN gave. If there are any ideas or thoughts, I'd be happy to hear them :)

Still curious if somebody knows an answer to the above post.

Or are there other events that could be being fired that you know of when the user right clicks to bring up the menu?

Any ideas are appreciated

Erik