Jump to content
  • Advertisement
Sign in to follow this  
EmptyVoid

How to get raw input data from the win 32 API thats not dependant on a window?

This topic is 3686 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

Well I need to get raw input data from the win 32 API thats not dependant on a window. I don't know how but I think I could use GetDesktopWindow to get a handle to the desktop window and then I need to set it's WndProc to a function that gets the raw input data but I don't know how to set it's WndProc function. So how would I do this?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by SiCrane
That depends entirely on what you mean by "raw input data".


I would think it's pretty clear but I'll explain. I need to get the raw data from a Mouse, Keyboard, Gamepad, etc, using the win32 API command GetRawInputData but it is called in a window's WndProc function when it receives a WM_INPUT message, so now do you understand?

Share this post


Link to post
Share on other sites
Given a HWND you can override the WndProc like this:

window_info_t win_info;
win_info.input_system = this;
win_info.local_proc = &InputSystem::WindowProc;

// Retrieve window procedure
win_info.global_proc = (WNDPROC)::GetWindowLongPtr( wnd, GWLP_WNDPROC );
if( !win_info.global_proc )
throw Win32Exception( "Could not retrieve window procedure from supplied window handle: ", ::GetLastError() );

sWindowStore[ wnd ] = win_info;

// Override window procedure
if( !::SetWindowLongPtr( wnd, GWLP_WNDPROC, (LONG_PTR)&InputSystem::StaticWindowProc ) ) // This is the override WndProc
throw Win32Exception( "Could not set window procedure on supplied window handle: ", ::GetLastError() );


Then call your own WndProc from StaticWindowProc:

LRESULT CALLBACK InputSystem::StaticWindowProc( HWND wnd, UINT msg, WPARAM wParam, LPARAM lParam ) {
window_info_t const& win_info = sWindowStore[ wnd ];
return ( win_info.input_system->*win_info.local_proc )( wnd, win_info.global_proc, msg, wParam, lParam );
}

LRESULT InputSystem::WindowProc( HWND wnd, WNDPROC wnd_proc, UINT msg, WPARAM wParam, LPARAM lParam ) {
switch( msg ) {
[...]
default:
return ::CallWindowProc( wnd_proc, wnd, msg, wParam, lParam );
}
}


Note how the original WndProc is called for all messages you don't handle.

Share this post


Link to post
Share on other sites
You know, acting like an ass towards people trying to help you might explain why you have a 0 rating. Have fun figuring this out.

Share this post


Link to post
Share on other sites
You can't change the desktop window's WndProc.
From MSDN for SetWindowLongPtr http://msdn.microsoft.com/en-us/library/ms644898(VS.85).aspx
Quote:

The SetWindowLongPtr function fails if the process that owns the window specified by the hWnd parameter is at a higher process privilege in the User Interface Privilege Isolation (UIPI) hierarchy than the process the calling thread resides in.

Microsoft Windows XP and earlier: The SetWindowLongPtr function fails if the window specified by the hWnd parameter does not belong to the same process as the calling thread.


And also:
Quote:

Calling SetWindowLongPtr with the GWLP_WNDPROC index creates a subclass of the window class used to create the window. An application can subclass a system class, but should not subclass a window class created by another process.



I suggest you create an invisible window, and have it handle your messages. Many Windows programs do that, even built-in Microsoft programs.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
You know, acting like an ass towards people trying to help you might explain why you have a 0 rating. Have fun figuring this out.


Sorry I didn't even know I was being an ass, I'll try to say things that sound more friendly from now on then...

Share this post


Link to post
Share on other sites
Quote:
Original post by Erik Rufelt
You can't change the desktop window's WndProc.
From MSDN for SetWindowLongPtr http://msdn.microsoft.com/en-us/library/ms644898(VS.85).aspx
Quote:

The SetWindowLongPtr function fails if the process that owns the window specified by the hWnd parameter is at a higher process privilege in the User Interface Privilege Isolation (UIPI) hierarchy than the process the calling thread resides in.

Microsoft Windows XP and earlier: The SetWindowLongPtr function fails if the window specified by the hWnd parameter does not belong to the same process as the calling thread.


And also:
Quote:

Calling SetWindowLongPtr with the GWLP_WNDPROC index creates a subclass of the window class used to create the window. An application can subclass a system class, but should not subclass a window class created by another process.



I suggest you create an invisible window, and have it handle your messages. Many Windows programs do that, even built-in Microsoft programs.


Is that really the only option? It just seems a bit ridiculous.

Share this post


Link to post
Share on other sites
I haven't used raw input, so I'm not sure, but I doubt it's possible without a window. I haven't actually tried it with an invisible window either, so it might not even work.
By default only the top level window receives input. The documentation says this is the case for raw input too, but that you can register a specific window to receive input even when not in the foreground.
However, every Windows application is basically a window, and I guess the API is designed with that in mind. There is seldom if ever any good reason to receive input without a window to display it in.
You would probably have to use a lower level API to get such information without a window.

Share this post


Link to post
Share on other sites
Quote:
Original post by Erik Rufelt
I haven't used raw input, so I'm not sure, but I doubt it's possible without a window. I haven't actually tried it with an invisible window either, so it might not even work.
By default only the top level window receives input. The documentation says this is the case for raw input too, but that you can register a specific window to receive input even when not in the foreground.
However, every Windows application is basically a window, and I guess the API is designed with that in mind. There is seldom if ever any good reason to receive input without a window to display it in.
You would probably have to use a lower level API to get such information without a window.


No it didn't work but thats probably because it's not the active window so it's messages do not get processed but I think there is a way to fix that but I don't know how...

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!