• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Binding the enabled attribute of each NSPopUpButtonCell
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Binding the enabled attribute of each NSPopUpButtonCell


  • Subject: Re: Binding the enabled attribute of each NSPopUpButtonCell
  • From: Dave Geering <email@hidden>
  • Date: Wed, 6 May 2009 15:07:11 +1000

On Wed, May 6, 2009 at 2:30 PM, Jerry Krinock <email@hidden> wrote:
> But then there would have to be another API to give it the items, and
> another to localize the titles.  Don't wish for that.

Well, it's still not too bad an idea for me. "optionTitle" is already
localised in my custom object because it comes from a localised
source, but that still leaves the other issue.


> Actually, reality is better than your dream.  The hard part is to figure out
> which hook to use.  Look at
>  -[NSPopUpButtonCell setMenu:]
>  -[NSMenu menuNeedsUpdate]
>
> The easy part is to create the menu programatically.  You start at the top,
> creating menu items, and add them to the menu as you go along.  As you
> create each menu item, you set its title, target, action, enabled,
> representedObject, etc.  It's very straightforward coding.

That doesn't sound too hard at all. I just wish I didn't have to do it
manually considering nearly all the work is done for me with bindings
(except the enabling/disabling). This way, I'd not only have to create
the menu manually but also create all the bindings for the
"optionAllowed" key.

Perhaps it's a good idea to rethink my approach of the whole thing.
Perhaps there's a better way than using popup buttons.

Say you have a list of choices for the user. Whether each choice is
available depends on more than one underlying factor (in same cases up
to 5 or 6). These factors may include whether they have chosen
something from another list or whether certain checkboxes are ticked
etc. Is it better to only show what is relevant, or to show what is
possible and what is relevant together? Would it be better to allow
the user to choose anything but warn about conflicts?

I'm not sure where the idea of disabling menu items came from, but the
rest of the view all trucks along nicely just by using KVC and
bindings.
_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

References: 
 >Binding the enabled attribute of each NSPopUpButtonCell (From: Dave Geering <email@hidden>)
 >Re: Binding the enabled attribute of each NSPopUpButtonCell (From: Ken Thomases <email@hidden>)
 >Re: Binding the enabled attribute of each NSPopUpButtonCell (From: Jerry Krinock <email@hidden>)
 >Re: Binding the enabled attribute of each NSPopUpButtonCell (From: Dave Geering <email@hidden>)
 >Re: Binding the enabled attribute of each NSPopUpButtonCell (From: Jerry Krinock <email@hidden>)

  • Prev by Date: Re: Minimize All - sends what?
  • Next by Date: Re: instantiateNibWithOwner: fails due to "mutated while enumerated"
  • Previous by thread: Re: Binding the enabled attribute of each NSPopUpButtonCell
  • Next by thread: instantiateNibWithOwner: fails due to "mutated while enumerated"
  • Index(es):
    • Date
    • Thread