• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSTrackingArea strange requirement
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTrackingArea strange requirement


  • Subject: Re: NSTrackingArea strange requirement
  • From: Quincey Morris <email@hidden>
  • Date: Sun, 30 Nov 2008 00:37:47 -0800

On Nov 29, 2008, at 23:50, chaitanya pandit wrote:

I dunno if this is the right way to do it, but what if you Override mouseMoved: for the main view that contains all the subviews, and use a hitTest: to find the view over which the cursor is hovering and simply use
[[NSCursor whateverCursor] set]; to change the cursor depending on the view.
You obviously need to call setAcceptsMouseMovedEvennts on the view's window during initialization so that u'll get called with mouseMoved:.

It's not really going to work, unfortunately. The problem is that when the view is not one of your custom views, you don't know what to set the cursor to. (For example, if hitTest: tells you it's a text field under the mouse, you don't actually know which part of the text field should be an I-beam cursor (if any -- it may be disabled), and which part (if any) should be an arrow cursor. And if you find out by experimentation, the answer may change in the future.)


Plus, you could still end up with flickering, because the subviews are still possibly changing the cursor themselves.

The only way I know of that works is to use cursorUpdate: to figure out when you're responsible for the cursor (and when not), AND, when you are responsible for it, to figure out the correct cursor based on the mouse location, AND to avoid the loss-of-mouse-synchronization problem by not recreating the tracking areas if you can possibly avoid it after the first time.

If that sounds painful, I think it is. The whole cursorUpdate: mechanism turns out to be quite subtle, and is really difficult to get working properly in all but the simplest cases.
_______________________________________________


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


References: 
 >NSTrackingArea strange requirement (From: rajesh <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: Quincey Morris <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: rajesh <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: Rob Keniger <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: rajesh <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: Rob Keniger <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: rajesh <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: Quincey Morris <email@hidden>)
 >Re: NSTrackingArea strange requirement (From: chaitanya pandit <email@hidden>)

  • Prev by Date: Re: Right language
  • Next by Date: Re: reading a PDF
  • Previous by thread: Re: NSTrackingArea strange requirement
  • Next by thread: to get handle to "File/1.jpg"
  • Index(es):
    • Date
    • Thread