Re: Table of TextViews
Re: Table of TextViews
- Subject: Re: Table of TextViews
- From: Ken Thomases <email@hidden>
- Date: Wed, 15 Oct 2014 01:43:23 -0500
On Oct 14, 2014, at 7:49 AM, Charles Jenkins <email@hidden> wrote:
> I’m going to take this step by step. Would you comment on my NSTextView subclass and tell me if something is wrong in the way I’ve set it up to size itself, notify itself, or pass along size-change notifications?
I don't notice any obvious problems other than the height/width mixup you already caught.
That said, this seems overdeveloped to me. Why can't the objects which are interested in seeing when the text view changes size simply observe NSViewFrameDidChangeNotification themselves?
-[NSTextView initWithFrame:] builds a complete hierarchy of text system objects. Why do you replace the text container and layout manager? Your override of -initWithFrame: ends up nil-ing out the layout manager, which doesn't seem good.
In general, I'm not sure what the point of this class is. It seems that clients could just use a standard NSTextView.
If you are going to go with a subclass for this, why does it use NSViewFrameDidChangeNotification to find out when it's own frame has changed size? Why not just override -setFrameSize:?
When deciding if the frame size has actually changed, you should probably use NSEqualSizes(). Also, you might consider merely passing the old size to the clients and let them request the current size and compute the delta themselves if they want. That follows the pattern of -[NSView resizeWithOldSuperviewSize:], for example.
Regards,
Ken
_______________________________________________
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