Hi Tom
Thanks for adding the Carbon SetCursorPos patch.
Wome feedback on your comment: "Thanks. It's only pitty that it does not produce
mouse events."
I could be mistaken, and appreciate correction, but think that SetCursorPos
SHOULD NOT send mouse events (on any platform).
That is from my use of SetCursorPos but perhaps there are other uses which would
want to generate mouse events.
For instance, a favorite control is what I call a TextSlider-- It displays a
Text value, and when you click-drag the control, it tracks like a vertical
slider, but rather than the text control moving on-screen, the number in the
text control just changes in response to vertical mouse movement. This kind of
control has been common in music programs since the 1980's. Many round knob
controls work similarly.
I hilite the textbox and hide the cursor (and pin the hidden cursor on the
textbox), or alternately leave the cursor visible and move it to the right of
the textbox and 'pin' its location, so that vertical drags cannot move long
distances on the screen. If the TextSlider control is near the top of the screen
and the user wants to drag the value from 10 to 1000, the value drag would stop
when the cursor hits the top of the screen, limiting the amount that the user
could drag in a single movement.
In that kind usage, it would be undesirable if SetCursorPos would send mouse
events. If my OnMouseMove notices that the user dragged up 5 pixels, and then
adds 5 to the control's value and updates the screen, and does SetCursorPos to
move the cursor back to its original location for further user dragging--
If the control's OnMouseMove SetCursorPos generates a mouse move down event,
then that new event would trigger OnMouseMove again, and 'undo' the user's drag,
subtracting 5 from the control value and returning the control back to the
original value.
Haven't traced the code, but am pretty sure that the PC Delphi and PC Lazarus
SetCursorPos does not generate mouse move events, otherwise my mouse-tracking
controls which use that trick, would never work.
Apple strongly disapproves programmatically moving the cursor, and I read
somewhere that they supplied the WarpCursorPos function to coddle video game
programs, which also need to keep the cursor on-screen for similar reasons that
my controls need. It is doubtful that game programmers would want mouse-move
events, for the same reasons I don't want em. It could 'undo' the purpose of the
SetCursorPos.
Sorry for such a boring message. Just wanted to point out that adding a mouse
move event to SetCursorPos might be undesirable.
Thanks for such great work!
jcjr
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
