API - Unable to simulate +/- mouse scrolling

I am trying to send a mouse event using data from a WM_MOUSEWHEEL event that I saved in eventmsg.

I am not able to determine from the eventmsg paramH or paramL if the mouse was scrolled up or down. If I can determine that I can simply make WHEEL_DELTA ( 120 or -120) to send a 1 click scroll up or down in my mouse_event statement.

My question is, how can I determine mouse scroll direction from the data saved in eventmsg

Hi,

Looking at event msg structure, I am not sure what paramH is. I am thinking it should be window's wParam. ( i am also guessing that paramL is lParam).

If that is the case, the highword of your paramH (wParam) should have the delta in the highword portion (high-16bith portion). To get the high word portion of a variable, use the following code (note that .net may have an inbuilt function to do it)

Public Shared Function HighWord(ByVal i As Int32) As Int16
Return CShort((i And &HFFFF0000) \ &H10000)
End Function

Nic

Nicolas_qc_au wrote:

Hi, Public Shared Function HighWord(ByVal i As Int32) As Int16 Return CShort((i And &HFFFF0000) \ &H10000) End Function Nic

I am using vb6, and get errors when trying to insert this code. So instead I used this.....

Public Function HighWord(ByVal i As Int32) As Int16
HighWord = CShort((i And &HFFFF0000) \ &H10000)
End Function

same thing right relatively speaking for my purpose

Still getting errors when I click run.....

"User defined type not defined" on this statement

Public Function HighWord(ByVal i As Int32) As Int16

Hi,

Int16 and Int32 are .net datatypes only. Use Integer and Long respectively for vb6.

I am also not sure if CShort is a vb 6.0 function, what it's equivalent is, or if you need it at all for VB6.

The Shared Keyword used does not exist in VB6 and can be removed. In .net it allows the function to be calleable without creating an instance of a class.

The rest of the code should be fine.

Cheers

Nic

Doesnt like the word Short, probably use integer...........correct

In testing, debugger shows i (paramH) to be 312 upon entry into the function. The functions returns the value 0.

paramL is 581. These values change depending on where my mouse is when I record them.

To help anyone undersstand where my data is coming from here is a sample of my code.......

Hi,

I doesn't seem like you are caching wParam. From your code, it seems you're only doing stuff with lParam which is probably the problem. As such, I believe that paramH is not the wParam that you need.

Notice in your JournalRecordProc that you are receiving wParam yet not doing anything with it.

Cheers

Nic

Not too sure I understand what you mean. I capture wparam here

CopyMemory EVENTMSG, ByVal lParam, Len(tEVENTMSG)

This statement copies the contents in memory pointed to by lParam to the EVENTMSG structure. wparam is thereby saved.

The code works fine for everything......

WM_MOUSEMOVE, WM_LBUTTONUP, WM_LBUTTONDOWN, WM_LBUTTONDBLCLK, WM_RBUTTONUP, WM_RBUTTONDOWN, WM_RBUTTONDBLCLK, WM_MBUTTONUP, WM_MBUTTONDOWN, WM_KEYUP, WM_KEYDOWN

Keep in mind the code I showed you is not the entire source, just a small snippit..

Somebody found this for me. Here's the thing. It looks like the function is expecting a double word as input for function, however the wparam is a long.......man i'm so confused....... according to what microsoft says.......

http://msdn2.microsoft.com/en-us/library/ms644966.aspx

This is obviously in C, what is the vb6 equivalent of the UINT data type Its LONG isnt it

Hi,

Again, the one thing I am not certain is the ParamH of the EVENTMSG. From what I can tell, it "could" be the wParam of a normal event but why would they've used a different name !

When you say the code works fine for other events, have you checked that paramH correspond to wParam in those other events, or is it different

Again, the issue is not with the copymemory or the journalplaybackproc, but seems to be the discrepency between paramH and wParam.

cheers

Nic

Hi,

UINT is a 32 bit unsigned integer (i.e. use a Long in VB6).

The issue with your code though is that the paramH's value is too "low" to be the wParam that is needed. For instance, for the highword to have a value of 1, paramH must be 65536. As such, for a highword value other than 0, paramH must be between 65536 and 4294901760. Any other value means a highword of 0.

If the highword is 0, then the mousewheel delta value is 0 as well. Hence the HighWord function is working. The issue is not the function, it is the fact that the paramH value does not represent wParam of a WM_MOUSEWHEEL event (to my knowledge).

Cheers

Nic

My eventmsg structure is named exactly as microsofts example in the link I provided. I imagine they use a different name to avoid confusion..........LOL

wParam is not used in the function call. Only lParam is used, which again, is the pointer to the data for the event message. Moving the memory from the lParam position by length of eventmsg into eventmsg must be correct, because the paramH and paramL, seem to contain the correct values.

Microsoft's declaration of JournalRecordProc........Notice it indicates wParam is not used.

http://msdn2.microsoft.com/en-us/library/ms644983.aspx

Hi,

The JournalRecordProc receives, among other things, two params lParam and wParam.

wParam is nothing.

lParam is a pointer to an EVENTMSG structure. This EVENTMSG represents a standard windows event (to my knowledge). A standard windows event has four prarams (msg, hWnd, lParam and wParam). The EVENTMSG structure does have an hWnd, a message, a lParam but does not have a wParam (it has an paramh). It also has a time stamp but that is just for sequencing or some such.

To find what direction the mousewheel was scrolled, we need access to the wParam of the WM_MOUSEWHEEL event. Buggered if I know given we have the odd paramh.

Cheers

Nic

I can trap the event by checking the value of code in journalrecordproc. If the value = wm_mousewheel then I know the event is scrolling the mouse. At the point where I have determined I have a mouse scroll, I capture the memory according to the structure microsoft says windowsmessages are designed. I'm at a loss. I found the same questions posted on another site, but they want money to show their answers. I cant find any source code to look at as an example.

Microsofts example of WM_LBUTTONDOWN

http://msdn.microsoft.com/library/default.asp url=/library/en-us/winui/winui/windowsuserinterface/userinput/mouseinput/mouseinputreference/mouseinputmessages/wm_lbuttondown.asp

compared to ......... WM_MOUSEWHEEL

http://msdn.microsoft.com/library/default.asp url=/library/en-us/winui/winui/windowsuserinterface/userinput/mouseinput/mouseinputreference/mouseinputmessages/wm_mousewheel.asp

Maybe I need to use a window hook........ like it says ...........if thats even a hook Still learning...

http://msdn.microsoft.com/library/default.asp url=/library/en-us/winui/winui/windowsuserinterface/windowing/windowprocedures/windowprocedurereference/windowprocedurefunctions/windowproc.asp

Hi,

What I have found is this. For mouse messages, ParamL = x coordinate and ParamH = y coordinate.

As such, the method is not recording the original lparam, wparam of the standard windows proc function but a converted parameter. This essentially means that you cannot query the direction of the mousewheel using JournalRecordProc.

You can't event query if SHIFT, CONTROL, ALT were pressed down when it occured.

The next question is, why were you using JournalRecordProc. If it's simply to monitor the mouse, you could use instead the MouseProc or the LowLevelMouseProc.

The real reason to use JournalRecordProc is to write them out to a file to playback later.

And all three, JournalRecordProc, MouseProc, LowLevelMouseProc (and others) are called hooks. they "hook" into the OS allowing you to intercept messages as they occur. It's the base trick for keyloggers, by the way.

Suggestion is, use the LowLevelMouseProc if you can (among others).

Cheers

Nic