On Oct 15, 2014, at 6:40 AM, Charles Jenkins <cejw...@gmail.com> wrote:
> 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. Dragging a text view in IB does give you an enclosing scroll view, which is almost always what one wants, so it's probably a good default, but it can be a bit annoying. However, the documentation clearly explains that there are two approaches when creating on programmatically. If you use -initWithFrame:, NSTextView creates all of the appropriate objects of the text system. If you use -initWithFrame:textContainer:, the NSTextView assumes you are taking responsibility for creating those objects. The two approaches also result in different ownership semantics for the various objects. > 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. You can poke around with the debugger if you like, but the docs are clear. Just look at the docs for the initializer methods in the NSTextView class reference. Or see the "Creating an NSTextView Object Programmatically" article in the Text System User Interface Layer Programming Guide: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/TextUILayer/Tasks/CreateTextViewProg.html > 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. Are you using the text view as the _direct_ cell view in the table? Don't do that. The outline view is in charge of the frame of the cell views. So, it will call (or cause to be called by, for example, auto layout) the -setFrame… methods, which will cause the text view to re-layout the text, which will cause the layout manager to change the size of the text view, etc. Put the text view into another view. Probably easiest to make that containing view flipped, since you want the text view's top-left corner, not its bottom-left, to be anchored in place as it changes size. If you're using auto layout, leave the text view's translatesAutoresizingMaskIntoConstraints property as YES and don't set any constraints on it. Position it using -setFrame: and let the autoresizingMask take it from there. The outline view can resize the container view as it likes. That won't have a direct effect on the text view's height. It will affect its width, as desired, because of the autoresizingMask. If the text view changes height such that it is taller or shorter than the container view, that should be corrected after you inform the outline view that the row's height has changed, so it queries your delegate for the new height, at which point your delegate would inform it and the outline view will resize the container view so that the text view shows and is not clipped. 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
