Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
Oleg, had you thought of doing something like adding -isSelectionValid and -setSelectionValid: methods to your controller class? The view would always keep track of the mouse state, tell the controller what the current selection is when the mouse moves, but won't update itself or respond to mouse clicks while the lengthy operation is in progress. No fake events since the view has been tracking the real mouse all along. Just call -setNeedsDisplay: inside -setSelectionValid: to automagically get the view to redraw itself to reflect the current mouse state. steve On Nov 3, 2009, at 5:46 AM, Oleg Krupnov wrote: Graham, I really appreciate you taking your time to write such detailed posts for me, but what I am trying to say is that I am doing everything exactly as you suggest, following the best design patterns (I think). There is a controller and it maintains the selection. The view only draws the selection in its drawRect, and during drawRect it queries the selection from the controller. The view can also cause the selection to change in response to mouse input. That's when the view performs hit testing of its items, in its mouseMoved handler. Then the view asks the controller to change the current selection. Then the controller calls back the view telling that selection has changed, and the view calls setNeedsDisplay on itself. The way the items are displayed, and therefore also how they are hit-tested, is encapsulated inside the view. In other words, the controller and the model don't have to know how the items appear and how to hit test them in each kind of view. The view is responsible to process the mouse events. This all is pretty standard MVC pattern, I believe. No problem with that. The need to refresh the view after animation is rather a tiny exception from the otherwise solid implementation. And I am considering the fake mouse event because it seems the most natural and straightforward way of changing the state of the system in this case. Think of it this way: while the animation is in progress, the user may be moving the mouse around, but all those events were ignored, and what matters is only the last position of the mouse at the moment when the animation ends. So in a sense, the fake mouse move event is not so much fake, but a single consolidated mouse event of all those events. The way my system should respond to this event is exactly the same as to an ordinary, non-fake mouse event. If I don't generate that fake event and use some explicit methods, I would have to do the following: 1. in controller, determine which view the mouse currently is over (hit test the window) 2. localize the coordinate to that view and ask the view to hit test its items for the coordinate 3. set the controller's selection to that item This all, and exactly this, would happen all by itself, by the already existing code, in case if I sent the fake mouse moved event. On Tue, Nov 3, 2009 at 3:09 PM, Graham Cox wrote: On 03/11/2009, at 11:15 PM, Oleg Krupnov wrote: 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. But why? State is an independent variable. It is coupled to the mouse location in your case, but it's independent nevertheless. If you like, state is the part of the view's output (because it causes the visual appearance to change) whereas events are always input. Don't conflate them - views are designed to keep the input (events) and outputs (drawing) handled in two completely independent phases. 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. I don't really follow this. At some point any hit testing does have to be done externally, if you have multiple objects, either by you or by AppKit. Doing it yourself is easy, and I strongly recommend that approach as follows: 1. main view gets the localised mouse location. 2. it iterates over all of its sub-objects representing the items and asks each one to test itself against the mouse position which is passed to it. 3. The first item that returns yes is sent the appropriate - setState: to highlight it (and the main view also keeps track of this one as "the selected item"). 4. the -setState: method invalidates the drawing area covered by the object. 5. drawing deals with the appearance change. This is the classic, no-nonsense, norm
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
On 03.11.2009, at 14:56, Graham Cox wrote: In other words, instead of faking a mouse event in order to get the mouse position into that code, just factor that part out and give it the mouse position at the end. You can get that using - mouseLocationOutsideOfEventStream. Converting it to local coordinates is a simple call, far simpler than trying to build a mouse event. Also, faking mouse events could cause all sorts of weird side effects, like making VoiceOver unnecessarily read out some item's text, or whatever. You do not want to do this. Also, this way if you ever need to behave differently in the real mouse-over case than in the other, you can easily change one method that calls your selectItemAtPoint: method (or whatever you call it), while not changing the other. If you send a fake mouse event, you're discarding the information where this "mouse movement" came from. Also, look into NSNotifications. You can use a notification to send out a general "progress finished" message and all views that need to know of it can then subscribe to that notification without the sender having to know about it. Of course, if you're dealing with views and a progress window, your views should probably just listen for window activation changes, or track mouse movements even while they're in the background (they wouldn't draw a highlight while they're in an inactive window, but that doesn't mean they can't update their internal "selected part" instance variable). Cheers, -- Uli Kusterer "The witnesses of TeachText are everywhere..." ___ 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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
On 04/11/2009, at 12:46 AM, Oleg Krupnov wrote: 1. in controller, determine which view the mouse currently is over (hit test the window) 2. localize the coordinate to that view and ask the view to hit test its items for the coordinate 3. set the controller's selection to that item This all, and exactly this, would happen all by itself, by the already existing code, in case if I sent the fake mouse moved event. OK, sounds to me that all you need to do is a little factoring. Factor out the code that takes a mouse position and does the hit-testing and selection maintenance into a new method. Call this code from your mouse moved handler. Also call it with the current mouse position at the end of your animation. Job jobbed. In other words, instead of faking a mouse event in order to get the mouse position into that code, just factor that part out and give it the mouse position at the end. You can get that using - mouseLocationOutsideOfEventStream. Converting it to local coordinates is a simple call, far simpler than trying to build a mouse event. --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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
Graham, I really appreciate you taking your time to write such detailed posts for me, but what I am trying to say is that I am doing everything exactly as you suggest, following the best design patterns (I think). There is a controller and it maintains the selection. The view only draws the selection in its drawRect, and during drawRect it queries the selection from the controller. The view can also cause the selection to change in response to mouse input. That's when the view performs hit testing of its items, in its mouseMoved handler. Then the view asks the controller to change the current selection. Then the controller calls back the view telling that selection has changed, and the view calls setNeedsDisplay on itself. The way the items are displayed, and therefore also how they are hit-tested, is encapsulated inside the view. In other words, the controller and the model don't have to know how the items appear and how to hit test them in each kind of view. The view is responsible to process the mouse events. This all is pretty standard MVC pattern, I believe. No problem with that. The need to refresh the view after animation is rather a tiny exception from the otherwise solid implementation. And I am considering the fake mouse event because it seems the most natural and straightforward way of changing the state of the system in this case. Think of it this way: while the animation is in progress, the user may be moving the mouse around, but all those events were ignored, and what matters is only the last position of the mouse at the moment when the animation ends. So in a sense, the fake mouse move event is not so much fake, but a single consolidated mouse event of all those events. The way my system should respond to this event is exactly the same as to an ordinary, non-fake mouse event. If I don't generate that fake event and use some explicit methods, I would have to do the following: 1. in controller, determine which view the mouse currently is over (hit test the window) 2. localize the coordinate to that view and ask the view to hit test its items for the coordinate 3. set the controller's selection to that item This all, and exactly this, would happen all by itself, by the already existing code, in case if I sent the fake mouse moved event. On Tue, Nov 3, 2009 at 3:09 PM, Graham Cox wrote: > > On 03/11/2009, at 11:15 PM, Oleg Krupnov wrote: > >> 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. > > But why? State is an independent variable. It is coupled to the mouse > location in your case, but it's independent nevertheless. If you like, state > is the part of the view's output (because it causes the visual appearance to > change) whereas events are always input. Don't conflate them - views are > designed to keep the input (events) and outputs (drawing) handled in two > completely independent phases. > >> 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. > > I don't really follow this. At some point any hit testing does have to be > done externally, if you have multiple objects, either by you or by AppKit. > Doing it yourself is easy, and I strongly recommend that approach as > follows: > > 1. main view gets the localised mouse location. > 2. it iterates over all of its sub-objects representing the items and asks > each one to test itself against the mouse position which is passed to it. > 3. The first item that returns yes is sent the appropriate -setState: to > highlight it (and the main view also keeps track of this one as "the > selected item"). > 4. the -setState: method invalidates the drawing area covered by the object. > 5. drawing deals with the appearance change. > > This is the classic, no-nonsense, normal everyday approach. Tracking to get > each individual object to handle its own mouse tracking independently is not > only going to be hard to get right, it's likely to have poor performance as > well. All you're really doing is shunting the mouse position detection and > hit-testing off onto multiple NSTrackingAreas - it still has to be done and > it's unlikely to be faster than a simple approach that can take advantage of > knowledge of how your sub-objects work. > > (Side discussion: In fact, an improved design than the above where state is > linked to the concept of selection is to maintai
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
On 03/11/2009, at 11:15 PM, Oleg Krupnov wrote: 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. But why? State is an independent variable. It is coupled to the mouse location in your case, but it's independent nevertheless. If you like, state is the part of the view's output (because it causes the visual appearance to change) whereas events are always input. Don't conflate them - views are designed to keep the input (events) and outputs (drawing) handled in two completely independent phases. 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. I don't really follow this. At some point any hit testing does have to be done externally, if you have multiple objects, either by you or by AppKit. Doing it yourself is easy, and I strongly recommend that approach as follows: 1. main view gets the localised mouse location. 2. it iterates over all of its sub-objects representing the items and asks each one to test itself against the mouse position which is passed to it. 3. The first item that returns yes is sent the appropriate -setState: to highlight it (and the main view also keeps track of this one as "the selected item"). 4. the -setState: method invalidates the drawing area covered by the object. 5. drawing deals with the appearance change. This is the classic, no-nonsense, normal everyday approach. Tracking to get each individual object to handle its own mouse tracking independently is not only going to be hard to get right, it's likely to have poor performance as well. All you're really doing is shunting the mouse position detection and hit-testing off onto multiple NSTrackingAreas - it still has to be done and it's unlikely to be faster than a simple approach that can take advantage of knowledge of how your sub-objects work. (Side discussion: In fact, an improved design than the above where state is linked to the concept of selection is to maintain a separate list of the selected items. When the items are drawn, pass them the selected state on the fly by testing if they belong to the selection set or not. This avoids the maintenance of two state variables that need to be synchronised - one to mean 'this object is part of my selection' and another one within the object that indicates 'highlighted'. If you don't have to keep those two in synch they can never get out of synch, and management of the selection becomes independent of the objects that are selected themselves, which shouldn't really care, other than to draw differently accordingly). 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. This sounds backwards. Instead, just pass the mouse position down to the sub-object as needed, usually to perform a hit-test. (It's good for each object to implement its own hit-test method because you can customise it for different classes if necessary). The main view that contains all these other objects should act as a controller, responding to mouse events and asking the relevant objects to change state. If you find this repugnant for some reason (not sure why, it's what nearly all drawing apps actually do), another option is to make each sub-object a NSView subclass in its own right, so that the normal hit- testing and mouse dispatch is done for you. But this approach *is* discouraged by the docs for performance reasons - it's better to keep your sub-objects lightweight and let the main view do the work of grovelling over them. But even NSView has a -hitTest: method. 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. Well, I have successfully posted mouse-up events in the (rare) situation I described, but I filled in all the parameters, so maybe Dave's suggestion is right - you have to make sure the event is well- f
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
Dave, I already tried CGEventPost() but it does not seem to work either -- just nothing happens. I'd appreciate an example of working code, I haven't been able to find any. I also tried CGPostMouseEvent(). This works, but in a weird way -- it actually moves the mouse cursor (kind of a too low-level thing), which is not my intention, but even despite that, the corresponding mouse moved event still does not occur in the NSApp, which puzzles me. Besides I heard this function is deprecated in Snow Leopard, so I'd not like to use it. Thanks On Tue, Nov 3, 2009 at 2:33 PM, Dave Keck wrote: > Untested suggestion: when a real mouse moved event occurs, NSLog it > and duplicate its arguments exactly. Perhaps the '0' arguments are why > it's not working. > > If that doesn't do the trick, you'll probably have to drop to a lower > level, such as CGEventPost(). > > ... but Graham's right - there's probably a better way :) > ___ 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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
Untested suggestion: when a real mouse moved event occurs, NSLog it and duplicate its arguments exactly. Perhaps the '0' arguments are why it's not working. If that doesn't do the trick, you'll probably have to drop to a lower level, such as CGEventPost(). ... but Graham's right - there's probably a better way :) ___ 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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
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 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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
Thanks Graham, 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). The lengthy operation is an animation. During the animation, the mouse moved events are absorbed, so that when it is done, the state of the views do not correspond to the current mouse position, and a refresh is needed. Yes, I always use NSTrackingArea, and I don't use any hacks there. I expected that the fake mouse moved event that I post would get dispatched as a normal mouse event and tracked by the tracking area. 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? Oleg. On Tue, Nov 3, 2009 at 12:07 PM, Graham Cox wrote: > > On 03/11/2009, at 8:48 PM, Oleg Krupnov wrote: > >> As I said, I am trying to refresh the state of the view after a >> lengthy operation is complete. > > No disrespect, but you did not say that - this is the first mention of a > "lengthy operation". How lengthy? What is it?. Not sure why the coyness but > if you want help you have to be helpful. > > >> By "state" I mean that the item in the >> view on which the mouse is hovered, should highlight. > > Why not just tell the view to sort itself out when the "lengthy operation" > completes? Just send it a message and implement whatever you need to do to > fix it up. > > >> Also, if I don't >> refresh, the view will not respond to the following mouse down event, >> unless it is preceded with another mouse move event (because the view >> only respond to clicks if there is a highlighted item). > > Well, that doesn't sound right. Are you sure there isn't some other bug > causing that? > >> There are >> multiple views of different kind > > What kind? Are they custom views of your own design? In which case you can > do whatever you want, you are not constrained by the architecture of > controls or other built-in views. > > >> in the window, each with its own kind >> of state. I'd like the currently hovered view to refresh its state, as >> if it received a regular mouse move event. I thought imititating the >> mouse move event would be the most straightforward and simple way. Was >> I wrong? > > Hard to be sure without seeing any code, but on the face of it, yes, I think > this is wrong. You normally don't need to post events to make things happen. > There is a situation where you might need to post a mouse-up if you are > implementing your own tracking loop inside a view that expects mouse > down/move/up events and the mouse up is expected to balance the mouse down > and your inner tracking loop has already swallowed it, but those cases are > pretty unusual and it doesn't sound like yours is like that. > > How are you doing the hovering? Using NSTrackingArea (or tracking rects) is > a good solution - trying to trap & dispatch mouse events in a loop is not. > > --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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
On 03/11/2009, at 8:48 PM, Oleg Krupnov wrote: As I said, I am trying to refresh the state of the view after a lengthy operation is complete. No disrespect, but you did not say that - this is the first mention of a "lengthy operation". How lengthy? What is it?. Not sure why the coyness but if you want help you have to be helpful. By "state" I mean that the item in the view on which the mouse is hovered, should highlight. Why not just tell the view to sort itself out when the "lengthy operation" completes? Just send it a message and implement whatever you need to do to fix it up. Also, if I don't refresh, the view will not respond to the following mouse down event, unless it is preceded with another mouse move event (because the view only respond to clicks if there is a highlighted item). Well, that doesn't sound right. Are you sure there isn't some other bug causing that? There are multiple views of different kind What kind? Are they custom views of your own design? In which case you can do whatever you want, you are not constrained by the architecture of controls or other built-in views. in the window, each with its own kind of state. I'd like the currently hovered view to refresh its state, as if it received a regular mouse move event. I thought imititating the mouse move event would be the most straightforward and simple way. Was I wrong? Hard to be sure without seeing any code, but on the face of it, yes, I think this is wrong. You normally don't need to post events to make things happen. There is a situation where you might need to post a mouse-up if you are implementing your own tracking loop inside a view that expects mouse down/move/up events and the mouse up is expected to balance the mouse down and your inner tracking loop has already swallowed it, but those cases are pretty unusual and it doesn't sound like yours is like that. How are you doing the hovering? Using NSTrackingArea (or tracking rects) is a good solution - trying to trap & dispatch mouse events in a loop is not. --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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
As I said, I am trying to refresh the state of the view after a lengthy operation is complete. By "state" I mean that the item in the view on which the mouse is hovered, should highlight. Also, if I don't refresh, the view will not respond to the following mouse down event, unless it is preceded with another mouse move event (because the view only respond to clicks if there is a highlighted item). There are multiple views of different kind in the window, each with its own kind of state. I'd like the currently hovered view to refresh its state, as if it received a regular mouse move event. I thought imititating the mouse move event would be the most straightforward and simple way. Was I wrong? On Tue, Nov 3, 2009 at 11:37 AM, Graham Cox wrote: > > On 03/11/2009, at 8:03 PM, Oleg Krupnov wrote: > >> I'd like to imitate a mouse move event programmaticaly, to refresh the >> state of my custom view. >> [] > > >> What am I doing wrong? Thanks! > > > The answer is: you're trying to post a mouse event to refresh the state of > your custom view. > > There has to be a better and easier way to do what you're trying to do - > whatever it is. So what is it? > > --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
Re: How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
On 03/11/2009, at 8:03 PM, Oleg Krupnov wrote: I'd like to imitate a mouse move event programmaticaly, to refresh the state of my custom view. [] What am I doing wrong? Thanks! The answer is: you're trying to post a mouse event to refresh the state of your custom view. There has to be a better and easier way to do what you're trying to do - whatever it is. So what is it? --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
How to imitiate mouse move programmatically? [NSApp postEvent:atStart:] does not work...
Hi, I'd like to imitate a mouse move event programmaticaly, to refresh the state of my custom view. What is the best way to do it? I am trying to use [NSApp postEvent:atStart:] and [window postEvent:atStart:], but nothing happens, the event is not fired, and the view does not receive it. Here is my code: NSEvent* event = [NSEvent mouseEventWithType:NSMouseMoved location:windowPoint modifierFlags:0 timestamp:0 windowNumber:windowNumber context:nil eventNumber:0 clickCount:0 pressure:0]; [NSApp postEvent:event atStart:NO]; What am I doing wrong? Thanks! ___ 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
