Re: Getting a reference to an NSMenuItem from another nib?
Re: Getting a reference to an NSMenuItem from another nib?
- Subject: Re: Getting a reference to an NSMenuItem from another nib?
- From: Sherm Pendley <email@hidden>
- Date: Tue, 14 Jun 2005 10:13:42 -0400
On Jun 14, 2005, at 9:34 AM, Theodore H. Smith wrote:
"If tables" are just not good. I do not like them. They are bad
code, hard to maintain, look ugly. What if I type one of those
titles in the code wrong? Or what if I change the menu due to a
request from company management? Or what if the titles then get
localised?
Sure I can use tags, but that also is a bit yucky.
Instead of doing things in such an "if table" way, using hard coded
references to the exact object I want to enable, is generally clearer.
int row = [tableView selectedRow];
[menuNextRecord setEnabled: !(row == [countryKeys indexOfObject:
[countryKeyslastObject]])];
[menuPriorRecord setEnabled: (row != 0)];
You're missing the bigger picture.
You're going to need to make these calls whenever anything that
determines a menu's state would change. Changing the current
selection? Update the relevant menu items. Switching documents?
Update menu items. Etc.
You wind up with setEnabled: calls scattered throughout your code.
Worse, they're called every time the state of your model changes,
instead of only when needed to display a particular menu item.
NSMenuValidation keeps all of your menu validation code in a single
method that's only called when it's needed. You know exactly where to
look if you need to make changes, so it's easy to maintain.
Frankly, I think that jumping through hoops trying to do things
manually is a lot uglier than an "if table".
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden