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 protected]) 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 [email protected]
