Jump to content

  • Log In with Google      Sign In   
  • Create Account

cannot receive WM_INPUT_DEVICE_CHANGE message after registered with RIDEV_DEVNOTIFY


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 Frahm   Members   -  Reputation: 106

Like
0Likes
Like

Posted 21 October 2013 - 07:43 AM

Hey, this is my first post, and I have some trouble when implementing my input framework for my game. I want to get notified whenever a keyboard is attached for detached from the computer, but I couldn't get it done.

Here is the relevant codes:

void Input::registerKeyboards() {
  RAWINPUTDEVICE rid[1];
  rid[0].usUsagePage = 0x01;
  rid[0].usUsage = 0x06;
  rid[0].dwFlags = RIDEV_DEVNOTIFY;
  rid[0].hwndTarget = 0;
  if(RegisterRawInputDevices(rid, 1, sizeof(RAWINPUTDEVICE)) == FALSE) {
    DebugTrace();
  }
}

 and the message loop

  MSG msg;
  while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) != 0) {
    switch(msg.message) {
      case WM_INPUT:
        input_.onKeyEvent(msg.lParam);
        break;
      case WM_INPUT_DEVICE_CHANGE:
        input_.onDeviceChanges(msg.wParam, msg.lParam);
        break;
      case WM_QUIT:
        this->exit_code_ = msg.wParam;
        return false;
      default:
        DispatchMessage(&msg);
    }
  }

I can receive all the WM_INPUT message, but no WM_INPUT_DEVICE_CHANGE.

There must be something I missed, any suggestions would be appreciated.



Sponsor:

#2 Endurion   Crossbones+   -  Reputation: 3575

Like
0Likes
Like

Posted 22 October 2013 - 11:09 PM

Why in heaven to you process messages in your message loop?

 

You really should only handle messages (beside WM_QUIT) in your window proc. DispatchMessage may actually create new messages while dispatching that will never even appear in your loop.

 

 

Second line on MSDN for WM_INPUT_DEVICE_CHANGE:

 

Sent to the window that registered to receive raw input.

A window receives this message through its WindowProc function.


Edited by Endurion, 22 October 2013 - 11:10 PM.

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#3 wintertime   Members   -  Reputation: 1713

Like
0Likes
Like

Posted 23 October 2013 - 03:35 AM

Yes, you need to know on Windows there are 2 ways to take a message to you.

SendMessage directly calls the window procedure you gave on window creation when its used.

PostMessage just puts it in the message queue where you can retrieve it with GetMessage or PeekMessage, then you can feed it to TranslateMessage if you want WM_CHAR and similar messages for text input to be generated from keyboard messages and then you call DispatchMessage which checks what window the message belongs to and calls the window procedure for that window.



#4 Frahm   Members   -  Reputation: 106

Like
0Likes
Like

Posted 23 October 2013 - 05:21 AM

Thanks for answering my question.

Why in heaven to you process messages in your message loop?

 

You really should only handle messages (beside WM_QUIT) in your window proc. DispatchMessage may actually create new messages while dispatching that will never even appear in your loop.

 

 

Second line on MSDN for WM_INPUT_DEVICE_CHANGE:

 

Sent to the window that registered to receive raw input.

A window receives this message through its WindowProc function.

 

The reason that I process input messages inside the message loop is to avoid introducing another global variable. Yes, I have tried catching the WM_INPUT_DEVICE_CHANGE message inside the WndProc, and it failed. "Sent to the window that registered to receive raw input", does it mean that I must specify a single window handle to catching this message?

void Input::registerKeyboards(HWND handle) {
  RAWINPUTDEVICE rid[1];
  rid[0].usUsagePage = 0x01;
  rid[0].usUsage = 0x06;
  rid[0].dwFlags = RIDEV_DEVNOTIFY;
  rid[0].hwndTarget = handle;
  if(RegisterRawInputDevices(rid, 1, sizeof(RAWINPUTDEVICE)) == FALSE) {
    DebugTrace();
  }
}

this really works well, but I have more than one window, and I need the "inputs following the focus" feature. is there any way to work around this?

 

Yes, you need to know on Windows there are 2 ways to take a message to you.

SendMessage directly calls the window procedure you gave on window creation when its used.

PostMessage just puts it in the message queue where you can retrieve it with GetMessage or PeekMessage, then you can feed it to TranslateMessage if you want WM_CHAR and similar messages for text input to be generated from keyboard messages and then you call DispatchMessage which checks what window the message belongs to and calls the window procedure for that window.

Thanks, you mean that message might comes from a call to SendMessage, it sounds resonable, but after I tried this:

LRESULT CALLBACK WndProc(HWND handle,
                         UINT message,
                         WPARAM w_param,
                         LPARAM l_param) {
  if(message == WM_NCCREATE) {
    SetWindowLongPtr(handle, GWLP_USERDATA, 
    (LONG_PTR)(((LPCREATESTRUCT)l_param)->lpCreateParams));
    //let it propagate
  }
  
  if(message == WM_INPUT_DEVICE_CHANGE) {
    OutputDebugString(L"bingo\n");
  }

  //....

  return DefWindowProc(handle, message, w_param, l_param);
}

it didn't output "bingo" in my output window. I didn't call TranslateMessage since I don't want to process WM_CHAR.


Edited by Frahm, 23 October 2013 - 05:24 AM.


#5 Endurion   Crossbones+   -  Reputation: 3575

Like
0Likes
Like

Posted 25 October 2013 - 12:24 AM

Did you use the WndProcs HWND as the registered hwndTarget?


Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#6 Frahm   Members   -  Reputation: 106

Like
0Likes
Like

Posted 26 October 2013 - 01:04 AM

Did you use the WndProcs HWND as the registered hwndTarget?

no, I set the hwndTarget as 0 since I have more than one window that needs keyboard inputs, and I don't want to restrict the inputs to one window.



#7 Bacterius   Crossbones+   -  Reputation: 8880

Like
0Likes
Like

Posted 27 October 2013 - 05:05 AM

/offtopic

 

Sorry for intruding, but I couldn't help noticing - how does this thread have over 14k views? blink.png


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#8 Headkaze   Members   -  Reputation: 583

Like
0Likes
Like

Posted 27 October 2013 - 04:31 PM

You could have a message only window that receives all raw input (using RIDEV_INPUTSINK) and passes it on to the other windows.

#9 Frahm   Members   -  Reputation: 106

Like
0Likes
Like

Posted 27 October 2013 - 10:12 PM

/offtopic

 

Sorry for intruding, but I couldn't help noticing - how does this thread have over 14k views? blink.png

Even me doubt about it, but I found that this thread has good rankings when searching with these keywords: "WM_INPUT_DEVICE_CHANGE",  "RIDEV_DEVNOTIFY".


Edited by Frahm, 27 October 2013 - 10:12 PM.


#10 Frahm   Members   -  Reputation: 106

Like
0Likes
Like

Posted 27 October 2013 - 10:20 PM

You could have a message only window that receives all raw input (using RIDEV_INPUTSINK) and passes it on to the other windows.

nice, it works.

 

Thank you all, guys.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS