setFrameSize called multiple times for a single size change?
I have a sub-classed TableView that is the document view of an ScrollView. The rows of the TableView are composited by a custom cell, and soI have overridden the -setFrameSize method of the TableView in order to determine if any rows have changed height as a consequence of the resize (if so, I invoke - noteHeightOfRowsWithIndexesChanged). After performing that calculation (and call to inform the table if any rows did change height), I then call the -setFrameSize of the super class (the NSTableView). What I am seeing is that upon invoking the super class's -setFramSzie method, the overridden -setFrameSize is invoked twice more: the first time with the *old* size, then twice with the new size. While my app functions, I am troubled by these seemingly extra calls, and wonder if I haven't configured some setting of the TableView or ScrollView that I should. All of these objects are instantiated programmatically (not in IB). I set a breakpoint to examine the calling stack to see what was going on. The call to set the old size comes from -resizeWithOldSuperviewSize. The docs say this can be overriden, so I have done so, making it a no- op method (that is, not invoking the super class). My app seems to perform just fine. Question 1 -- Is this okay to do?? The two calls for the new size come, it seems to me, as a consequence of the TableView sizing the column (there is only one column in the table), as indicated by these two calling stacks: #0 0x00041148 in -[TweetsListTableView setFrameSize:] at TweetsListTableView.m:181 #1 0x93ba6057 in -[NSTableView tile] #2 0x93baefcf in -[NSTableColumn setWidth:] #3 0x93baeae0 in -[NSTableView _sizeTableColumnsToFitWithStyle:forceExactFitIfPossible:] #4 0x93bae24a in -[NSTableView _sizeTableColumnsToFitForAutoresizingWithStyle:] #5 0x93bae1d4 in -[NSTableView sizeLastColumnToFit] #6 0x93bae00f in -[NSTableView _autoresizeToFit] #7 0x93badd34 in -[NSTableView superviewFrameChanged:] #0 0x00041148 in -[TweetsListTableView setFrameSize:] at TweetsListTableView.m:181 #1 0x93ba6057 in -[NSTableView tile] #2 0x93bae1e6 in -[NSTableView sizeLastColumnToFit] #3 0x93bae00f in -[NSTableView _autoresizeToFit] #4 0x93badd34 in -[NSTableView superviewFrameChanged:] I now cache the last size given to the -setFrameSize method, and don't perform my testing for row height changes if the width hasn't changed, so I am no longer incurring that calculation cost. Question 2 -- Is there a better way to configure the single column's resizing mask to avoid the double call? TIA, --Stuart ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: setFrameSize called multiple times for a single size change?
On Tue, Jul 21, 2009 at 9:17 AM, Stuart Malinstu...@zhameesha.com wrote: I have a sub-classed TableView that is the document view of an ScrollView. For future reference: TableView and ScrollView are not names of classes in Cocoa. NSTableView and NSScrollView are; UITableView and UIScrollView exist in Cocoa Touch, so it's important to make this distinction. The rows of the TableView are composited by a custom cell, and soI have overridden the -setFrameSize method of the TableView in order to determine if any rows have changed height as a consequence of the resize (if so, I invoke -noteHeightOfRowsWithIndexesChanged). After performing that calculation (and call to inform the table if any rows did change height), I then call the -setFrameSize of the super class (the NSTableView). You're doing this backwards. Your delegate should be telling your table view the size of the rows. Have your delegate listen for NSViewFrameDidChangeNotification from the table view, and have it call -noteHeightOfRowsWithIndexesChanged:. What I am seeing is that upon invoking the super class's -setFramSzie method, the overridden -setFrameSize is invoked twice more: the first time with the *old* size, then twice with the new size. While my app functions, I am troubled by these seemingly extra calls, and wonder if I haven't configured some setting of the TableView or ScrollView that I should. All of these objects are instantiated programmatically (not in IB). I set a breakpoint to examine the calling stack to see what was going on. Sounds like a situation you need to be able to handle (perhaps at the expense of more drawing). It may go away if you use the notifications. The call to set the old size comes from -resizeWithOldSuperviewSize. The docs say this can be overriden, so I have done so, making it a no-op method (that is, not invoking the super class). My app seems to perform just fine. Question 1 -- Is this okay to do?? No, because it's orthogonal. NSTableView is going to resize itself based on the number of rows and their size. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: setFrameSize called multiple times for a single size change?
On Jul 21, 2009, at 9:17 AM, Stuart Malin wrote: I now cache the last size given to the -setFrameSize method, and don't perform my testing for row height changes if the width hasn't changed, so I am no longer incurring that calculation cost. Question 2 -- Is there a better way to configure the single column's resizing mask to avoid the double call? My bad -- I figured out an answer to the second question after posting... Since I have only one column, I now set the columnAutoresizingStyle of the TableView to NSTableViewFirstColumnOnlyAutoresizingStyle In the past, I had multiple columns, and had instead set this to - NSTableViewSequentialColumnAutoresizingStyle I guess that the TabbleView doesn't notice that there is only one column, and so it was generating two resizing calls. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: setFrameSize called multiple times for a single size change?
On Jul 21, 2009, at 9:27 AM, Kyle Sluder wrote: On Tue, Jul 21, 2009 at 9:17 AM, Stuart Malinstu...@zhameesha.com wrote: I have a sub-classed TableView that is the document view of an ScrollView. For future reference: TableView and ScrollView are not names of classes in Cocoa. NSTableView and NSScrollView are; UITableView and UIScrollView exist in Cocoa Touch, so it's important to make this distinction. Good point. I was referring to NS, not UI, and will be clearer in the future. The rows of the TableView are composited by a custom cell, and soI have overridden the -setFrameSize method of the TableView in order to determine if any rows have changed height as a consequence of the resize (if so, I invoke -noteHeightOfRowsWithIndexesChanged). After performing that calculation (and call to inform the table if any rows did change height), I then call the -setFrameSize of the super class (the NSTableView). You're doing this backwards. Your delegate should be telling your table view the size of the rows. Have your delegate listen for NSViewFrameDidChangeNotification from the table view, and have it call -noteHeightOfRowsWithIndexesChanged:. Ah yes, this makes sense -- I will recode. Thank you Kyle! ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
