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 17:53:01 +0200
14 jun 2005 kl. 15.34 skrev Theodore H. Smith:
On 14 Jun 2005, at 14:16, Sherm Pendley wrote:
I can see myself wanting to often draw up connections between
different nibs. How is this best done, in general?
In general, it's best *not* done. If you find yourself thinking
you need to, it's very often a sign that you should re-think your
higher level design.
Speaking as someone who is pretty good at high level design, I can
tell you that the reason I want to avoid the NSMenuValidation
protocol, is demonstrated very well by Apple's example code:
- (BOOL)validateMenuItem:(NSMenuItem*)anItem {
int row = [tableView selectedRow];
if ([[anItem title] isEqualToString:@"Next Record"]&&
(row == [countryKeys indexOfObject:
[countryKeyslastObject]])) {
return NO;
}
if ([[anItem title] isEqualToString:@"Prior Record"]&& row == 0) {
return NO;
}
return YES;
}
Using isEqualToString indeed is a bad practice, because it is both
slower than necessary and will not work well with localization. Use
selectors instead.
"If tables" are just not good. I do not like them.
Then do not write them, you are free to implement validateMenItem: as
you see fit.
They are bad code, hard to maintain, look ugly.
That is a personal opinion.
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?
I believe the common practice is to use selectors, I'm surprised you
found string comparisons in sample code.
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.
And you can do that from validateMenuItem.
int row = [tableView selectedRow];
[menuNextRecord setEnabled: !(row == [countryKeys indexOfObject:
[countryKeyslastObject]])];
[menuPriorRecord setEnabled: (row != 0)];
In the general case you would need to first check if you are actually
the first responder for the selector sent by 'menuNextRecord' before
calling setEnabled: and have some extra logic to re-setEnabled: later
when you become first responder for the selector again.
I think that menus, being global and all, really should be globally
accessable from all the nibs. I can understand document nibs or
other nibs not being globally accessable, because there may be
multiple instances of them. But menus and apps are different, there
is only one instance of each.
That is a personal opinion. It will not help you write a better
application.
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. 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