Generating Window Procedure mouse WPARAM from Hooks

[seaders]

Ok, I've a DLL that's hooked to pick up all Mouse and Keyboard events in it. What I then want to do is through all those to another window. I understand how to do simulate these events, with PostMessage and SendMessage, to the HWND, but what I'd like to do is automatically convert these into a compatible lpfnWndProc message.

Generating the UINT is easy enough, because that can be obtained in the hooks, as the WPARAM identifier. The values for LPARAM and wParam for Keyboard is also easy, but I've no idea how to get the lParam for mouse events.

From MSDN, it says that it

Indicates whether various virtual keys are down. This parameter can be one or more of the following values.

MK_CONTROL
The CTRL key is down.
MK_LBUTTON
The left mouse button is down.
MK_MBUTTON
The middle mouse button is down.
MK_RBUTTON
The right mouse button is down.
MK_SHIFT
The SHIFT key is down.
MK_XBUTTON1
Windows 2000/XP: The first X button is down.
MK_XBUTTON2
Windows 2000/XP: The second X button is down.

I can't see any way of getting this information from within the hooks, without keeping a static record of whether these keys were pressed already. Is there another way that I can get that information, do any of you know?

[William Hemsworth]

I'm not entirely sure what it is you're trying to do, posting some code would help (or even a small example). Some other ways to simulate these events is to use mouse_event and keybd_event, as directly sending a message into a windows procedure can sometimes give you a different result to what your expecting. I'm not entirely sure what you mean by "The values for LPARAM and wParam for Keyboard is also easy, but I've no idea how to get the lParam for mouse events."

[seaders]

In windows programming, when you've done all your regular stuff, setting your classes and everything, you have to set a WindowProcedure for your HWND,

wincl.lpfnWndProc = WindowProcedure;

...

Param;
}

LRESULT CALLBACK WindowProcedure(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
	switch (message) {
	case WM_MOUSEMOVE: {
		cout << message << ", " << wParam << ", " << LOWORD(lParam) << ", " << HIWORD(lParam) << endl;
	}
	break;
	}
}

In that Window Procedure, any time any mouse events take place, WM_LBUTTONUP, WM_LBUTTONDOWN... and so on, 4 pieces of information gets passed to it,
the HWND it should be applied to,
the UINT message id, which is the "WM_..." part,
a WPARAM which is the MSDN piece that I quoted and
a LPARAM, which contains a client relative container for the mouse x and y values.

From the DLL hooks, MouseProc and LowLevelMouseProc, you are easily able to get the HWND, the UINT and the LPARAM to recreate the message for the window, but I can't see anywhere that you can find how to recreate the WPARAM value.

With the keyboard, it's much easier, because the WPARAM and LPARAM from WindowProcedure are exactly the same as the WPARAM and LPARAM from the KeyboardProc Hook.

Does that explain it any better? I'm trying to find a may to work out how to create the WPARAM that gets sent to a WindowProcedure from within Hooks and I've no idea where that information would be found.

[nucleon]

It would seem that your only hope (besides the static idea) is to investigage what MOUSEHOOKSTRUCT's dwExtraInfo member holds.

[seaders]

that's what I thought to, but from where, like, there seems to be absolutely no information about that at all. I've tried finding out about that member before, but left it as there seemed to be little to know info about it at all.

[NicAx64]

are you trying to write a keylogger or something like that ?
am I correct ? Then using that program you are recording something
. some key strokes and mouse evens like this.

Yes you can do this on your secnario using the SendMessage () API call if you knows the HWND( window handle ) value of the targert window.

But if you are writing a keylogger , it's very easy to use the OLE instead of using a window procedure of your listining program.

Please brifely explain your secnnario.

[NicAx64]

I can't see any way of getting this information from within the hooks, without keeping a static record of whether these keys were pressed already. Is there another way that I can get that information, do any of you know?

These information are simple. WPARAM HIWORD contains the y location and the WPARAM LOWORD contains the x position.

EDIT: Opps sorry ,
MouseProc doesn't input that LPARAM no ?
anyway I write a keylogger a long time ago. second , I will see what I can do.

[NicAx64]

I don't know this will be really useful . Sounds like there is no direct way to just pass it directly. looks like You have to use the LowLevelMouseProc and it's LPARAM is the
pointer to MSLLHOOKSTRUCT structure. Then if you see the MSDN page of that struct you can find that there is POINT structure inside it.

So use these values and make your new lParam value , It's normal
HIWORD contains the y and loword contains the x . Just typecast it up and reassemble the lParam and pass it to SendMessage.

Don't try to pass lParam as it is to the SendMessage() .

// this is MSLLHOOKSTRUCT

typedef struct {
    POINT pt;
    DWORD mouseData;
    DWORD flags;
    DWORD time;
    ULONG_PTR dwExtraInfo;
} MSLLHOOKSTRUCT, *PMSLLHOOKSTRUCT;

