Лучший способ подключить NSMenuItems от Interface Builder?

Question

Поэтому я потратил некоторое время на проверку CocoaDev, на чтение документов Cocoa по NSMenuItems и на выполнение некоторых тестов в Интерфейсном Разработчике.

В моем приложении у меня есть меню приложения ([NSApp mainMenu]), разработанноев Интерфейсном Разработчике.Я вижу три возможных пути:

1. Поместите мои ответчики действий в NSApplicationDelegate.Мне это кажется странным, частично потому, что он находится далеко в пищевой цепочке, частично потому, что он, кажется, закреплен.

2. Создайте подпредставление (я), которое будет прослушивать различные NSMenuItemсообщения действий.Это может показаться полезным, но похоже, что для того, чтобы он находился в цепочке респондента, может быть какая-то магия, которую я не смог понять.

3. Создайте объект NSO, который слушает конкретныйменю приложения, поместите его в xib и подключите.Это кажется мне лучшим решением на данный момент, потому что я могу изолировать вещи, и не зависеть от цепочки респондента, чтобы достигнуть определенного объекта.НО мне интересно, если, когда я получаю свое приложение на достаточном уровне сложности, это может быть проблемой, потому что это узурпирует цепочку респондента, которая существует, возможно, по причине, выходящей за рамки простоты использования.

Извините за длинный вопрос.Есть ли предпочтительный подход?Спасибо!

Answer 1

Это действительно зависит от архитектуры вашего приложения.Как правило, выполняйте действия везде, где они имеют смысл.В этом отношении вам помогает цепочка респондентов для сообщений действий.

Если ваше приложение не основано на документах, цепочка респондентов для сообщений действий выглядит следующим образом:

1. Какой бы респондент не былпервый респондент
2. Просмотр иерархии
3. Окно
4. Контроллер окна
5. Делегат окна
6. NSApp
7. Приложениеделегат

Я использую действия в делегате приложения, только если они действительно глобальные для всего приложения.В противном случае я помещаю их в контроллер окна (который обычно также является делегатом окна), если они имеют смысл для конкретного окна, или в контроллер представления, если они имеют смысл для конкретного представления.

Стоит упомянутьчто контроллеры представления (подклассы NSViewController) не вставляются автоматически в цепочку респондента.Я делаю это вручную после добавления соответствующего представления в суперпредставление.Например, в подклассе NSViewController:

NSResponder *nextResponder = [[self view] nextResponder];
[[self view] setNextResponder:self];
[self setNextResponder:nextResponder];

Это вставит self (экземпляр подкласса NSViewController) в цепочку респондента между представлением и следующим респондентом исходного представления.

Обратите внимание, что в вашем третьем подходе нет ничего неправильного, а именно наличие конкретной цели (подмножество) сообщений действий.Цепочка респондента существует, чтобы дать возможность различным объектам обрабатывать сообщения действий, потому что некоторые действия могут зависеть от контекста.Например, действия в меню «Файл» обычно применяются к окну, которое в настоящее время является главным окном, поэтому имеет смысл не указывать конкретную цель и вместо этого использовать цепочку респондента.С другой стороны, действия в меню ApplicationName действительно глобальны - им не нужно проходить через цепочку респондента, поэтому вы можете подключить их к определенной цели.

Answer 2

Я обычно просто выставляю IBActions в контроллере приложения (NSApp делегат) и подключаю пункты меню к этим действиям.Это довольно стандартный способ ведения дел.Если у вас много пунктов меню, вы также можете разбить функциональность на один или несколько контроллеров, которые подключены к контроллеру приложения, и подключить пункты меню к ним.