negative distance retrieved from GetGestureInfo

Question

negative distance retrieved from GetGestureInfo

孟轩郝 11

I have a secondary monitor with a touch screen. When handling the WM_GESTURE message with dwID GID_ZOOM, the low 32-bit of the ullArguments retrieved from GetGestureInfo, which indicates the distance between the two points as documented, is negative if I position the secondary monitor on the left of the primary monitor as shown below. User's image

This issue also occurs when dwID is GID_PAN or GID_TWOFINGERTAP

Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-17T02:54:15.76+00:00

Whether have you tried placing the secondary monitor on the right of the primary monitor to check the result?
孟轩郝 11 Reputation points

2024-10-17T05:26:24.9733333+00:00

yeah, and then the distance returned is about 2000-3000. Actually I've tried placing the secondary monitor on different positions and it seems that the x-coordinate of its position is added to the result
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-17T08:56:20.6966667+00:00

According to your description, is it only when you position the secondary monitor on the left of the primary monitor that the result is negative? And is it normal to place the secondary display in another position? Could you please tell us what do you mean "the x-coordinate of its position is added to the result"?
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-17T09:06:01.5166667+00:00

According to the Doc:GESTUREINFO structure:

For GID_PRESSANDTAP, it is the distance between the two points.

For gestures like GID_PRESSANDTAP, the distance between the two points is stored in the ullArguments member.

For another gesture, the coordinates of the gesture are included in the ptsLocation member. Could you please tell us how you get the distance between the two points.
孟轩郝 11 Reputation points

2024-10-17T09:40:12.8566667+00:00

The document says the ullArgument indicates the distance between the two points for GID_ZOOM. And I'm assuming the two points means the places which my two fingers touch the screen.
孟轩郝 11 Reputation points

2024-10-17T10:07:14.45+00:00

My primary monitor has a resolution of 25601600 and my secondary monitor has a resolution of 19201080. I've tried to trigger the GID_ZOOM gesture with my two fingers close to each other which should result in the ullArgument to be around 100. This holds if I let the second monitor duplicate the primary monitor, or place the secondary monitor on top/ bottom of the primary monitor as below.

In these cases, if I retrieve the RECT of the secondary monitor, the "left" attribute or the x-coordinate of the position of the secondary monitor is 0. However, if I put the secondary monitor on the left as below, the x-coordinate of its postion is -1920 as its resolution is 1920*1080, and the ullArgument is around -1920+100 if I trigge the GID_ZOOM gesture with my two fingers close to each other.

When I place the second monitor on the right and the x-coordinate of the second monitor is 2560 according to the primary monitor's resolution(2560*1600), the ullArgument is around 2560+100 with the same operation. I've also tried to place secondary monitor on top of the primary one and align its left edge with the center of the latter to make the x-coordnate 1280. This time the ullArgument is around 1280+100.

According to the trials above, I think the ullArgument is the orinal distance of the two fingers plus the x-coordinate of the monitor's position
Darran Rowe 2,076 Reputation points

2024-10-17T13:20:23.98+00:00

The documentation for GID_ZOOM does state that all distances and positions are screen coordinates.

This implies something important on multimonitor systems. The top left of the primary display is seen as (0,0). Any monitor to the left of the primary display will have negative coordinates. I know this can be a bit difficult to grasp, but this is part of how the multi monitor system works in Windows, and it is documented.
孟轩郝 11 Reputation points

2024-10-17T16:29:53.01+00:00

I understand how the coordinate works for multimonitor systems, but I think the ullArgument for GID_ZOOM should represent the distance of the two touched points. This is the case when the screen touched is at (0,0) that the value is only related to the finger distance regard less of where the screen is touched. This also holds for the secondary monitor except that all the values are added by the screen's x-coordinate (-1920 in this case)

The numbers in the firgure represent the value retrieved by ullArgument
David Lowndes 2,640 Reputation points MVP

2024-10-17T16:57:50.84+00:00

Is there no such difference if the monitors are top/bottom i.e. the values aren't offset in the y direction as they are for you in the x?
Are your results consistent with different devices (assuming you have the ability to test with such)?
Do apps that support zoom work correctly where you see this issue?
孟轩郝 11 Reputation points

2024-10-18T03:24:10.5933333+00:00

There is no difference when the y-coordinate of the monitor's position changes, only the x-coordinate.

I have only one touch screen but I've tried it on other computers (two with windows 10 22H2, one with windows11 21H2 and my own with windows11 23H2 and all get the same result.

As it's usually the difference between "ullArgument"s retrieved from consecutive WM_GESUTRE message with GIZ_ZOOM is used for zooming the app, and this issue only add a constant value but not contribute to thier difference, most apps with zoom support should not be affected. But I do find some app's zoom function doesn't work on the secondary monitor when I place the monitor on the left.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-22T05:27:01.99+00:00