// This is point
typedef struct tagPOINT {
  LONG x;
  LONG y;
} POINT, 
 *PPOINT;

so the x and y values are in longs and they are 4 bytes long. However you have to typecast them and make lParam as it means. If you know basic C++ you can do this.

My idea is for this is just take the y value and shift it by 2^15 and add it to x That will make your new lParam.

Note: looks like there is no other way. But keep this thread open ! someone will reply.

[seaders]

My scenario is like a proprietary VNC or remote desktop operation. I'm getting the image of a remote system on like a web-page, that's refreshed a few times a second, then whatever I do locally, within that window is sent across to the remote system. I've got everything else working exactly how I want and this is the last thing I need.

Just to clarify, for the last few posts, I've already got the UINT that would go into the WindowProcedure, as do I have the LPARAM, which contains the relative x and y co-ordinates of the mouse position in it's high and low bytes, they're easily available from the MouseProc hook. Unfortunately, as I've said the information from within the WPARAM of the WindowProcedure does not seem to be available from hooks.

This parameter, as I quoted from MSDN,

Indicates whether various virtual keys are down. This parameter can be one or more of the following values.

MK_CONTROL
The CTRL key is down.
MK_LBUTTON
The left mouse button is down.
MK_MBUTTON
The middle mouse button is down.
MK_RBUTTON
The right mouse button is down.
MK_SHIFT
The SHIFT key is down.
MK_XBUTTON1
Windows 2000/XP: The first X button is down.
MK_XBUTTON2
Windows 2000/XP: The second X button is down.

I can't find any Mouse Hook that has that information, which, from where I sit, is really strange. I also find the lack of information about that dwExtraInfo very strange.

For the moment, I've built my system up that will just send 0 as the WPARAM, but I can't it as that for long. I really didn't want to have to keep track of whether all of those buttons are pressed or not, but it's looking like I may have to.

[NicAx64]

WPARAM is availiable in the LowLevelMouseProc procedure.
I think you can use it.

and you can process that structure to get x and y values out.

see http://msdn.microsoft.com/en-us/library/ms644986.aspx

I wonder is there are duplicate docs for various zones ( I'm asian).

[seaders]

No sorry NicAx64, they may both be WPARAM's, but they contain very different information. The WPARAM from LowLevelMouseProc is the mouse event identifier, whether the event itself is mousewheel up, left-mouse button down, it's actually the exact same as the UINT that gets sent to the WindowProcedure.

http://msdn.microsoft.com/en-us/library/ms644986(VS.85).aspx
&
http://msdn.microsoft.com/en-us/library/ms645616(VS.85).aspx

I've already got the x and y values out, as I've stated, they're not the problem. Getting the extra information to fill the WPARAM for the Window Procedure, which contains information about whether virtual keys are present (see the second msdn link in this post).

[nucleon]

Is dwExtraInfo always 0? If not, try interpreting it as the keystate. That is, test it against, say, MK_CONTROL while pressing the control key. If it's just an arbitrary number, then maybe it's pointing to something ... but what? The lack of documentation on this is pitiful.

I've asked on comp.os.ms-windows.programmer.win32. I know I should have told YOU to ask, but I just did it. ;) I will post any answer back here.

[seaders]

Thank you very much, nucleon, I've only just subscribed and see your post, really appreciate that, it's at moments like this that you really do love the internet! I'll be watching for a reply there eagerly :)

I wholeheartedly agree about the pitiful documentation about some of those members, dwExtraInfo and reserved, that's pathetic to give that info and that info only. Even trying to get the full info on events that go through Window Procedure is a painful procedure, the was MSDN is set up. Ah well, we can but hope for improvements.

[seaders]

Got it! Thanks to a PM from NicAx64, where he suggested I use the GetKeyState function, it's now working perfectly.

So, from within my DLL, where the hooks are being set, I have a simple function that checks the states of the keys that the Window Procedure's contains,

int GetKeyStates() {
	int retval = 0;
	if (HIWORD(GetKeyState(VK_LBUTTON)))
		retval +=1;
	if (HIWORD(GetKeyState(VK_RBUTTON)))
		retval +=2;
	if (HIWORD(GetKeyState(VK_SHIFT)))
		retval +=4;
	if (HIWORD(GetKeyState(VK_CONTROL)))
		retval +=8;
	if (HIWORD(GetKeyState(VK_MBUTTON)))
		retval +=16;
	if (HIWORD(GetKeyState(VK_XBUTTON1)))
		retval +=32;
	if (HIWORD(GetKeyState(VK_XBUTTON2)))
		retval +=64;
	return retval;
}

Which then gives me that info. Thanks for all your help guys, although I still think that if Window Procedure gets this info implicitly, the hooks should too, this works just as well.

[nucleon]

Nice one, NicAx64 !!!