On Aug 4, 2009, at 06:51, Björn Bollensdorff wrote:
I'm trying to implement a remote control for an application. The
mouse data is send to the application through a socket which is
checked regularly by a function triggered by a NSTimer. The data is
then transfered into the corresponding CGEvent. Interestingly this
works as long as I do not perform a mouse down on a NSButton or
something similar. If I hit an active element the NSTimer does not
fire anymore.
I simplified the problem as much as possible getting to the
following small application that does not use socket communication
anymore.
There are two buttons, a checkbox and a label. The first button
triggers the mouse event and the second is the target. The checkbox
sets the position of the mouseEvent. If it is unchecked the mouse
down and up are performed somewhere in the applications window. If
it is checked they are performed on the target button. To see if the
action bound to the target button was triggered the label changes.
If the first button is activated I generate a CGEvent MouseDown and
start a NSTimer. The NSTimer triggers a function that generates a
CGEvent MouseUp. The behavior of the small application now depends
on where the MouseDown is performed. If there is no element
underneath it, the NSTimer fires and the Mouse Up is performed. If
an element is hit the NSTimer does not fire until I manually hit the
mouse button.
I'm using CGEventCreateMouseEvent to create the MouseEvent and
CGEventPost to post the mouse event. I tried CGPostMouseEvent, too,
getting the same result.
Does anybody know how to can resolve that problem?
You're going to have to come up with a different solution, something
that doesn't depend on a NSTimer.
The problem is that it's perfectly legal for something (e.g. a
NSButton responding to a mouse-down) to use a local, modal event loop
-- a "while" loop, not a NSRunLoop -- using
nextEventMatchingMask:untilDate:inMode:dequeue: to get the events it's
interested in, and during that loop timers won't run. Depending on the
mode, it may also be that some event types are left in the queue, or
unknown events may even be discarded (not likely by NSButton, but in
the general case), so you can't even assume network communications
will continue, and you can't come up with a solution involving custom
event types.
I suspect you'll have a similar problem with dragging scroll bars, and
perhaps with selecting things in controls.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