As this issue is complex, to resolve this issue as soon as possible, you can open an incident via Contact us tab at link below: https://developer.microsoft.com/en-us/windows/support/

Please choose the Technical Support - Coding/Debugging for Windows SDK for this issue. In-addition, if the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged.

Your answer

Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-17T02:54:15.76+00:00

Whether have you tried placing the secondary monitor on the right of the primary monitor to check the result?
孟轩郝 11 Reputation points

2024-10-17T05:26:24.9733333+00:00

yeah, and then the distance returned is about 2000-3000. Actually I've tried placing the secondary monitor on different positions and it seems that the x-coordinate of its position is added to the result
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-17T08:56:20.6966667+00:00

According to your description, is it only when you position the secondary monitor on the left of the primary monitor that the result is negative? And is it normal to place the secondary display in another position? Could you please tell us what do you mean "the x-coordinate of its position is added to the result"?
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-17T09:06:01.5166667+00:00

According to the Doc:GESTUREINFO structure:

For GID_PRESSANDTAP, it is the distance between the two points.

For gestures like GID_PRESSANDTAP, the distance between the two points is stored in the ullArguments member.

For another gesture, the coordinates of the gesture are included in the ptsLocation member. Could you please tell us how you get the distance between the two points.
孟轩郝 11 Reputation points

2024-10-17T09:40:12.8566667+00:00

The document says the ullArgument indicates the distance between the two points for GID_ZOOM. And I'm assuming the two points means the places which my two fingers touch the screen.
孟轩郝 11 Reputation points

2024-10-17T10:07:14.45+00:00

My primary monitor has a resolution of 25601600 and my secondary monitor has a resolution of 19201080. I've tried to trigger the GID_ZOOM gesture with my two fingers close to each other which should result in the ullArgument to be around 100. This holds if I let the second monitor duplicate the primary monitor, or place the secondary monitor on top/ bottom of the primary monitor as below.

In these cases, if I retrieve the RECT of the secondary monitor, the "left" attribute or the x-coordinate of the position of the secondary monitor is 0. However, if I put the secondary monitor on the left as below, the x-coordinate of its postion is -1920 as its resolution is 1920*1080, and the ullArgument is around -1920+100 if I trigge the GID_ZOOM gesture with my two fingers close to each other.

When I place the second monitor on the right and the x-coordinate of the second monitor is 2560 according to the primary monitor's resolution(2560*1600), the ullArgument is around 2560+100 with the same operation. I've also tried to place secondary monitor on top of the primary one and align its left edge with the center of the latter to make the x-coordnate 1280. This time the ullArgument is around 1280+100.

According to the trials above, I think the ullArgument is the orinal distance of the two fingers plus the x-coordinate of the monitor's position
Darran Rowe 2,076 Reputation points

2024-10-17T13:20:23.98+00:00

The documentation for GID_ZOOM does state that all distances and positions are screen coordinates.

This implies something important on multimonitor systems. The top left of the primary display is seen as (0,0). Any monitor to the left of the primary display will have negative coordinates. I know this can be a bit difficult to grasp, but this is part of how the multi monitor system works in Windows, and it is documented.
孟轩郝 11 Reputation points

2024-10-17T16:29:53.01+00:00

I understand how the coordinate works for multimonitor systems, but I think the ullArgument for GID_ZOOM should represent the distance of the two touched points. This is the case when the screen touched is at (0,0) that the value is only related to the finger distance regard less of where the screen is touched. This also holds for the secondary monitor except that all the values are added by the screen's x-coordinate (-1920 in this case)

The numbers in the firgure represent the value retrieved by ullArgument
David Lowndes 2,640 Reputation points MVP

2024-10-17T16:57:50.84+00:00

Is there no such difference if the monitors are top/bottom i.e. the values aren't offset in the y direction as they are for you in the x?
Are your results consistent with different devices (assuming you have the ability to test with such)?
Do apps that support zoom work correctly where you see this issue?
孟轩郝 11 Reputation points

2024-10-18T03:24:10.5933333+00:00

There is no difference when the y-coordinate of the monitor's position changes, only the x-coordinate.

I have only one touch screen but I've tried it on other computers (two with windows 10 22H2, one with windows11 21H2 and my own with windows11 23H2 and all get the same result.

As it's usually the difference between "ullArgument"s retrieved from consecutive WM_GESUTRE message with GIZ_ZOOM is used for zooming the app, and this issue only add a constant value but not contribute to thier difference, most apps with zoom support should not be affected. But I do find some app's zoom function doesn't work on the secondary monitor when I place the monitor on the left.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2024-10-22T05:27:01.99+00:00

As this issue is complex, to resolve this issue as soon as possible, you can open an incident via Contact us tab at link below: https://developer.microsoft.com/en-us/windows/support/

Please choose the Technical Support - Coding/Debugging for Windows SDK for this issue. In-addition, if the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged.

Share via

negative distance retrieved from GetGestureInfo

Your answer