Re: NSTrackingArea strange requirement
Re: NSTrackingArea strange requirement
- Subject: Re: NSTrackingArea strange requirement
- From: Quincey Morris <email@hidden>
- Date: Wed, 26 Nov 2008 10:02:56 -0800
On Nov 26, 2008, at 06:30, rajesh wrote:
I have Custom NSView with set of boxes arranged in some pattern
( boxes with some extra UI elements like , text fields and stuff).
I am using the gaps between the boxes a.k.a the visible custom
NSView to add the NStrackingAreas for cursor updates and as well for
resizing the subviews (i.e the NSBox)
As an obvious fact , when ever I try to resize the subviews I need
to as well set the frame for the NSTrackingArea elements and here I
is no such thing as setFrame
I googled around and found that , everybody is alloc-init ' ng and
then set the tracking area to 'nil' or release and create a new
NSTrackingArea then – initWithRect:options:owner:userInfo: and use
it.
I don't have fixed number of subviews or as a fact no fixed gaps ,
hence the tracking areas count might shoot up to anything.....
I think following the general approach will have a serious affect on
efficiency , memory and other factors .....
I can't use SplitView to manage the resizing of subviews ( I
iterate, no fixed subview , and I need to collapse or expand a
particular subview )
Assuming you have a custom NSView and the NSBox views are its
subviews, you can set *one* tracking area on the custom view, and one
tracking area on each of the subviews. (Use the
"NSTrackingInVisibleRect" option on all the tracking areas, if you
can. Then you don't even have to update the tracking areas yourself
when the views change size or position.)
It's not a problem that the tracking areas of the subviews overlap the
tracking area of the parent custom view. For cursor updates, a
tracking area doesn't send the cursorUpdate event to its owner, or
even to its view. Instead, it sends the event to the view under the
mouse (that is, the view that would respond to hitTest: at the current
mouse location). So, only one view gets the event, and it's the
"right" view -- if the mouse just entered a NSBox, the subview would
get it; if the mouse just exited the NSBox, the parent view would get
it.
If you need different cursors depending on which "gap" the mouse is in
(e.g. sometimes a horizontal-resize cursor, sometimes a vertical-
resize cursor), I'd suggest doing it by having your cursorUpdate:
method work out which gap the mouse location is in, and not try to use
multiple tracking areas.
_______________________________________________
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