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 14:34:12 +0100
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;
}
"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)];
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.
_______________________________________________
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