Re: NSTrackingArea strange requirement
Re: NSTrackingArea strange requirement
- Subject: Re: NSTrackingArea strange requirement
- From: rajesh <email@hidden>
- Date: Thu, 27 Nov 2008 10:17:41 +0100
On Nov 26, 2008, at 7:02 PM, Quincey Morris wrote:
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.)
I should have made my query bit clear , I need the cursor updates only
for certain portion of the visible area ( only horizontal gaps , its
like horizontal split view but no split view in use ) . but I can use
the above technique for something else I am working on , thanks :)
I think I am still hanging with same problem....
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
_______________________________________________
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