How to get raw input data from the win 32 API thats not dependant on a window?
Author
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?
Author
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?
Given a HWND you can override the WndProc like this:
Then call your own WndProc from StaticWindowProc:
Note how the original WndProc is called for all messages you don't handle.
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.
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.
You can't change the desktop window's WndProc.
From MSDN for SetWindowLongPtr http://msdn.microsoft.com/en-us/library/ms644898(VS.85).aspx
And also:
I suggest you create an invisible window, and have it handle your messages. Many Windows programs do that, even built-in Microsoft programs.
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.
Author
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...
Author
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).aspxQuote:
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.
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.
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.
Author
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...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
