Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
- Subject: Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
- From: Graham Cox <email@hidden>
- Date: Tue, 3 Nov 2009 22:54:44 +1100
On 03/11/2009, at 10:39 PM, Oleg Krupnov wrote:
There are basically two or three custom views of different class in
the window that need refresh. These views are totally custom, which
means I could of course implement the corresponding methods that would
explicitly refresh their state, but because the state depends on the
mouse position, the method would have to query the current mouse
position outside the event loop and then do the same thing as I do in
mouse moved event handler. That's why I thought I could spare on extra
code in all views and just send one fake mouse moved event to whatever
view is hovered, specifying the current mouse coordinate (i.e. no
actual coordinate change).
You seem to be forcing the view's state to be defined by the mouse
events, instead of letting the mouse events merely act as input to the
state change.
Let's say for argument's sake that your view has three states - off,
hover and on. Each one has a different appearance. Your view should
have a 'state' property that makes a note of the state it's in, and
calls -setNeedsDisplay: when it changes. The -drawRect: method queries
[self state] and draws accordingly. Then you'll have implemented the
different states without reference to the mouse position - you can
freely set the state by sending the view the -setState: message from
anywhere at any time and it will obey.
The next thing is to change state according to the mouse position. You
can do this using NSTrackingArea so that entering goes to hover,
exiting goes to off. On mouse down you can go to ON, and on mouse up
go to off (for example).
Now you can see how to change the state under any other condition, for
example when a lengthy operation starts and stops - just call -
setState: appropriately.
The mouse events should be an input to your view that changes its
state property, not part of its state property, as you seem to have.
That way you don't need to do anything skanky like posting events to
cause a state change - you have a well-defined method to do that.
Anyway, thanks for your recommendation. Is there any final argument
that would convince me that posting fake mouse moved events is a bad
idea? Some discouragement in the docs, or something?
Not as such, but it's just a case of recognising what is the right
tool for a job. Managing state is not what events are for - events may
cause a state change, but they are not themselves part of the view's
state. Separate the state property out and you should find getting the
effects you want much easier, because events can drive it, instead of
you needing to make events to indirectly change the state.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden