Re: Table of TextViews
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
Re: Table of TextViews
On Oct 14, 2014, at 7:49 AM, Charles Jenkins 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
Re: Table of TextViews
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
Re: Table of TextViews
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
Re: Table of TextViews
Can I ask you folks to look over and comment on this code? I think I’ve set up
the text view and text container correctly to track the size of the text they
contain, and I can notify my table view delegate when their size changes. The
problem I’m having is that the table view delegate can note and log the size
change and everything works well--as long as I don’t really do anything with
the information. But if the table view delegate notifies the table that the
corresponding row size changed, everything goes crazy.
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?
The code below is from three separate source files, but I’m sure you can tell
which is which.
@protocol SizeWatcher NSObject
// Notify of actual size change, along with variables to
// answer the most common questions receiver will want to
// ask:
//Did width grow? Shrink? Remain the same?
//Did height grow? Shrink? Remain the same?
//What is the view's new frame/bounds?
-(void)sizeChangedForView:(NSView*)view
widthChange:(CGFloat)wc
heightChange:(CGFloat)hc;
@end
#import SizeWatcher.h
@interface CJAutosizingTextView : NSTextView
-(void)addSizeWatcher:(id)obj;
-(void)removeSizeWatcher:(id)obj;
-(void)removeAllSizeWatchers;
-(void)setLayoutManager:(NSLayoutManager*)lm;
@end
#import CJAutosizingTextView.h
@interface CJAutosizingTextView ()
@property NSRect oldFrame;
@property NSMutableArray* sizeWatchers;
@end
@implementation CJAutosizingTextView
@synthesize oldFrame;
@synthesize sizeWatchers;
-(instancetype)initWithFrame:(NSRect)frameRect
andLayoutManager:(NSLayoutManager*)lm
{
self = [super initWithFrame:frameRect];
if ( self != nil ) {
sizeWatchers = nil;
oldFrame = frameRect;
NSTextContainer* tc = [[NSTextContainer alloc] init];
self.textContainer = tc;
NSNotificationCenter* nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self
selector:@selector(frameChanged:)
name:NSViewFrameDidChangeNotification
object:self];
self.layoutManager = lm;
// Make text container and text view automatically
// size themselves vertically to fit the text
tc.widthTracksTextView = YES;
tc.heightTracksTextView = NO;
self.horizontallyResizable = NO;
self.verticallyResizable = YES;
// Allow superview to resize text view's width
self.autoresizingMask = NSViewWidthSizable;
}
return self;
}
-(instancetype)initWithFrame:(NSRect)frameRect
{
return [self initWithFrame:frameRect andLayoutManager:nil];
}
-(void)dealloc
{
NSNotificationCenter* nc = [NSNotificationCenter defaultCenter];
[nc removeObserver:self
name:NSViewFrameDidChangeNotification
object:self];
}
// NSTextView already has a layoutManager: selector to read the
// text container's layout manager. Here we add a convenient
// setter companion
-(void)setLayoutManager:(NSLayoutManager*)lm
{
self.textContainer.layoutManager = lm;
}
// Maintain the array of size watchers
-(void)addSizeWatcher:(id)obj
{
if ( [obj conformsToProtocol:@protocol(SizeWatcher)] ) {
if ( sizeWatchers == nil ) {
sizeWatchers = [[NSMutableArray alloc] initWithCapacity:1];
}
[self.sizeWatchers addObject:obj];
}
}
-(void)removeSizeWatcher:(id)obj
{
if ( sizeWatchers != nil ) {
[sizeWatchers removeObject:obj];
}
}
-(void)removeAllSizeWatchers
{
if ( sizeWatchers != nil ) {
[sizeWatchers removeAllObjects];
}
}
// When I'm notified that my frame changes, see if the new frame's
// size change and, if so, notify all size watchers
-(void)frameChanged:(NSNotification*)note
{
// Begin with test that's probably unnecessary, but just to be sure...
if ( [note object] == self ) {
NSRect newFrame = self.frame;
CGFloat wd = newFrame.size.width - oldFrame.size.width;
CGFloat hd = newFrame.size.width - oldFrame.size.width;
oldFrame = newFrame;
if ( wd != 0.0 || hd != 0.0 ) {
// Notify watchers of actual size change
for ( NSObjectSizeWatcher* obj in sizeWatchers ) {
[obj sizeChangedForView:self widthChange:wd heightChange:hd];
}
}
}
}
@end
--
Charles
___
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
Re: Table of TextViews
Oops. When I pulled out this example code from the rest of my project, I mistyped something. Here is a corrected line: CGFloat hd = newFrame.size.height - oldFrame.size.height; -- Charles On Tuesday, October 14, 2014 at 8:49, Charles Jenkins wrote: Can I ask you folks to look over and comment on this code? -- Charles ___ 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
Re: Table of TextViews
Thank you, Ken. Originally I started out by implementing the table view using a data source and delegate. With some help from list members, I got that working pretty well except for row height. I only started my latest test app using NSArrayController and bindings because I mistakenly thought the Row Height binding would be useful. Here’s the problem I have: I can set up my text container and text view to pin their widths to the enclosing scroll view, no problem. And I can set the text container to size itself vertically to fit the text, and I can set my text view to size itself vertically to fit the text container. All that has worked for me in a demo app. The only piece missing is to get the text view to call the table view’s noteHeightOfRowsWithIndexesChanged: I create the text views programmatically instead of using IB, because apparently the only way to get ‘em in IB is enclosed in individual scroll views I don’t need. So how can I get my individual, programmatically created text views to react by notifying the table view when they update their size? -- Charles On Wednesday, October 8, 2014 at 22:18, Ken Thomases wrote: The table view's rowHeight binding is not a per-row row height. It's a single number for the height of all rows of the table. If/when you change the height of a subdocument, you need to inform the table view by calling -noteHeightOfRowsWithIndexesChanged: on it. 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
Re: Table of TextViews
On Oct 9, 2014, at 7:40 AM, Charles Jenkins cejw...@gmail.com wrote: Thank you, Ken. Originally I started out by implementing the table view using a data source and delegate. With some help from list members, I got that working pretty well except for row height. I only started my latest test app using NSArrayController and bindings because I mistakenly thought the Row Height binding would be useful. Here’s the problem I have: I can set up my text container and text view to pin their widths to the enclosing scroll view, no problem. And I can set the text container to size itself vertically to fit the text, and I can set my text view to size itself vertically to fit the text container. All that has worked for me in a demo app. The only piece missing is to get the text view to call the table view’s noteHeightOfRowsWithIndexesChanged: I create the text views programmatically instead of using IB, because apparently the only way to get ‘em in IB is enclosed in individual scroll views I don’t need. So how can I get my individual, programmatically created text views to react by notifying the table view when they update their size? You generally wouldn't, as they are both views. You could have a custom subclass of NSTableView or you would have a controller--preferably the table view delegate as it knows the most about the table view--send noteHeightOfRowsWithIndexesChanged: when it is told (possibly by NSTextView delegate method or notification) that the text view size needs to change. Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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
Re: Table of TextViews
Well, I was imprecise. I didn’t literally mean the text view would directly change the table view. Right now the text container and text view adjust automatically to fit the text, but my code isn’t told about any changes, so I have no opportunity to do anything to change the table view. But once again I think you might have said the magic word, and this time it is “notification.” Tonight I’ll do research on notifications. I see NSView offers NSBoundsDidChangeNotification and NSFrameDidChangeNotification. If, as I assume, NSTextView is a subclass of NSView, maybe I can make my Subdocument register to receive such notifications from their text views, which would give me the final piece of the puzzle. -- Charles On Thursday, October 9, 2014 at 10:19, Keary Suska wrote: You generally wouldn't, as they are both views. You could have a custom subclass of NSTableView or you would have a controller--preferably the table view delegate as it knows the most about the table view--send noteHeightOfRowsWithIndexesChanged: when it is told (possibly by NSTextView delegate method or notification) that the text view size needs to change. Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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
Re: Table of TextViews
On Oct 9, 2014, at 11:19 AM, Charles Jenkins cejw...@gmail.com wrote: Well, I was imprecise. I didn’t literally mean the text view would directly change the table view. Right now the text container and text view adjust automatically to fit the text, but my code isn’t told about any changes, so I have no opportunity to do anything to change the table view. But once again I think you might have said the magic word, and this time it is “notification.” Tonight I’ll do research on notifications. I see NSView offers NSBoundsDidChangeNotification and NSFrameDidChangeNotification. If, as I assume, NSTextView is a subclass of NSView, maybe I can make my Subdocument register to receive such notifications from their text views, which would give me the final piece of the puzzle. Yes, it should work to observe the NSViewFrameDidChangeNotification from the text view. I believe this is how NSClipView knows when the text view that's inside of a scroll view has changed its size, so the scroll view knows how much it can scroll. 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
Table of TextViews
I’m still struggling to create a single scrollview containing a stack of textviews. I created an object called “Subdocument” which has two important readonly properties: NSTextView* myView CGFloat myHeight myHeight returns myView's frame hight, but never less than 10. The Subdocument’s initializers take care of instantiating and connecting up all four text objects (TextView, TextContainer, LayoutManager, and TextStorage). For now, my Document class has one important property which is read/write: NSMutableArray* subdocumentStack; The Document initializer creates and plugs in an array of 20 subdocuments as a test. In my NIB, I add an NSArrayController and set it to manage the Subdocument class and bind it to File’s Owner’s subdocumentStack. Then I add a view-based NSTableView and turn off unnecessary things like column headers, column selection, and column resizing. If I run my application at this point, everything is fine, but the table is empty. NSLog statements confirm the subdocumentStack contains 20 objects with views and heights. Now I try to bind the table. I select the Table View object and bind Table Content to the array controller’s arrangedObjects myView key path. Then I bind its Row Height to the array controller’s arrangedObjects myHeight key path. The next time I run the program, no document ever appears. Initialization happens normally, but before the window opens, an error is logged: [__NSArrayI doubleValue]: unrecognized selector sent to instance address. If I unbind the Row Height, the document window will appear, but the views are all copies of the default Text View Cell. Now, IB liked all the model key paths I chose. subdocumentStack was in the suggestion list for the array controller; and myView and myHeight were in the suggestion lists for table bindings. So here’s my first question: What if anything am I doing wrong when I try to bind the row height? Adding that one thing causes the error and interrupts the NIB from loading. — Charles Jenkins ___ 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
Re: Table of TextViews
On Oct 8, 2014, at 8:59 PM, Charles Jenkins cejw...@gmail.com wrote: Now I try to bind the table. I select the Table View object and bind Table Content to the array controller’s arrangedObjects myView key path. Then I bind its Row Height to the array controller’s arrangedObjects myHeight key path. The next time I run the program, no document ever appears. Initialization happens normally, but before the window opens, an error is logged: [__NSArrayI doubleValue]: unrecognized selector sent to instance address. What if anything am I doing wrong when I try to bind the row height? Adding that one thing causes the error and interrupts the NIB from loading. The table view's rowHeight binding is not a per-row row height. It's a single number for the height of all rows of the table. Using KVC to get the value from the array controller with the key path arrangedObjects.myHeight returns an array. -valueForKey: applied to an array will always produce an array, and -valueForKeyPath: is just a series of -valueForKey: calls. Then, the table view calls -doubleValue on whatever object KVC obtained. Hence the error that an array class doesn't respond to -doubleValue. If you want separate row heights for each row, you need to implement a table view delegate and the method -tableView:heightOfRow:. You would look up the object for the row by indexing into the array controller's arrangedObjects and obtain the height from your myHeight property. If/when you change the height of a subdocument, you need to inform the table view by calling -noteHeightOfRowsWithIndexesChanged: on it. 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
