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: "Theodore H. Smith" <email@hidden>
- Date: Tue, 14 Jun 2005 15:42:22 +0100
On 14 Jun 2005, at 15:13, Sherm Pendley wrote:
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".
Based upon what measurement? The code itself? Your understanding of
the code? The readability of the code? The reliability of the code
(especially when it comes to maintainability)?
I'm not missing the bigger picture. Menu enablement only needs to be
done once just before the user gets a chance to create user events.
I've written apps which have a lot of menus, including a few submenus
which are read from the file system, everytime the menus are enabled.
On a 350mhz G3, the menus were instant.
Also, more importantly, the code was good code.
There is no scattering. All the enablement goes into one method. If
that method is too big, I just split it up into smaller methods
called by one parent method, but all the menus can only be enabled
from one access point.
There is no changing the menus upon the state change. Why on Earth
would that be anymore necessary doing it this way than the other way????
I think that what I want to do, might just not be simple to do in
Cocoa, although it is in other languages. Alas. I thought of one work
around, but even that work around was not anywhere near as graceful
as doing it the normal way in more graceful languages in which the
menus were globally accessable.
_______________________________________________
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