news:3a3044e2.167364667@news.terra.com.br...

Use the SetCursorPos function in the Win API. IMO programmatically moving
the mouse cursor around isn't a very good idea.

Hello!

How to SET mouse to desired postion?
I have X and Y and I want my mouse there but don't know how to put
pointer there from runtime.

TIA

"Bruce Roberts" <b...@bounceitattcanada.xnet> skrev i melding
news:NLYX5.3838$t3.4621@tor-nn1.netcom.ca...

...unless you actually need to set the mouse position for some
reason....

--
Bjoerge Saether
Consultant / Developer
Asker, Norway
bsaether.removet...@online.no (remove the obvious)

There is a global variable Mouse, with a CursorPos property which wraps the
API call.  Just set Mouse.CursorPos:=point(x,y);

_________________________
Gary
http://www.delphiforfun.org
_________________________

news:3a3044e2.167364667@news.terra.com.br...

news:vL5Y5.3140

Other than some kind of calibration function can you suggest what those
reasons might be?

news:vL5Y5.3140

In article <KqiY5.4216$t3.5...@tor-nn1.netcom.ca>, "Bruce Roberts"

As a lurker on this thread, strangely enough I have just had reason to move the
mouse myself for GUI reasons. However the description sounds much much more
complicated than it is in use.

I have a 15 row / 2 column string grid, the first column has 15 entries, the
second column has from 4 to 10 entries. The user needs to associate the entries
in the second column with those in the first(they are originally spaced out).
But the entries in the second column must always be in the same order, and if a
moving entry "catches up" with another entry then both must move if they can.

When the user clicks on a cell in the second column, an UpDown control appears
against the row of the cell. By clicking up or down the cell may be moved up or
down. When it has moved, the UpDown control must move with it, so it is still
against the selected/moved row ready for further movement.

But of course the mouse which was over the UpDown button is now either below
(entry going up) or above (entry going down). So I move the mouse up or down by
the amount the UpDown control has moved. All the user has then to do to move
the entry again is click the mouse button.

But I would agree with you that only rarely is it needed.

Another use I saw was an "intelligent" mouse pointer. When the user tabbed
between controls, then the mouse was programmatically moved to be over a
clickable control ready to click. Seemed clever but not terible useful <g>.

Alan Lloyd
alangll...@aol.com

Want reason? Ok, I will explain.

One of my clients has racing motocycle and a driver. In addition, he
has a Infra Red device which is plugged into mouse port, positioned at
the track and when beam is cut (motocycle passes IR line), it sends
onMouseDown signal.

When you plug in this device, you loose control of the mouse
(obviously).
Application has menu, buttons and all sort of necessary things which
you can do with mouse or keyboard when IR device is unplugged.

As result of all this, I need to place mouse over a exact control when
timer is initiated, so device can log LAP time on mouseDown event.
When timer is stopped, I release mouse, and when he plug in mouse
again, he can use it normally.
IR device cannot be on any other port as it is piece of shit and all
other thoughts, like: "plug it there, unplug here, see this, see that"
are out of consideration. I have only one option: Mouse port,
onMouseDown event.

Sounds reasonable?

On Fri, 8 Dec 2000 23:18:31 -0500, "Bruce Roberts"

"Bruce Roberts" <b...@bounceitattcanada.xnet> skrev i melding
news:KqiY5.4216$t3.5395@tor-nn1.netcom.ca...

I've been creating a kind of up/down control where you right-click a
"lever", and drag the mouse up or down to set values. There should be no
limitation to this movement, and it should work likewise if the control
is at the top of your form or at the bottom. The best solution was
actually to set mouse cursor to an invisible one, and let the mouse
cursor roll over, being set to opposite edge by SetCursorPos whenever it
reached the screen bounds.

From time to time, there may actually be a good idea to move the mouse
cursor to the 'OK' button, if the dialog box for some reason has to be
placed at a distance from the position where the mouse was clicked and
caused the box to appear. Personally I like this behaviour with modal
dialogs.

--
Bjoerge Saether
Consultant / Developer
Asker, Norway
bsaether.removet...@online.no (remove the obvious)

news:20001209095544.08022.00000466@nso-mg.aol.com...

<g>.

This is just the kind of behavior that I'm not fond of. When I first started
with Windows I thought it was a good idea. The problem is, however, that
each time one moves the mouse programmatically the user has to re-set the
current cursor position that they typically maintain in their mind. In a
uni-program environment that's not so bad, in Windows its a real annoyance.

news:3a32a3cb.13488355@news.terra.com.br...

Your solution does. The problem device, as you've noted, doesn't.

news:dPxY5.95

A technical qualification only :-). I don't have a problem programatically
moving invisible mice.

If by modal dialogs you mean those (IMO) really {*word*193} and bothersome message
boxes that some programs pop-up on any excuse, I can see your point. For
other dialogs I'd suggest that in most cases form placement and design need
to be re-examined. If a form pop's up whose first action is to click an OK
button, then why is the form being displayed in the first place? If the
reason is because confirmation for a particularly serious action is
required, then doesn't one really want the user to pause and think about
what they are doing? In these situations, placing the mouse over the button
just encourages users to click before they read. If there are entry fields
on the form, then the user will be using the keyboard, so making the OK
button the default alleviates the need to even move the mouse.

As I suggested to Alan, whenever a program moves the mouse it forces the
user to re-evaluate their mental and physical mouse positions. IMO this
imposes an unnecessary task on the user, especially new users who are not
familiar with the software and who may have to take several seconds to find
the mouse cursor on their nice new 21" monitor.

In article <T8FY5.6060$t3.6...@tor-nn1.netcom.ca>, "Bruce Roberts"

In general I agree with your strictures for many occasions when the mouse is
programmatically moved. But your argument is not really applicable for the
"intelligent" mouse (although I don't like it). The user has chosen to move
focus by pressing tab, it is logical to presume that he would want the mouse to
be over the focussed control, otherwise why did he press the tab key.

Alan LLoyd
alangll...@aol.com