Mouseevent units question

[KSTS]

In dllcall ( mouse_event, if i set the mouse to move with decimal units or lower than 1, will it move? Is there limitations?

[BoBo]

No idea if this will be the case for DllCall() but IMHO it won't make sense with any pixel-coord-related command like MouseMove
Here the mouse will only move once the x/y-coord is an integer.

Code: Select all

F7::
	x := A_ScreenWidth / 2
	y := A_ScreenHeight / 2
	Run, Notepad ,, Max
	Loop % 50 {
		x += 0.1
		y += 0.1
		ToolTip % round(x,2) " : " round(Y,2)
		Sleep, 300
		MouseMove, round(x,2), round(y,2)
		}
	ToolTip
	Return

[Noesis]

Short answer is Mouse_Event is expecting an integer value.

Depending on what you're trying to do, it also kind of depends on how you're using mouse_event (are you telling it to use relative or absolute coords). If absolute it's pixel based, if relative, it's mickey based. Again, neither of these units have fractional components, i.e. no such thing as 0.5 of a pixel, or 0.5 of a mickey (A mickey is the amount that a mouse has to move for it to report that it has moved, traditionally approx 1/200th of an inch but can vary depending on the mouse and it's settings).

Having said that, a mickey is less than a pixel, so you could move the mouse less than a pixel, it wouldn't show with the mouse cursor on the desktop, but it would be detected as moved, and would show in programs that show more minor movements.

Without further info on exactly what you're doing and how you're using the dllcall, you're best bet is look at this page https://msdn.microsoft.com/en-us/library/ms646260.

[BoBo]

@Noesis, thx for that insightful explanation. Much appreciated

[evilC]

"If absolute it's pixel based". Are these not "global coordinates"? ie the 65k x 65k address space that all desktops fit into?
Why do you think that 1 mickey is too much? If you are using moves of 1 mickey, but the screen moves too quickly then either:
1) Turn down the DPI of the mouse in your mouse software (Windows sensitivity setting will have ZERO effect on games)
2) Turn down the sensitivity of the mouse in the game
3) Send mouse_event DllCalls less frequently (I suspect this is not your issue tho as AHK timers / sleep etc only go down to ~10ms and 1-5ms is much smoother for mouse_event)

[Noesis]

@evilC, I'm not entirely sure if you've posted to the correct thread.

Regarding the "If absolute it's pixel based" I'd have thought that was pretty self explanatory, 1 unit = 1 pixel. Since it's a Windows API call, it means the size of the MS Windows Desktop, as represented by the monitor resolution or combined resolution if more than one monitor. Relative to 0,0 being the top left corner of whichever monitor is set as the Primary Monitor within the Windows OS.

KSTD never said what this was for, it may be a game, or it could be a widowed desktop app, I have no idea. Perhaps there's been a deleted post or something but I'm also not sure where anyone said 1 mickey was too much, my suspicion when I posted was that it would likely not be enough, but I never actually said anything one way or the other regarding that, I simply mentioned a mickey is less than a pixel (which could actually be wrong, depending on if he/she has deliberately changed certain settings, to make 1 mickey less than or equal to 1 pixel, which is highly unlikely IMO).

Still good advice if it turns out it is for a game and 1 mickey actually is too much.

[evilC]

@Noesis Yes, I posted in the correct thread.
You made the statement "If absolute it's pixel based, if relative, it's mickey based" which, as far as I am aware, is incorrect.
Absolute is not reported in pixels. No form of mouse input is ever reported in pixels.
In the RAWMOUSE structure, when usFlags is 1 (MOUSE_MOVE_ABSOLUTE), the mouse reports values in the range 0...65535 for each axis.
Bear in mind the case of a WACOM tablet operating in absolute mode. How does the WACOM know what your screen(s) resolution is? It doesn't.
Windows has one "coordinate space" of 65k units square, which all desktops get mapped into. This then ties up with the absolute range used by the mouse, so the bottom-right of your WACOM tablet matches up with the bottom-right of your right-most, bottom-most monitor.
Or at least that is the way I understand it, an absolute pointing device is still on my purchase list so that I can play around with it in person.

Perhaps there's been a deleted post or something but I'm also not sure where anyone said 1 mickey was too much

if i set the mouse to move with decimal units or lower than 1, will it move?

The implication being that he does not have as much granularity as he wants (ie he wants to be able to move less than 1 mickey)

[Noesis]

Fair enough, however, he's not using, Raw Input or a WACOM tablet (which btw I'm unfamiliar with), as far as I'm aware, he's using a "mouse_event" dllcall which I linked to in my original post.

This particular Mouse_Event api call doesn't report anything, (it's a Void return type). It's like ahk's mousemove, it sets the mouse to a position, if absolute coords are used that desired position is expressed as pixel coordinates, if set to use relative coordinates, then it uses mickeys instead of pixels as the units, it then simulates a mouse movement.

It's all in the msdn linked In my original post.

None of what you're saying is wrong, it's just that it isn't relevant to this particular api call. Hence I was confused by your original post.

With regard to the granularity, 1 pixel might not be small enough, but 1 mickey might be, might not be to. No way of knowing without further info, as it depends on what mode was used with the dllcall.

[evilC]

Me bringing up absolute was only ever intended to be relevant to the comment you made regarding how relative worked vs absolute - I just thought I would point out that as far as I knew, absolute did not quite work how you thought it did. Sorry for de-railing

however, he's not using, Raw Input

The point I was trying to make was that If he is using mouse_event, he effectively is using RawInput, as mouse_event essentially synthesizes RawInput events, so I saw it as relevant. ie, if you want a greater understanding of how various values or modes in mouse_event behave, you can study how the data appears from a real device when seen through RawInput