SendInput always moves mouse pointer to left top corner
I would like to programmatically synthesize mouse motion to a point (100,100) on a screen with code below, but it moves to left top side instead. What could be wrong?
#include "stdafx.h"
#include<Windows.h>
int main() {
INPUT input;
input.type = INPUT_MOUSE;
input.mi.dx = 100;
input.mi.dy = 100;
input.mi.dwFlags = MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE;
input.mi.mouseData = 0;
input.mi.dwExtraInfo = NULL;
input.mi.time = 0;
SendInput(1, &input, sizeof(INPUT));
return 0;
}
PS. I have compiled it in VS2017 on Windows 10x64. I have run the code on Win7 as well
PPS. When I remove MOUSEEVENTF_ABSOLUTE flag, it moves to relative position.
c++ winapi mouseevent
asked Feb 28 '18 at 10:11
LeoLeo
304112
add a comment |
I would like to programmatically synthesize mouse motion to a point (100,100) on a screen with code below, but it moves to left top side instead. What could be wrong?
#include "stdafx.h"
#include<Windows.h>
int main() {
INPUT input;
input.type = INPUT_MOUSE;
input.mi.dx = 100;
input.mi.dy = 100;
input.mi.dwFlags = MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE;
input.mi.mouseData = 0;
input.mi.dwExtraInfo = NULL;
input.mi.time = 0;
SendInput(1, &input, sizeof(INPUT));
return 0;
}
PS. I have compiled it in VS2017 on Windows 10x64. I have run the code on Win7 as well
PPS. When I remove MOUSEEVENTF_ABSOLUTE flag, it moves to relative position.
c++ winapi mouseevent
asked Feb 28 '18 at 10:11
LeoLeo
304112
add a comment |
I would like to programmatically synthesize mouse motion to a point (100,100) on a screen with code below, but it moves to left top side instead. What could be wrong?
#include "stdafx.h"
#include<Windows.h>
int main() {
INPUT input;
input.type = INPUT_MOUSE;
input.mi.dx = 100;
input.mi.dy = 100;
input.mi.dwFlags = MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE;
input.mi.mouseData = 0;
input.mi.dwExtraInfo = NULL;
input.mi.time = 0;
SendInput(1, &input, sizeof(INPUT));
return 0;
}
PS. I have compiled it in VS2017 on Windows 10x64. I have run the code on Win7 as well
PPS. When I remove MOUSEEVENTF_ABSOLUTE flag, it moves to relative position.
c++ winapi mouseevent
asked Feb 28 '18 at 10:11
LeoLeo
304112
I would like to programmatically synthesize mouse motion to a point (100,100) on a screen with code below, but it moves to left top side instead. What could be wrong?
#include "stdafx.h"
#include<Windows.h>
int main() {
INPUT input;
input.type = INPUT_MOUSE;
input.mi.dx = 100;
input.mi.dy = 100;
input.mi.dwFlags = MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE;
input.mi.mouseData = 0;
input.mi.dwExtraInfo = NULL;
input.mi.time = 0;
SendInput(1, &input, sizeof(INPUT));
return 0;
}
PS. I have compiled it in VS2017 on Windows 10x64. I have run the code on Win7 as well
PPS. When I remove MOUSEEVENTF_ABSOLUTE flag, it moves to relative position.
c++ winapi mouseevent
c++ winapi mouseevent
asked Feb 28 '18 at 10:11
LeoLeo
304112
asked Feb 28 '18 at 10:11
LeoLeo
304112
edited Feb 28 '18 at 10:22
Leo
asked Feb 28 '18 at 10:11
LeoLeo
304112
asked Feb 28 '18 at 10:11
LeoLeo
304112
asked Feb 28 '18 at 10:11
LeoLeo
304112
304112
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The API call follows documented behavior:
MOUSEEVENTF_ABSOLUTE: The dx and dy members contain normalized absolute coordinates. [...] see the following Remarks section.
Normalized coordinates are indeed described in the Remarks section:
If
MOUSEEVENTF_ABSOLUTEvalue is specified, dx and dy contain normalized absolute coordinates between 0 and 65,535. The event procedure maps these coordinates onto the display surface. Coordinate (0,0) maps onto the upper-left corner of the display surface; coordinate (65535,65535) maps onto the lower-right corner. In a multimonitor system, the coordinates map to the primary monitor.
To move the mouse to an absolute position, you first need to query the display surface size (e.g. through a call to GetMonitorInfor), and scale the coordinates appropriately.
The following function normalizes a point, given the point and display surface dimensions in device units as input:
POINT normalize(POINT const& pt_in_px, RECT const& display_size_in_px)
{
POINT pt_normalized{};
auto const width_in_px{ display_size_in_px.right - display_size_in_px.left };
auto const height_in_px{ display_size_in_px.bottom - display_size_in_px.top };
pt_normalized.x = ::MulDiv(pt_in_px.x, 65536, width_in_px);
pt_normalized.y = ::MulDiv(pt_in_px.y, 65536, height_in_px);
return pt_normalized;
}
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
Thank you! Because of small values of dx and dy in my data I have not noticed any move at all.
– Leo
Feb 28 '18 at 10:48
Haha, I just though: so this 'works' until we have 64k monitors. As if ever ;)
– JHBonarius
Feb 28 '18 at 10:56
@JHBonarius: This does work for 64k displays just fine. Only exception is the rounding performed byMulDiv, that starts to map the final rows and columns to 65536, once you get closer to coordinates with values 2^32 - 1. For a hypothetical display with resolution 64k x 64k the function produces perfectly valid values.
– IInspectable
Feb 28 '18 at 11:03
Yes, sorry. I meant after 64k, so 128k etc ;). Just very hypothetical.. Imagine the bandwidth of a theoretical 128k*128k*120fps monitor... 2 TB/s xD
– JHBonarius
Feb 28 '18 at 11:53
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f49026921%2fsendinput-always-moves-mouse-pointer-to-left-top-corner%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The API call follows documented behavior:
MOUSEEVENTF_ABSOLUTE: The dx and dy members contain normalized absolute coordinates. [...] see the following Remarks section.
Normalized coordinates are indeed described in the Remarks section:
If
MOUSEEVENTF_ABSOLUTEvalue is specified, dx and dy contain normalized absolute coordinates between 0 and 65,535. The event procedure maps these coordinates onto the display surface. Coordinate (0,0) maps onto the upper-left corner of the display surface; coordinate (65535,65535) maps onto the lower-right corner. In a multimonitor system, the coordinates map to the primary monitor.
To move the mouse to an absolute position, you first need to query the display surface size (e.g. through a call to GetMonitorInfor), and scale the coordinates appropriately.
The following function normalizes a point, given the point and display surface dimensions in device units as input:
POINT normalize(POINT const& pt_in_px, RECT const& display_size_in_px)
{
POINT pt_normalized{};
auto const width_in_px{ display_size_in_px.right - display_size_in_px.left };
auto const height_in_px{ display_size_in_px.bottom - display_size_in_px.top };
pt_normalized.x = ::MulDiv(pt_in_px.x, 65536, width_in_px);
pt_normalized.y = ::MulDiv(pt_in_px.y, 65536, height_in_px);
return pt_normalized;
}
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
Thank you! Because of small values of dx and dy in my data I have not noticed any move at all.
– Leo
Feb 28 '18 at 10:48
Haha, I just though: so this 'works' until we have 64k monitors. As if ever ;)
– JHBonarius
Feb 28 '18 at 10:56
@JHBonarius: This does work for 64k displays just fine. Only exception is the rounding performed byMulDiv, that starts to map the final rows and columns to 65536, once you get closer to coordinates with values 2^32 - 1. For a hypothetical display with resolution 64k x 64k the function produces perfectly valid values.
– IInspectable
Feb 28 '18 at 11:03
Yes, sorry. I meant after 64k, so 128k etc ;). Just very hypothetical.. Imagine the bandwidth of a theoretical 128k*128k*120fps monitor... 2 TB/s xD
– JHBonarius
Feb 28 '18 at 11:53
add a comment |
The API call follows documented behavior:
MOUSEEVENTF_ABSOLUTE: The dx and dy members contain normalized absolute coordinates. [...] see the following Remarks section.
Normalized coordinates are indeed described in the Remarks section:
If
MOUSEEVENTF_ABSOLUTEvalue is specified, dx and dy contain normalized absolute coordinates between 0 and 65,535. The event procedure maps these coordinates onto the display surface. Coordinate (0,0) maps onto the upper-left corner of the display surface; coordinate (65535,65535) maps onto the lower-right corner. In a multimonitor system, the coordinates map to the primary monitor.
To move the mouse to an absolute position, you first need to query the display surface size (e.g. through a call to GetMonitorInfor), and scale the coordinates appropriately.
The following function normalizes a point, given the point and display surface dimensions in device units as input:
POINT normalize(POINT const& pt_in_px, RECT const& display_size_in_px)
{
POINT pt_normalized{};
auto const width_in_px{ display_size_in_px.right - display_size_in_px.left };
auto const height_in_px{ display_size_in_px.bottom - display_size_in_px.top };
pt_normalized.x = ::MulDiv(pt_in_px.x, 65536, width_in_px);
pt_normalized.y = ::MulDiv(pt_in_px.y, 65536, height_in_px);
return pt_normalized;
}
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
Thank you! Because of small values of dx and dy in my data I have not noticed any move at all.
– Leo
Feb 28 '18 at 10:48
Haha, I just though: so this 'works' until we have 64k monitors. As if ever ;)
– JHBonarius
Feb 28 '18 at 10:56
@JHBonarius: This does work for 64k displays just fine. Only exception is the rounding performed byMulDiv, that starts to map the final rows and columns to 65536, once you get closer to coordinates with values 2^32 - 1. For a hypothetical display with resolution 64k x 64k the function produces perfectly valid values.
– IInspectable
Feb 28 '18 at 11:03
Yes, sorry. I meant after 64k, so 128k etc ;). Just very hypothetical.. Imagine the bandwidth of a theoretical 128k*128k*120fps monitor... 2 TB/s xD
– JHBonarius
Feb 28 '18 at 11:53
add a comment |
The API call follows documented behavior:
MOUSEEVENTF_ABSOLUTE: The dx and dy members contain normalized absolute coordinates. [...] see the following Remarks section.
Normalized coordinates are indeed described in the Remarks section:
If
MOUSEEVENTF_ABSOLUTEvalue is specified, dx and dy contain normalized absolute coordinates between 0 and 65,535. The event procedure maps these coordinates onto the display surface. Coordinate (0,0) maps onto the upper-left corner of the display surface; coordinate (65535,65535) maps onto the lower-right corner. In a multimonitor system, the coordinates map to the primary monitor.
To move the mouse to an absolute position, you first need to query the display surface size (e.g. through a call to GetMonitorInfor), and scale the coordinates appropriately.
The following function normalizes a point, given the point and display surface dimensions in device units as input:
POINT normalize(POINT const& pt_in_px, RECT const& display_size_in_px)
{
POINT pt_normalized{};
auto const width_in_px{ display_size_in_px.right - display_size_in_px.left };
auto const height_in_px{ display_size_in_px.bottom - display_size_in_px.top };
pt_normalized.x = ::MulDiv(pt_in_px.x, 65536, width_in_px);
pt_normalized.y = ::MulDiv(pt_in_px.y, 65536, height_in_px);
return pt_normalized;
}
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
The API call follows documented behavior:
MOUSEEVENTF_ABSOLUTE: The dx and dy members contain normalized absolute coordinates. [...] see the following Remarks section.
Normalized coordinates are indeed described in the Remarks section:
If
MOUSEEVENTF_ABSOLUTEvalue is specified, dx and dy contain normalized absolute coordinates between 0 and 65,535. The event procedure maps these coordinates onto the display surface. Coordinate (0,0) maps onto the upper-left corner of the display surface; coordinate (65535,65535) maps onto the lower-right corner. In a multimonitor system, the coordinates map to the primary monitor.
To move the mouse to an absolute position, you first need to query the display surface size (e.g. through a call to GetMonitorInfor), and scale the coordinates appropriately.
The following function normalizes a point, given the point and display surface dimensions in device units as input:
POINT normalize(POINT const& pt_in_px, RECT const& display_size_in_px)
{
POINT pt_normalized{};
auto const width_in_px{ display_size_in_px.right - display_size_in_px.left };
auto const height_in_px{ display_size_in_px.bottom - display_size_in_px.top };
pt_normalized.x = ::MulDiv(pt_in_px.x, 65536, width_in_px);
pt_normalized.y = ::MulDiv(pt_in_px.y, 65536, height_in_px);
return pt_normalized;
}
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
edited Feb 28 '18 at 10:45
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
answered Feb 28 '18 at 10:32
IInspectableIInspectable
26.4k54498
26.4k54498
Thank you! Because of small values of dx and dy in my data I have not noticed any move at all.
– Leo
Feb 28 '18 at 10:48
Haha, I just though: so this 'works' until we have 64k monitors. As if ever ;)
– JHBonarius
Feb 28 '18 at 10:56
@JHBonarius: This does work for 64k displays just fine. Only exception is the rounding performed byMulDiv, that starts to map the final rows and columns to 65536, once you get closer to coordinates with values 2^32 - 1. For a hypothetical display with resolution 64k x 64k the function produces perfectly valid values.
– IInspectable
Feb 28 '18 at 11:03
Yes, sorry. I meant after 64k, so 128k etc ;). Just very hypothetical.. Imagine the bandwidth of a theoretical 128k*128k*120fps monitor... 2 TB/s xD
– JHBonarius
Feb 28 '18 at 11:53
add a comment |
Thank you! Because of small values of dx and dy in my data I have not noticed any move at all.
– Leo
Feb 28 '18 at 10:48
Haha, I just though: so this 'works' until we have 64k monitors. As if ever ;)
– JHBonarius
Feb 28 '18 at 10:56
@JHBonarius: This does work for 64k displays just fine. Only exception is the rounding performed byMulDiv, that starts to map the final rows and columns to 65536, once you get closer to coordinates with values 2^32 - 1. For a hypothetical display with resolution 64k x 64k the function produces perfectly valid values.
– IInspectable
Feb 28 '18 at 11:03
Yes, sorry. I meant after 64k, so 128k etc ;). Just very hypothetical.. Imagine the bandwidth of a theoretical 128k*128k*120fps monitor... 2 TB/s xD
– JHBonarius
Feb 28 '18 at 11:53
Thank you! Because of small values of dx and dy in my data I have not noticed any move at all.
– Leo
Feb 28 '18 at 10:48
Thank you! Because of small values of dx and dy in my data I have not noticed any move at all.
– Leo
Feb 28 '18 at 10:48
Haha, I just though: so this 'works' until we have 64k monitors. As if ever ;)
– JHBonarius
Feb 28 '18 at 10:56
Haha, I just though: so this 'works' until we have 64k monitors. As if ever ;)
– JHBonarius
Feb 28 '18 at 10:56
@JHBonarius: This does work for 64k displays just fine. Only exception is the rounding performed by
MulDiv, that starts to map the final rows and columns to 65536, once you get closer to coordinates with values 2^32 - 1. For a hypothetical display with resolution 64k x 64k the function produces perfectly valid values.– IInspectable
Feb 28 '18 at 11:03
@JHBonarius: This does work for 64k displays just fine. Only exception is the rounding performed by
MulDiv, that starts to map the final rows and columns to 65536, once you get closer to coordinates with values 2^32 - 1. For a hypothetical display with resolution 64k x 64k the function produces perfectly valid values.– IInspectable
Feb 28 '18 at 11:03
Yes, sorry. I meant after 64k, so 128k etc ;). Just very hypothetical.. Imagine the bandwidth of a theoretical 128k*128k*120fps monitor... 2 TB/s xD
– JHBonarius
Feb 28 '18 at 11:53
Yes, sorry. I meant after 64k, so 128k etc ;). Just very hypothetical.. Imagine the bandwidth of a theoretical 128k*128k*120fps monitor... 2 TB/s xD
– JHBonarius
Feb 28 '18 at 11:53
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f49026921%2fsendinput-always-moves-mouse-pointer-to-left-top-corner%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
