On Jan 20, 2011, at 9:39 PM, Corbin Dunn wrote:
> Now for something like a button, it obviously won't run into this type of
> latent drawing issue, since they don't message the delegate every time they
> draw. However, if you temporarily allocated an object and set it as the
> target/action of a
On Jan 20, 2011, at 8:51 PM, Eric Gorr wrote:
> On Jan 20, 2011, at 4:27 PM, Corbin Dunn wrote:
[...]
>> Yes, please do file a bug. The sample should set the delegate/datasource to
>> nil, as it is good practice to do so, and we can update the sample.
>
> Bug filed: rdar://8896270
I just submit
On Jan 20, 2011, at 1:33 PM, Abdul Sowayan wrote:
> Hi Corbin,
>
>
>> I wrote that sample, and gave the WWDC talk based on it a few years ago. I
>> also "own" NSTableView.
>>
>> Yes, please do file a bug. The sample should set the delegate/datasource to
>> nil, as it is good practice to do so,
On Jan 20, 2011, at 4:27 PM, Corbin Dunn wrote:
> Hi Eric,
>
> On Jan 20, 2011, at 9:26 AM, Eric Gorr wrote:
>
>>
>> On Jan 20, 2011, at 12:17 PM, Kyle Sluder wrote:
>>
>>> On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr wrote:
Based on my current understanding, the dealloc should be setting
On Jan 20, 2011, at 4:56 PM, Sean McBride wrote:
> On Thu, 20 Jan 2011 13:27:35 -0800, Corbin Dunn said:
>
>>> For a specific example, check out the AnimatedTableView sample code
>> from Apple. The ATColorTableController class is a datasource for the
>> table, but it's dealloc looks like:
>>>
On Thu, 20 Jan 2011 13:27:35 -0800, Corbin Dunn said:
>> For a specific example, check out the AnimatedTableView sample code
>from Apple. The ATColorTableController class is a datasource for the
>table, but it's dealloc looks like:
>>
>> - (void)dealloc
>> {
>> [_colorList release];
>> [_colo
On Jan 20, 2011, at 1:24 PM, Corbin Dunn wrote:
On Jan 19, 2011, at 4:51 PM, Lee Ann Rucker wrote:
On Jan 19, 2011, at 3:21 PM, Corbin Dunn wrote:
In general, it is good practice in your apps to set your delegate and
datasource to nil. Who is to say something might cause a draw to happen, w
Hi Corbin,
> I wrote that sample, and gave the WWDC talk based on it a few years ago. I
> also "own" NSTableView.
>
> Yes, please do file a bug. The sample should set the delegate/datasource to
> nil, as it is good practice to do so, and we can update the sample.
Thanks for the clarification, i
Hi Eric,
On Jan 20, 2011, at 9:26 AM, Eric Gorr wrote:
>
> On Jan 20, 2011, at 12:17 PM, Kyle Sluder wrote:
>
>> On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr wrote:
>>> Based on my current understanding, the dealloc should be setting it's
>>> datasource and delegate to nil. Correct? If so, I wi
On Jan 19, 2011, at 4:51 PM, Lee Ann Rucker wrote:
>
> On Jan 19, 2011, at 3:21 PM, Corbin Dunn wrote:
>
>>
>> In general, it is good practice in your apps to set your delegate and
>> datasource to nil. Who is to say something might cause a draw to happen,
>> which would then message your (n
Hi folks,
I'm trying to figure out a clear guideline on how to handle weak references.
Let's consider the following scenarios:
1- Say I have a button, and set its action/target (via a nib file) to call
method on the controller. In the controller dealloc method, should the
controller set the actio
On Jan 20, 2011, at 07:22, Eric Gorr wrote:
> I was wondering why this was such a surprise to me, so I went hunting through
> sample code, books, etc.
>
> I cannot seem to find any sample code, either in books (even Cocoa
> Programming for Mac OS X (3rd Edition)) or in Apple's own sample code w
On Jan 20, 2011, at 12:17 PM, Kyle Sluder wrote:
> On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr wrote:
>> Based on my current understanding, the dealloc should be setting it's
>> datasource and delegate to nil. Correct? If so, I will file a bug.
>
> No. It is the responsibility of the delegate t
On Thu, Jan 20, 2011 at 7:22 AM, Eric Gorr wrote:
> Based on my current understanding, the dealloc should be setting it's
> datasource and delegate to nil. Correct? If so, I will file a bug.
No. It is the responsibility of the delegate to set the table view's
backpointer to nil. The delegate usu
On Jan 19, 2011, at 8:24 PM, Eric Gorr wrote:
> On Jan 19, 2011, at 8:19 PM, Graham Cox wrote:
>
>> On 20/01/2011, at 12:14 PM, Eric Gorr wrote:
>>
>>> The table is also owned by the the scrolling view and therefore the window
>>> and would not be deallocated here...it will stick around long af
On Jan 19, 2011, at 8:19 PM, Graham Cox wrote:
> On 20/01/2011, at 12:14 PM, Eric Gorr wrote:
>
>> The table is also owned by the the scrolling view and therefore the window
>> and would not be deallocated here...it will stick around long after the
>> controller is deallocated.
>
> You're righ
On 20/01/2011, at 12:14 PM, Eric Gorr wrote:
> However, simply setting the the datasource and delegate to nil works as well
> and is a better solution.
It is also the correct solution.
> The table is also owned by the the scrolling view and therefore the window
> and would not be deallocated
The reason was that removing the table columns from the table prevented the
crash from happening.
However, simply setting the the datasource and delegate to nil works as well
and is a better solution.
Without any table columns, even though the table might have been marked as
dirty, neither the
On Jan 19, 2011, at 3:21 PM, Corbin Dunn wrote:
>
> In general, it is good practice in your apps to set your delegate and
> datasource to nil. Who is to say something might cause a draw to happen,
> which would then message your (now dealloced) delegate? Ideally, NSTableView
> shouldn't messa
On 20/01/2011, at 11:28 AM, Corbin Dunn wrote:
> for ( column in tableColumns )
> {
> [table removeTableColumn:column];
> }
>
> [table release];
Since the table owns its columns, why not just release the table - if it gets
deallocated the columns wi
Hi eric,
As I mentioned earlier, it is good practice to set your delegate/ds to nil,
since people inadvertently don't realize when they tell the table to redraw,
and are
surprised when they get the delegate messages after they are deallocd. I looked
at your app, and I can point out the problem
On Jan 19, 2011, at 12:28 PM, Eric Gorr wrote:
> I believe my situation is a bit different and my stack trace is not the same.
>
> What I see in my stack trace is:
>
> #00x978f8edb in objc_msgSend
> #10x00516f60 in ??
> #20x98fbb3ea in -[NSTableView preparedCellAtColumn:row:]
> #3
On Jan 19, 2011, at 12:15 PM, Lee Ann Rucker wrote:
> Sounds like a radar bug I filed a while back. It was marked as a duplicate of
> 6728942
>
>> From my bug:
>
> Snow leopard throws a doesNotRecognizeSelector in NSTableView.
>
> Regression:
> Works on Leopard.
>
> 6 com.apple.ExceptionHa
I believe my situation is a bit different and my stack trace is not the same.
What I see in my stack trace is:
#0 0x978f8edb in objc_msgSend
#1 0x00516f60 in ??
#2 0x98fbb3ea in -[NSTableView preparedCellAtColumn:row:]
#3 0x98fd58bc in -[NSTableView _drawContentsAtRow:column:w
Sounds like a radar bug I filed a while back. It was marked as a duplicate of
6728942
>From my bug:
Snow leopard throws a doesNotRecognizeSelector in NSTableView.
Regression:
Works on Leopard.
6 com.apple.ExceptionHandling 0x976b1ebb -[NSExceptionHandler
_handleException:mask:] + 33
If anyone is interested, this odd crash turns out to be the same issue I was
struggling with in the 'Window Controllers & Window Deallocation' (
http://bit.ly/gzd1LI ) thread.
If in the dealloc method of the table controller, I set the table's dataSource
and delegate to nil, it will no longer c
Try grabbing the project again - I have cleaned up a few things which should
make this a bit easier.
http://ericgorr.net/cocoadev/TableColumnTest.zip
It should crash everytime as long as in TableController.m the column are not
being removed from the table first. You will have to go in an commen
On Jan 11, 2011, at 5:49 PM, Eric Gorr wrote:
> I do release them after adding them to the table. It will still crash...
I cannot reproduce the crash with your test project. Have you verified, using
zombies, that in fact it is a table column crashing? It might have to do with
an invalid data so
I do release them after adding them to the table. It will still crash...
Sent from my iPad
On Jan 11, 2011, at 7:29 PM, Peter Lübke wrote:
> Table columns are retained by the table view they are added to.
>
> So you can safely release or autorelease the table column right after
> invoking -ad
Table columns are retained by the table view they are added to.
So you can safely release or autorelease the table column right after
invoking -addTableColumn: .
The table view owns its columns and will release them when it itself
is released.
This is the normal behaviour when adding subvie
I've got a sample test project at:
http://ericgorr.net/cocoadev/TableColumnTest.zip
which reproduces the strange crash.
I have a NSTableView to which I need to add NSTableColumns manually using the
addTableColumn: method. The problem is that for some reason when I release the
window and everyt
31 matches
Mail list logo
