Re: NSDrawerWindow - using it is okay?
Re: NSDrawerWindow - using it is okay?
- Subject: Re: NSDrawerWindow - using it is okay?
- From: Douglas Davidson <email@hidden>
- Date: Fri, 18 Mar 2005 09:36:54 -0800
On 2005-03-18 08:04:56 -0800 Axel Andersson <email@hidden>
wrote:
On Mar 18, 2005, at 13:33, Simon Liu wrote:
I have subclassed tableviews, outlineviews and cells for custom
drawing purposes, and some of the highlighting is based on whether or
not the tableview's window is the keyWindow or not. It's quite
'elegant' and easy to be able to invoke -window, -keyWindow without
worring whether the window is a NSWindow or NSDrawerWindow.
Otherwise
I'll have to go and get the NSDrawer and invoke -parentWindow... Not
a
big deal, but would be interested in any comments.
That your tableview returns an NSDrawerWindow instance in this case
is
implementation specific. NSView is bound by the contract stipulated
in the
header, and must return something that can be used as an NSWindow
from its
-window method. However, it's free to return, for instance, an
NSWindow
subclass of its own choosing; NSDrawerWindow is such a subclass. The
point
here is that you don't need to know what it actually is, just what
the header
says it is.
Quite right. You are entitled to assume that views in a drawer have a
window that you can operate on using standard NSWindow methods. You
should not assume, however, that this window will be of any particular
class. The current implementation is designed to make most common
operations work properly so that they need not take into account
whether a view is in a drawer or not. If you encounter a case that
seems to force you to do something awkward or to make excessive
assumptions about the implementation of drawers, please file a bug and
we will look into it.
Douglas Davidson
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden