Sign in to follow this  
EmptyVoid

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

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
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 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
Documentation for RAWINPUTDEVICE: http://msdn.microsoft.com/en-us/library/ms645565(VS.85).aspx
Quote:

RIDEV_INPUTSINK
If set, this enables the caller to receive the input even when the caller is not in the foreground. Note that hwndTarget must be specified.


I don't mean to be rude, but this whole thread pretty much consists of questions that would've been answered if you'd glanced through the documentation. Ofcourse you can ask instead to get an educated answer, but you could at least look it over =) I suggest it mostly for your own benefit. Once you learn to use the available documentation and search tools, your development process will be quite significantly sped up.
I for one haven't even tried using this API, still I'm answering your questions.
Also you can benefit from explaining your problem in more detail in your question, together with the steps you've already taken attempting to solve your problem. Several times when I've been about to start a new topic, in the course of explaining the question well enough for everyone to understand exactly what I mean, I have found or realized the answer myself. While my more vague and not thought through questions rarely get me the answer I'm looking for.

Share this post


Link to post
Share on other sites
Quote:
Original post by Erik Rufelt
Documentation for RAWINPUTDEVICE: http://msdn.microsoft.com/en-us/library/ms645565(VS.85).aspx
Quote:

RIDEV_INPUTSINK
If set, this enables the caller to receive the input even when the caller is not in the foreground. Note that hwndTarget must be specified.


I don't mean to be rude, but this whole thread pretty much consists of questions that would've been answered if you'd glanced through the documentation. Ofcourse you can ask instead to get an educated answer, but you could at least look it over =) I suggest it mostly for your own benefit. Once you learn to use the available documentation and search tools, your development process will be quite significantly sped up.
I for one haven't even tried using this API, still I'm answering your questions.
Also you can benefit from explaining your problem in more detail in your question, together with the steps you've already taken attempting to solve your problem. Several times when I've been about to start a new topic, in the course of explaining the question well enough for everyone to understand exactly what I mean, I have found or realized the answer myself. While my more vague and not thought through questions rarely get me the answer I'm looking for.


I did read every line of that and every thing that has anything to do with raw input. Yes I may have missed something but I'm quit sure there is something completely different that I need to do and just to because I'll read every line again though I'm quit sure it won't help.

I may have not said so but I have tried each of your ideas and none of them have worked yet, plus many more I found on Google.

Code samples:

Init:


RAWINPUTDEVICE Rid[2];
Rid[0].usUsagePage = 0x01;
Rid[0].usUsage = 0x02;
Rid[0].dwFlags = NULL;
Rid[0].hwndTarget = 0;
Rid[1].usUsagePage = 0x01;
Rid[1].usUsage = 0x06;
Rid[1].dwFlags = NULL;
Rid[1].hwndTarget = 0;
RegisterRawInputDevices(Rid, 2, sizeof(Rid[0]));












WndProc:


LRESULT CALLBACK WndProc( HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam )
{
switch( message )
{

case WM_INPUT:
{
UINT dwSize;
GetRawInputData((HRAWINPUT)lParam, RID_INPUT, NULL, &dwSize, sizeof(RAWINPUTHEADER));
LPBYTE lpb = new BYTE[dwSize];
GetRawInputData((HRAWINPUT)lParam, RID_INPUT, lpb, &dwSize, sizeof(RAWINPUTHEADER));
RAWINPUT* raw = (RAWINPUT*)lpb;

if (raw->header.dwType == RIM_TYPEKEYBOARD)
{

}
else if (raw->header.dwType == RIM_TYPEMOUSE)
{
// If something happend with the mouse do lua On_MouseEvent and pass the values to it.
lua_getfield(g_Lua, LUA_GLOBALSINDEX, "On_MouseEvent");
lua_pushnumber(g_Lua,raw->data.mouse.lLastX);
lua_pushnumber(g_Lua,raw->data.mouse.lLastY);
lua_pushinteger(g_Lua,raw->data.mouse.ulButtons);
lua_call(g_Lua, 3, 0);
}

delete[] lpb;
break;
}

default:
return DefWindowProc( hWnd, message, wParam, lParam );
}
return 0;
}












The problem with this is that my program needs to receive inputs even if none of it's window are active.

EDIT: Why didn't you just say so?! Well anyways thanks and next time I'll read the msdn documents more then once just to make sure I didn't miss anything... (*Sigh* The darn Windows API defies logic...)

[Edited by - EmptyVoid on October 12, 2008 5:20:42 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by CmpDev
TO create your key logger (which is effectively what you want) use a message only window using HWND_MESSAGE.
http://msdn.microsoft.com/en-us/library/ms632599(VS.85).aspx


Even better!!! Thank you!!!

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
Quote:
Original post by Erik Rufelt
Documentation for RAWINPUTDEVICE: http://msdn.microsoft.com/en-us/library/ms645565(VS.85).aspx
Quote:

RIDEV_INPUTSINK
If set, this enables the caller to receive the input even when the caller is not in the foreground. Note that hwndTarget must be specified.

...

...
EDIT: Why didn't you just say so?! Well anyways thanks and next time I'll read the msdn documents more then once just to make sure I didn't miss anything... (*Sigh* The darn Windows API defies logic...)


Haha, I did say so, you probably just missed it =) Read my quote again, it says exactly the flag, and that the hwndTarget must be specified.

Share this post


Link to post
Share on other sites
Quote:
Original post by Erik Rufelt
Quote:
Original post by EmptyVoid
Quote:
Original post by Erik Rufelt
Documentation for RAWINPUTDEVICE: http://msdn.microsoft.com/en-us/library/ms645565(VS.85).aspx
Quote:

RIDEV_INPUTSINK
If set, this enables the caller to receive the input even when the caller is not in the foreground. Note that hwndTarget must be specified.

...

...
EDIT: Why didn't you just say so?! Well anyways thanks and next time I'll read the msdn documents more then once just to make sure I didn't miss anything... (*Sigh* The darn Windows API defies logic...)


Haha, I did say so, you probably just missed it =) Read my quote again, it says exactly the flag, and that the hwndTarget must be specified.


Oh Haha!!!, I'm kinda half awake but the good news is with that and HWND_MESSAGE it works exactly how I want. Even though a bit more complex then I would have thought but still works perfect!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this