Re: Table of TextViews
Re: Table of TextViews
- Subject: Re: Table of TextViews
- From: Charles Jenkins <email@hidden>
- Date: Wed, 15 Oct 2014 07:40:07 -0400
Ken,
Thanks for looking it over. :-) I guess I misunderstood the documentation. I thought if you dragged out a table view from the palette into a NIB, you got a full hierarchy of objects (including the extra scroll view I specifically don’t want), but if you created it programmatically you had to create all the individual text objects and link them up programmatically.
I’ll use the debugger to scope out what I actually get via initWithFrame:, and if the other objects are already there, I’ll leave them alone instead of wasting code space recreating them. The only thing I truly must replace is the text source, which is located in another of my objects.
As for reporting the size the way I do, I tried that because of the craziness that happens when I use text views in a table. I originally started out having the table delegate watch for the size change notification. When my table delegate is notified of a text view’s size change, it logs the event and makes these calls:
NSIndexSet* ixs = [NSIndexSet indexSetWithIndex:row];
[self.theTableView noteHeightOfRowsWithIndexesChanged:ixs];
And things go nuts. I imagine the table retrieves the view and asks its height, then makes an adjustment. As a result the row might grow to perfectly fit the new text, if my change was to simply type new words into the control. But if I pressed Enter, the row grows, but then the table apparently does something to change the text view/text container and the notification happens again and the row grows again…and again and again in a never-ending loop. If I hit Backspace, a character or selection might be deleted and the row might shrink accordingly…or the entire text view may be removed from the table, leaving behind a dead, empty row.
If I comment out those two lines above and simply log the size change event, everything works normally even though the text view soon grows larger than the row and I can no longer see the characters I’m typing. I cannot imagine why adjusting height would cause the Backspace or Enter keys to work differently (unless there is some kind of race condition that makes the table respond to the Backspace key by killing the view, rather than sending the keypress on to the text view).
I wondered if I had the table delegate responding incorrectly to too many notifications, so I redesigned the table view this way to filter them carefully and make sure my table delegate could never know about inapplicable notifications. Well, last night I finally got this new version all together and tested, and the behavior is no different. I can do anything I want EXCEPT adjust the table row height, which is the very thing I need to do.
I’m going to take your advice and simplify this object. Fewer lines of code equals fewer potential bugs, so if I really don’t have to do all this stuff, I won’t. But I sure would appreciate any clues as to why a table view would make a text view go crazy resizing itself in response to a row height adjustment. I posted this code first because I thought someone might find a nuance I’ve misunderstood of the sizing setup.
--
Charles
On Wednesday, October 15, 2014 at 2:43, Ken Thomases wrote:
> On Oct 14, 2014, at 7:49 AM, Charles Jenkins <email@hidden (mailto: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