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 <cejw...@gmail.com
> (mailto:cejw...@gmail.com)> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
