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: Pandaa <email@hidden>
- Date: Tue, 14 Jun 2005 18:12:17 +0200
14 jun 2005 kl. 16.42 skrev Theodore H. Smith:
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.
No, it only needs to be done before the user opens a menu or presses
a key shortcut.
But to do it "once just before the user gets a chance to create user
events" you need to track the responder chain. Which working with
NSMenuValidation would already do for you.
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.
. . ..so?
On a 350mhz G3, the menus were instant.
Also, more importantly, the code was good code.
?
What constitutes good code is a matter of personal opinion and how it
fits into a larger context. Do not state it like an isolated fact.
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.
That sounds like a bad design decision to me, I fear it may entangle
logic from logically distinct parts of your application. Or you may
end up writing something to manually track the responder chain
anyway, at which point it would have been easier to write statefull
menu validation code instead.
Remember, it is you who have insisted that the menu validation code
must be an "if-table".
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????
Your code sample gave the impression you wanted to call setEnabled:
when [tableView selectedRow] changed. If you had been more careful to
tell us you meant to do it in one large validation method that would
get called at the same times NSMenuValidation does its' work, perhaps
the misunderstanding could have been avoided.
I think that what I want to do, might just not be simple to do in
Cocoa, although it is in other languages.
Cocoa is not a language.
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.
There are conceptual differences between frameworks. If you can't
cope with that, and see application programming from different fresh
angles, please don't talk about what's "graceful" or not. Just
because you're used to doing it one way doesn't mean that's the best
or only way.
Fighting the framework does not help you write a better application.
Adapting your ways and views does.
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. email@hidden . . www.synapticpulse.net .
_______________________________________________
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