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: Oleg Krupnov <email@hidden>
- Date: Tue, 3 Nov 2009 14:15:00 +0200
Graham,
Maybe I'm not speaking clearly, but that's exactly what I'm trying to
do -- use a mouse event to cause a state change, but in this case the
mouse event would be fake. Mouse position is in no way part of the
view's state. I just want that at particular moment the view's state
becomes synchronized with the current mouse position, as if the mouse
did move.
There are multiple items in the view, and the hovered one of the items
should be highlighted. When the mouse event arrives, the view performs
hit testing of its items and determines which of the items is hovered.
If I make a setState method as you suggest, I would have to specify
which item to highlight. This would break the view's encapsulation,
because I would have to perform item hit testing externally.
Again, I could implement a custom "refresh" method in each view, which
would query the current mouse position and call the mouse moved event
handler, but in addition to the extra code, before calling this method
I would have to hit test the window to determine which view is
currently hovered, i.e. basically repeat what NSApp and NSWindow
normally do when dispatching mouse events. That's why I thought
simulating a mouse move event could be justified.
Also, beside this discussion of design, I'd appreciate to find out why
postEvent actually did not work, just to improve my understanding of
Cocoa, even if I decide against using this approach.
Thanks!
On Tue, Nov 3, 2009 at 1:54 PM, Graham Cox <email@hidden> wrote:
>
> 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