Re: NSMenu setTarget method causes intermittent crashes?

On Sep 15, 2009, at 4:14, Duncan Champney wrote:

>
> On Sep 14, 2009, at 7:15 PM, Greg Titus wrote:
>
>>
>> On Sep 14, 2009, at 4:09 PM, Duncan Champney wrote:
>>
>>>     [a_menu_item setView: self];
>>
>>
>> Duncan,
>>
>> I believe the above line of code is the trouble. The -setView:  
>> method on NSMenuItem is for placing a custom view _inside_ the menu  
>> item, and has nothing to do with the target. (See the NSMenuItem  
>> documentation.) Frankly, I'm surprised you aren't running into  
>> trouble long before the garbage collector does anything if you are  
>> setting this to a view which is already in the visible view  
>> hierarchy of your app's windows.
>>
>> Hope this helps,
>>  - Greg
>
>
> Greg,
>
> I didn't explain that as clearly as I should have.
>
> The way we create our objects is a little unusual. The view object  
> creates the menu, and the menu object creates the menu item object  
> and calls the menu item's setView and setTarget methods. The view  
> object doesn't exist in the view hierarchy except as the view of the  
> menu item.
>
> So even though our code creates the objects in an unusual order the  
> way they are presented to the system is correct.
>
> The reason we do this is that our popup menu only contains one  
> NSMenuItem. That menu item contains a custom view that draws a grid  
> of objects in rows and columns. Those objects act like menu items,  
> but they are really one single menu item. That lets us support a  
> grid of objects rather than a single column of menu items.
>
> In our code the custom view is the object that contains the special  
> behavior. We have a general popup view class that has the code to  
> create the popup menu, add an item, and attach itself to the menu  
> item as the view object. Each subclass of view object implements the  
> special behavior for that type of popup. That way we only have to  
> subclass one object (the view) in order to create a new kind of  
> popup menu.
>
>
> Duncan Champney
> WareTo

I really can't think of any reason why you'd want such a convoluted  
circular ownership cycle. My advice would be to make the ownership  
graph a tree without cycles. Who's owning the view? Why doesn't it  
just own the menu? Why do you even set the target of the menu item, as  
that's not functional with a view anyway?

Christiaan