i was struggling with this, when i happened to stumble across a remark
from someone on the cocoadev-forums that hit the nail right on the
head:
" … Also, you didn't call super's -setSelected: within your override … "
http://cocoadev.com/forums/discussion/comment/2190#Comment_2190
So, in your imp
On 2 Mar 2010, at 04:03, Markus Spoettl wrote:
> On Mar 1, 2010, at 2:42 PM, Thomas Davie wrote:
>> However, when the user clicks on item B after clicking on item A,
>> setSelected:NO is *not* sent to the NSCollectienViewItem subclass for A.
>> This displeases me greatly :(.
>
>
> Works fine
On 2 Mar 2010, at 14:39, Markus Spoettl wrote:
> On Mar 2, 2010, at 3:36 AM, Thomas Davie wrote:
>>> On Mar 1, 2010, at 2:42 PM, Thomas Davie wrote:
However, when the user clicks on item B after clicking on item A,
setSelected:NO is *not* sent to the NSCollectienViewItem subclass for A
On Mar 2, 2010, at 10:52 AM, Thomas Davie wrote:
> The NSCollectionView certainly *thought* it was being deselected – if the
> user clicks A, then A again, only one setSelected:YES gets sent, if the user
> clicks A, then B, then A again, setSelected:YES gets sent to A twice and B
> once.
>
> I'
On Mar 2, 2010, at 3:36 AM, Thomas Davie wrote:
>> On Mar 1, 2010, at 2:42 PM, Thomas Davie wrote:
>>> However, when the user clicks on item B after clicking on item A,
>>> setSelected:NO is *not* sent to the NSCollectienViewItem subclass for A.
>>> This displeases me greatly :(.
>>
>>
>> Work
On Mar 1, 2010, at 2:42 PM, Thomas Davie wrote:
> However, when the user clicks on item B after clicking on item A,
> setSelected:NO is *not* sent to the NSCollectienViewItem subclass for A.
> This displeases me greatly :(.
Works fine for me. Are you sure it's not called/set? Put a breakpoint
