FROM : Luke Evans
DATE : Fri Feb 15 01:43:03 2008
Closure:
Not that this is necessarily of any use to anyone, but the "something
seriously wrong" causing -copyWithZone to be sent to an
NSManagedObject was the following:
I had an NSArrayController set up to collect a set of NSManagedObjects
from a master view selection 'upstream'. I had then bound a table
view to this in one of its columns, *but* I had only set the
Controller Key (to arrangedObjects), I had not entered a Model Key
Path i.e. set up a path to the content to be rendered in each cell of
the column.
Under these circumstances, the objects referenced in arrangedObjects
(which happen to be Core Data objects) get sent a -copyWithZone.
So this is why the problem "went away" when I had restructured my
bindings before, I had clearly 'done the right thing' and the problem
vanished. I've just repeated the earlier mistake and so can report
the reason for the message.
-- Lwe
On 13-Jan-08, at 3:37 PM, Luke Evans wrote:
> O.K...
>
> So, I just did this and found it wasn't being called any longer.
> So, I suspect your original intuition was right - there was
> something badly wrong with my code (which thankfully I have now
> rectified - though its frustrating not to be able to nail the
> original reason now).
>
> One change that may have had a bearing here was that I had
> inadvertently commented out some code to return an
> NSCollectionViewItem in a subclass of NSCollectionView that was
> generating UI for the B objects. I fixed this yesterday. It's
> possible that something in NSCollectionView was trying to do its
> best with just the prototype item and the list of B's from the
> NSArrayController. Anyway, that's pure speculation, and perfectly
> well covered by your comment that "something is seriously wrong with
> your code"!
>
> I'm deleting the spurious copyWithZone now, safe in the knowledge
> that it's just not something that I should need to implement until
> such time as I have a real need for a copy constructor in that class.
>
> Thanks.
>
> -- Lwe
>
>
> On 13-Jan-08, at 2:54 PM, Bill Bumgarner wrote:
>
>> You mentioned that you had implemented a -copyWithZone: on B? Can
>> you set a breakpoint on that and see what backtrace barfs up as a
>> result?
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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/<email_removed>
>
> This email sent to <email_removed>
>
DATE : Fri Feb 15 01:43:03 2008
Closure:
Not that this is necessarily of any use to anyone, but the "something
seriously wrong" causing -copyWithZone to be sent to an
NSManagedObject was the following:
I had an NSArrayController set up to collect a set of NSManagedObjects
from a master view selection 'upstream'. I had then bound a table
view to this in one of its columns, *but* I had only set the
Controller Key (to arrangedObjects), I had not entered a Model Key
Path i.e. set up a path to the content to be rendered in each cell of
the column.
Under these circumstances, the objects referenced in arrangedObjects
(which happen to be Core Data objects) get sent a -copyWithZone.
So this is why the problem "went away" when I had restructured my
bindings before, I had clearly 'done the right thing' and the problem
vanished. I've just repeated the earlier mistake and so can report
the reason for the message.
-- Lwe
On 13-Jan-08, at 3:37 PM, Luke Evans wrote:
> O.K...
>
> So, I just did this and found it wasn't being called any longer.
> So, I suspect your original intuition was right - there was
> something badly wrong with my code (which thankfully I have now
> rectified - though its frustrating not to be able to nail the
> original reason now).
>
> One change that may have had a bearing here was that I had
> inadvertently commented out some code to return an
> NSCollectionViewItem in a subclass of NSCollectionView that was
> generating UI for the B objects. I fixed this yesterday. It's
> possible that something in NSCollectionView was trying to do its
> best with just the prototype item and the list of B's from the
> NSArrayController. Anyway, that's pure speculation, and perfectly
> well covered by your comment that "something is seriously wrong with
> your code"!
>
> I'm deleting the spurious copyWithZone now, safe in the knowledge
> that it's just not something that I should need to implement until
> such time as I have a real need for a copy constructor in that class.
>
> Thanks.
>
> -- Lwe
>
>
> On 13-Jan-08, at 2:54 PM, Bill Bumgarner wrote:
>
>> You mentioned that you had implemented a -copyWithZone: on B? Can
>> you set a breakpoint on that and see what backtrace barfs up as a
>> result?
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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/<email_removed>
>
> This email sent to <email_removed>
>
| Related mails | Author | Date |
|---|---|---|
| Luke Evans | Jan 13, 05:03 | |
| Bill Bumgarner | Jan 13, 06:31 | |
| Luke Evans | Jan 13, 23:48 | |
| Bill Bumgarner | Jan 13, 23:54 | |
| Luke Evans | Jan 14, 00:37 | |
| Luke Evans | Feb 15, 01:43 |






Cocoa mail archive

