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 <graham....@bigpond.com> 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 (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
