Of course in the penultimate paragraph I meant I redesigned the TEXT VIEW this way to filter notifications.
I never seem to find typos until after my posts appear… :-/ -- Charles On Wednesday, October 15, 2014 at 7:40, Charles Jenkins wrote: > 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
