On Sat, Feb 21, 2009 at 8:48 PM, Development Staff <[email protected]> wrote: > So I've got this app that uses various NSView subclasses (NSTextView, > NSImageView, QTMovieView, etc.) to display different kinds of data in a > window. The problem is that, when I need to select which kind of view to use > for the current data, I have very different code for each kind of view > (detecting what view handles the current data and initializing the view), > and it currently makes for a messy bit of code. > > What I'd like to do is have an array of candidate views and a consistent way > to test against the current data and initialize the view once I have > selected a candidate. I'm trying to decide between a formal protocol with > -(BOOL)canDisplayData:(id)data and -(int)setupDisplayInFrame:(NSRect)rect > withData:(id)data methods, or a sub-class of NSView from which all candidate > view classes must descend. > > I'm currently coding against the protocol, but reading the Cocoa Views Guide > to see what kind of work I'll need to put in to correctly wrap the actual > candidate views. If all I really need to do is pass on calls to -drawRect > calls to the actual view, then I feel comfortable going with the protocol. > If there is a lot more to it, then putting all that work in a separate base > class seems like the right thing to do.
Passing on calls to -drawRect: will not work. For example, a view may invalidate itself when it changes. It's going to invalidate *itself*, not your proxy view, and so the whole thing will fall apart. You could have your custom view and then add the "real" view as a *subview* rather than trying to proxy drawing across. The end result will look the same. Better yet, since your custom view doesn't actually do any drawing, it should really be a custom controller. Instead of trying to move your code into a view, just move it into a separate controller, in different classes which descend from a common subclass. Then your generic controller can instantiate and talk to your specific controllers and all is handled. Mike _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
