Архитектура события

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

Для дальнейшего фона, О Проекте Приложения OS X в Руководстве по программированию Приложения Mac рекомендуется, читая.

Как событие вводит приложение какао

Событие является низкоуровневой записью пользовательского действия, обычно направляющегося к приложению, в котором произошло действие. Когда пользователь управляет устройством ввода данных, присоединенным к компьютерной системе, такой как клавиатура, мышь или стилус планшета, типичное событие в OS X происходит. Когда пользователь нажимает клавишу или нажимает кнопку или перемещает стилус, устройство обнаруживает действие и инициирует передачу данных к драйверу устройства, связанному с ним. Через Набор I/O драйвер устройства создает низкоуровневое событие, помещает его в очередь событий сервера окна и уведомляет сервер окна. Сервер окна диспетчеризирует событие надлежащему порту цикла выполнения целевого процесса. Оттуда событие передается к механизму обработки событий, надлежащему среде приложения. Рисунок 1-1 изображает эту систему доставки события.

Рисунок 1-1  поток событий
The event stream

Прежде чем это диспетчеризирует событие приложению, серверные процессы окна это в различных способах; это добавляет метку времени к нему, аннотирует его связанным окном и портом процесса, и возможно выполняет другие задачи также. Как пример, рассмотрите то, что происходит, когда пользователь нажимает клавишу. Драйвер устройства переводит необработанный код сканирования в код виртуальной клавиши, который это тогда выдает (вместе с другой информацией о нажатии клавиши) к серверу окна в записи события. Сервер окна имеет средство перевода, преобразовывающее код виртуальной клавиши в символ Unicode.

В OS X события поставлены как асинхронный поток. Этот поток событий продолжается «вверх» (в архитектурном смысле) через различные уровни системы — аппаратных средств к серверу окна менеджеру по корпоративным мероприятиям — пока каждое событие не достигает своего конечного места назначения: приложение. Поскольку это проходит через каждую подсистему, событие может изменить структуру, но это все еще идентифицирует определенное пользовательское действие.

Каждое приложение имеет механизм, определенный для его среды для получения событий от сервера окна. Для приложения Какао тот механизм вызывают основным циклом событий. Цикл выполнения, который в Какао является NSRunLoop возразите, позволяет процессу получить ввод от различных источников. По умолчанию каждый поток в OS X имеет свой собственный цикл выполнения, и цикл выполнения основного потока приложения Какао вызывают основным циклом событий. То, что особенно различает, основной цикл событий является входным источником, вызвало источник события, создающийся когда глобальная переменная NSApplication объект (NSApp) инициализируется. Источник события состоит из порта для получения событий от сервера окна и очереди FIFO — очереди событий — для того, чтобы провести те мероприятия, пока приложение не может обработать их, как показано на рисунке 1-2.

Рисунок 1-2  основной цикл событий, с источником события
The main event loop, with event source

Приложение Какао управляемо событиями: Это выбирает событие от очереди, диспетчеризирует его надлежащему объекту, и, после того, как событие обрабатывается, выбирает следующее событие. За некоторыми исключениями (такими как модальные циклы событий) приложение продолжается в этом образце, пока пользователь не выходит из него. Следующий раздел, Отгрузка События, описывает, как приложение выбирает и диспетчеризирует события.

События, поставленные через источник события, не являются единственными видами событий, вводящих приложения Какао. Приложение может также реагировать на события Apple, высокоуровневые межпроцессные события, обычно отправленные другими процессами, такими как Finder and Launch Services. Например, когда пользователи дважды щелкают по значку приложения, чтобы открыть приложение или дважды щелкнуть по документу для открытия документа, событие Apple отправляется в целевое приложение. Приложение также выбирает события Apple от очереди, но это не преобразовывает их в NSEvent объекты. Вместо этого событие Apple обрабатывается непосредственно обработчиком событий. Когда приложение запускается, оно автоматически регистрирует несколько обработчиков событий с этой целью. Для больше на событиях Apple и обработчиках событий, см. Руководство по программированию Событий Apple.

Отгрузка события

В основном цикле событий, объект приложения (NSApp) постоянно получает следующее (самое верхнее) событие в конечном счете очередь, преобразовывает его в NSEvent объект и отгрузки это к его конечному месту назначения. Это выполняет эту выборку событий путем вызова nextEventMatchingMask:untilDate:inMode:dequeue: метод в замкнутом цикле. Когда нет никаких событий в конечном счете очереди, этот метод блоки, возобновляясь только, когда существует больше событий для обработки.

После выборки и преобразования события, NSApp выполняет первую стадию диспетчеризации события в sendEvent: метод. В большинстве случаев NSApp просто передает событие к окну, в котором пользовательское действие произошло путем вызова sendEvent: метод этого NSWindow объект. Объект окна тогда диспетчеризирует большинство событий NSView объект связался с пользовательским действием в NSResponder передайте такой как mouseDown: или keyDown:. Сообщение о событии включает как собственный параметр NSEvent объект, описывающий событие.

Объект, получающий сообщение о событии, отличается немного типом события. Для мыши и событий планшета, NSWindow возразите диспетчеризирует событие представлению, по которому пользователь щелкнул кнопка стилуса или мышь. Это диспетчеризирует большинство ключевых событий первому респонденту ключевого окна. Рисунок 1-3 и рисунок 1-4 иллюстрируют эти различные пути общей доставки. Целевое представление может решить не обработать событие, вместо этого передав его цепочка респондента (см. Цепочку Респондента).

  Путь рисунка 1-3
Path of a mouse event
  Пути мыши eventFigure 1-4 ключевого события (символ для вставки)
Path of a key event (character to insert)

В предыдущем абзаце Вы, возможно, заметили использование спецификаторов такой как «в большинстве случаев» и “обычно “. Поставка события (и особенно ключевое событие) в Какао может взять много различных путей в зависимости от определенного вида события. Некоторые события, многие из которых определяются Набором Приложения (тип NSAppKitDefined), имейте отношение к действиям, которыми управляет окно или сам объект приложения. Примеры этих событий - связанные с активацией, деактивацией, сокрытием и показом приложения. NSApp отфильтровывает эти события рано в его подпрограмме отгрузки и обрабатывает их самой.

Следующие разделы описывают различные пути событий, которые могут достигнуть Ваших объектов представления. Для получения дальнейшей информации на этих типах событий, считайте Объекты-события и Типы.

Путь событий мыши и планшета

Как отмечено выше, NSWindow объект в sendEvent: метод вперед события от нажатия мыши к представлению, по которому произошло пользовательское действие, включающее мышь. Это идентифицирует представление для получения события путем вызова NSView метод hitTest:, который возвращает самого низкого потомка, содержащего позицию курсора события (это обычно - самое верхнее выведенное на экран представление). Объект окна вперед событие от нажатия мыши к этому представлению путем отправки ему связанного с мышью NSResponder обменивайтесь сообщениями определенный для его точного типа, такой как mouseDown:, mouseDragged:, или rightMouseUp:, На (левых) событиях mouseDown объект окна также спрашивает представление получения, готово ли это стать первым респондентом для последующих ключевых событий и сообщений действия.

Объект представления может получить события от нажатия мыши трех общих типов: щелчки мышью, мышь перетаскивает, и движения мыши. События щелчка мышью далее категоризированы — как определенные NSEventType константы и NSResponder методы — кнопкой мыши (оставленный, право или другой) и направление щелчка (или вниз). Перетащенный мышью и события mouseUp обычно отправляются в то же представление, получившее новое событие mouseDown. Перемещенные в мышь события отправляются первому респонденту. Мышь вниз, перетащенная мышью, мышь и перемещенные в мышь события, может произойти только в определенных ситуациях относительно других событий от нажатия мыши:

  • Каждому событию mouseUp должно предшествовать событие mouseDown.

  • Перетащенные мышью события имеют место только между событием mouseDown и событием mouseUp.

  • Перемещенные в мышь события не имеют место между мышью вниз и событием mouseUp.

События mouseDown отправляются, когда пользователь нажимает кнопку мыши, в то время как курсор по объекту представления. Если окно, содержащее представление, не является ключевым окном, окно становится ключевым окном и отбрасывает событие mouseDown. Однако представление может обойти это поведение по умолчанию путем переопределения acceptsFirstMouse: метод NSView возвратиться YES.

Представления автоматически получают по которым щелкают мышью и перетащенные мышью события, но потому что перемещенные в мышь события имеют место так часто и могут сорвать очередь событий, объект представления должен явно запросить свое окно наблюдать за ними использующий NSWindow метод setAcceptsMouseMovedEvents:. Отслеживание прямоугольников, описанных в Другой Диспетчеризации События, является менее дорогим способом следовать за расположением мыши.

В его реализации NSResponder метод события от нажатия мыши, подкласс NSView может интерпретировать событие от нажатия мыши как сигнал для выполнения определенных действий, таких как отправка сообщения целевого действия, выбор графического элемента, перерисовка себя в различном расположении, и т.д. Каждый метод события включает как собственный параметр NSEvent объект, из которого представление может получить информацию о событии. Например, представление может использовать locationInWindow определять местоположение горячей точки курсора мыши в системе координат окна получателя. Для преобразования его в систему координат представления использовать convertPoint:fromView: с a nil параметр представления. Отсюда, можно использовать mouse:inRect: определить, произошел ли щелчок в интересной области.

События планшета берут путь к поставке представлению, которое подобно этому для событий от нажатия мыши. NSWindow объект, представляющий окно, в котором табличное событие имело место, передает событие к представлению под курсором. Однако существует два вида событий планшета, событий близости и событий указателя. Прежний - обычно собственные события планшета (типа NSTabletProximity) сгенерированный, когда стилус перемещается в и из близости к планшету. События указателя планшета имеют место между вводящими близость и оставляющими близость событиями планшета и указывают такие вещи как направление стилуса, давление и нажатие кнопки. События указателя обычно являются подтипами событий от нажатия мыши. Обратитесь к Обработке Событий Планшета для получения дополнительной информации.

Для путей, взятых событиями отслеживания мыши и обновления курсора, посмотрите, что Другое Событие Диспетчеризирует.

Путь ключевых событий

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

Приложение Какао оценивает каждое ключевое событие для определения, какое ключевое событие это и затем обрабатывает надлежащим способом. Путь, который может взять ключевое событие, прежде чем это будет обработано, может быть довольно длинным. Рисунок 1-5 показывает эти потенциальные пути.

Рисунок 1-5  Возможный путь ключевого события
Possible path of a key event

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

  1. Ключевые эквиваленты. Ключевой эквивалент является сочетанием клавиш или сочетанием клавиш (обычно ключ, измененный Командной клавишей), который обычно связывается с некоторым пунктом меню или объектом управления в приложении. Нажатие сочетания клавиш моделирует действие щелчка по управлению или выбора пункта меню.

    Объект приложения обрабатывает ключевые эквиваленты путем потери работоспособности иерархии представления в ключевом окне, отправки каждого объекта a performKeyEquivalent: сообщение до объекта возвращается YES. Если сообщение не обрабатывается объектом в иерархии представления, NSApp тогда отправляет его в меню в строке меню. Некоторые классы Какао, такой как NSButton, NSMenu, NSMatrix, и NSSavePanel обеспечьте реализации по умолчанию.

    Для получения дополнительной информации посмотрите Ключевые Эквиваленты Обработки.

  2. Управление интерфейсом клавиатуры. Событие управления интерфейсом клавиатуры управляет фокусом ввода среди объектов в пользовательском интерфейсе. В ключевом окне, NSWindow интерпретирует определенные ключи как команды, чтобы переместить управление в различный интерфейсный объект, моделировать щелчок мышью по нему, и т.д. Например, нажатие клавиши Tab перемещает фокус ввода в следующий объект; Shift-Tab изменяет направление; нажатие клавиши «Пробел» моделирует щелчок по кнопке. Порядок интерфейсных объектов, которыми управляют через этот механизм, указан ключевым циклом представления. Можно установить ключевой цикл представления в Интерфейсном Разработчике, и можно управлять ключевым циклом представления программно через setNextKeyView: и nextKeyView методы NSView.

    Для получения дополнительной информации посмотрите Управление Интерфейсом Клавиатуры.

  3. Действие клавиатуры. В отличие от сообщений действия, что средства управления отправляют к их целям (см. сообщения Действия), действия клавиатуры являются командами (представленный методами, определенными NSResponder класс), которые являются функциональными интерпретациями на представление физических нажатий клавиш (как идентифицировано константой, возвращенной characters метод NSEvent). Другими словами, действия клавиатуры связываются с физическими ключами через механизм привязок клавиш, описанный в текстовых Системных значениях по умолчанию и Привязках клавиш. Например, pageDown:, moveToBeginningOfLine:, и capitalizeWord: когда связанная клавиша нажата, методы, вызванные действиями клавиатуры. Такие действия отправляются первому респонденту, и методы, обрабатывающие эти действия, могут быть реализованы в том представлении или в суперпредставлении далее цепочка респондента.

    Посмотрите Переопределение keyDown: Метод для получения дополнительной информации об обработке действий клавиатуры.

  4. Символ (или символы) для вставки как текст.

Если объект приложения обрабатывает ключевое событие, и это, оказывается, не ключевой эквивалент или ключевое интерфейсное событие управления, это тогда отправляет его в ключевое окно в a sendEvent: сообщение. Объект окна вызывает keyDown: метод в первом респонденте, откуда ключевое событие перемещается цепочка респондента, пока это не обрабатывается. В этой точке ключевое событие может быть или одним или более символами Unicode, которые будут вставлены в отображаемый текст представления, сочетание клавиш или сочетание клавиш, которое будет особенно интерпретироваться, или событие действия клавиатуры.

Посмотрите Ключевые события Обработки для получения дополнительной информации о том, как ключевые события диспетчеризируются и обрабатываются.

Другая диспетчеризация события

NSWindow объект следит за развитием событий прямоугольника отслеживания и диспетчеризирует эти события непосредственно объекту владения в mouseEntered: и mouseExited: сообщения. Владелец указан во втором параметре NSTrackingArea метод initWithRect:options:owner:userInfo: и NSView методaddTrackingRect:owner:userData:assumeInside:. Используя область отслеживания Объекты описывает, как установить прямоугольники отслеживания и обработать связанные события.

Периодические события (тип NSPeriodic) сгенерированы приложением в указанной частоте и помещены в конечном счете очередь. Однако в отличие от большинства других типов событий, периодические события не диспетчеризируются с помощью sendEvent: механизм NSApplication и NSWindow. Вместо этого объект, регистрирующийся для периодических событий обычно, получает их в модальном цикле событий с помощью nextEventMatchingMask:untilDate:inMode:dequeue: метод. Посмотрите Другие Типы Событий для получения дополнительной информации о периодических событиях.

Сообщения действия

Обсуждение до сих пор фокусировалось на сообщениях о событиях: сообщения, являющиеся результатом связанного с устройством события, такие как щелчок мышью или нажатие клавиши. Набор Приложения отправляет сообщение о событии соответствующей формы — например, mouseDown: и keyDown:— к NSResponder объект для обработки.

Но NSResponder объекты, как также ожидают, обработают другой вид сообщения: сообщения действия. Действия являются командами, который возражает, обычно NSControl или NSMenu объекты, дайте объекту приложения для диспетчеризации как сообщения определенной цели или любой цели, это готово реагировать на них. Методы, вызванные сообщениями действия, имеют определенную подпись: единственный параметр, содержащий ссылку на объект, инициирующий сообщение действия; условно, имя этого параметра является отправителем. Например, 

- (void)moveToEndOfLine:(id)sender; // from NSResponder.h

Событие и методы действия диспетчеризируются по-разному различными методами. Почти все события вводят приложение от сервера окна и диспетчеризируются автоматически sendEvent: метод NSApplication. Сообщения действия, с другой стороны, диспетчеризируются sendAction:to:from: метод глобального объекта приложения (NSApp) их надлежащим местам назначения.

Столь же проиллюстрированный на рисунке 1-6, сообщения действия обычно отправляются как побочный эффект сообщения о событии. Когда пользователь щелкает по объекту управления, такому как кнопка, два сообщения о событиях (mouseDown: и mouseUp:) отправляются в результате. Управление и его связанная ячейка обрабатывают mouseUp: сообщение (частично) путем отправки объекта приложения a sendAction:to:from: сообщение. Первым параметром является селектор, идентифицирующий метод действия вызвать. Вторым является предполагаемый получатель сообщения, названного целью, которая может быть nil. Заключительным параметром обычно является объектный вызов sendAction:to:from:, таким образом указывая, какой объект инициировал сообщение действия. Цель сообщения действия может передать сообщения обратно отправителю для получения дополнительной информации. Подобная последовательность происходит для меню и пунктов меню. Для больше на архитектуре средств управления и ячеек (и меню и пункты меню) см. Проект Базового приложения в Руководстве по программированию Приложения Mac.

Рисунок 1-6  От сообщения о событии до сообщения действия
From event message to action message

Цель сообщения действия обрабатывается Набором Приложения специальным способом. Если намеченная цель не nil, действие просто отправляется непосредственно в тот объект; это вызывают сообщением террористического акта. В случае непредназначенного сообщения действия (т.е. целевой параметр nil), sendAction:to:from: поиски полная цепочка респондента (начиная с первого респондента) для объекта, реализующего указанный метод действия. Если это находит один, это отправляет сообщение в тот объект с инициатором сообщения действия как единственный параметр. Получатель сообщения действия может тогда запросить отправителя для получения дополнительной информации. Можно найти получателя непредназначенного сообщения действия, фактически не отправляя использование сообщения targetForAction:.

Сообщения о событиях формируют известный набор, таким образом, NSResponder обеспечивает объявления и реализации по умолчанию для всех них. Большинство сообщений действия, однако, определяется пользовательскими классами и не может быть предсказано. Однако NSResponder действительно объявляет много методов действия клавиатуры, такой как pageDown:, moveToBeginningOfDocument:, и cancelOperation:. Эти методы действия обычно связываются с определенными ключами с помощью механизма привязок клавиш и предназначаются для выполнения перемещения курсора, текстовых операций и подобных операций.

Более общая отгрузка сообщения механизма действия предоставлена NSResponder метод tryToPerform:with:. Этот метод проверяет получатель, чтобы видеть, реагирует ли это на селектор если, раз так вызывая сообщение. В противном случае это отправляет tryToPerform:with: его следующему респонденту. NSWindow и NSApplication переопределите этот метод для включения их делегатов, но они не соединяют отдельные цепочки респондента в пути который sendAction:to:from: метод делает. Подобный tryToPerform:with: doCommandBySelector:, который берет селектор метода и пытается найти респондента, реализующего его. Если ни один не найден, метод заставляет аппаратные средства подавать звуковой сигнал.

Респонденты

Респондент является объектом, который может получить события, или непосредственно или через цепочку респондента, на основании ее наследования от NSResponder класс. NSApplication, NSWindow, NSDrawer, NSWindowController, NSView и много потомков этих классов в Наборе Приложения наследовались от NSResponder. Этот класс определяет программируемый интерфейс для приема сообщений о событиях и многих сообщений действия. Это также определяет общую структуру поведения респондента. В цепочке респондента существует первый респондент и последовательность следующих респондентов

Для больше на цепочке респондента, посмотрите Цепочку Респондента.

Первые респонденты

Первый респондент обычно является объектом пользовательского интерфейса, который пользователь выбирает или активирует мышью или клавиатурой. Это обычно - первый объект в цепочке респондента, который получит сообщение действия или событие. NSWindow первый респондент объекта первоначально самостоятельно; однако, можно установить, программно и в Интерфейсном Разработчике, объект, сделанный первым респондентом, когда окно является занявшим первое место на экране.

Когда NSWindow объект получает событие mouseDown, он автоматически пытается сделать NSView объект под событием первый респондент. Это делает так путем выяснения у представления, хочет ли это стать первым респондентом, с помощью acceptsFirstResponder метод определяется этим классом. Этот метод возвраты NO по умолчанию; респондент разделяет на подклассы, который должен быть первым респондентом, должен переопределить его для возврата YES. acceptsFirstResponder когда пользователь изменяет первого респондента через функцию управления интерфейсом клавиатуры, метод также вызывается.

Можно программно изменить первого респондента путем отправки makeFirstResponder: к NSWindow объект. Это сообщение инициирует своего рода протокол, в котором объект теряет свое первое состояние респондента, и другой получает его. Посмотрите Установку Первого Респондента для получения дополнительной информации.

NSPanel возразите представляет изменение поведения первого респондента, разрешающего панелям представлять пользовательский интерфейс, не устраняющий ключевой фокус из главного окна. Если объект панели представление неактивного окна и возврат YES от becomesKeyOnlyIfNeeded получает событие mouseDown, оно пытается сделать объект представления под указателем мыши первым респондентом, но только если возвращается тот объект YES в acceptsFirstResponder и needsPanelToBecomeKey.

Перемещенные в мышь события (тип NSMouseMoved) всегда отправляются первому респонденту, не представлению под мышью.

Следующие респонденты

Каждый объект респондента имеет встроенную возможность получения следующего респондента цепочка респондента. nextResponder метод, возвращающий этот объект, является существенным механизмом цепочки респондента. Рисунок 1-7 показывает последовательность следующих респондентов.

Рисунок 1-7  цепочка следующих респондентов
The chain of next responders

Следующий респондент представления всегда является его суперпредставлением — большая часть цепочки респондента, фактически, включает представления от первого респондента окна до довольного представление. Когда Вы создаете окно или добавляете подпредставления к существующим представлениям, или программно или в Интерфейсном Разработчике, Набор Приложения автоматически поднимает трубку следующих респондентов в цепочке респондента. addSubview: метод NSView автоматически устанавливает получатель как суперпредставление нового подпредставления. Если Вы вмешиваетесь различный респондент между представлениями, несомненно, проверят и потенциально фиксируют цепочку респондента после добавления или удаления представлений от иерархии представления.

Цепочка респондента

Цепочка респондента является соединенной серией объектов респондента, к которым применяется сообщение события или действия. Когда данный объект респондента не обрабатывает определенное сообщение, объект передает сообщение своему преемнику в цепочке (т.е. его следующий респондент). Это позволяет объектам респондента делегировать ответственность за обработку сообщения к другому, обычно объектам более высокого уровня. Набор Приложения автоматически создает цепочку респондента, как описано ниже, но можно вставить пользовательские объекты в части его с помощью NSResponder метод setNextResponder: и можно исследовать его (или пересечь его) с nextResponder.

Приложение может содержать любое число цепочек респондента, но только один активен в любой момент времени. Цепочка респондента отличается для сообщений о событиях и сообщений действия, как описано в следующих разделах.

Цепочка респондента для сообщений о событиях

Почти все сообщения о событиях применяются к цепочке респондента единственного окна — окно, в котором произошло связанное пользовательское событие. Цепочка респондента по умолчанию для сообщений о событиях начинается с представления что NSWindow объект сначала передает сообщение к. Цепочка респондента по умолчанию для сообщения ключевого события начинается с первого респондента в окне; цепочка респондента по умолчанию для мыши или события планшета начинается с представления, на котором произошло пользовательское событие. Оттуда событие, если не обработанный, продолжает иерархию представления к NSWindow объект, представляющий само окно. Первый респондент обычно является «выбранным» объектом представления в окне, и его следующий респондент является его содержанием представления (также названный его суперпредставлением), и т.д. до NSWindow объект. Если NSWindowController объект управляет окном, это становится финалом следующий респондент. Можно ввести других респондентов между NSView объекты и даже выше NSWindow возразите около вершины цепочки. Эти введенные респонденты получают и событие и сообщения действия. Если никакой объект, как не находят, обрабатывает событие, последний респондент в цепочке вызывает noResponderFor:, который для ключевого вниз события просто подает звуковой сигнал. Объекты обработки событий (подклассы NSWindow и NSView) может переопределить этот метод для выполнения дополнительных шагов по мере необходимости.

Цепочка респондента для сообщений действия

Для сообщений действия Набор Приложения создает более тщательно продуманную цепочку респондента, варьирующуюся согласно двум факторам:

  • Основывается ли приложение на архитектуре документа и, если это не, использует ли это NSWindowController объекты для его окон

  • Выводит ли приложение в настоящее время на экран ключевое окно, а также главное окно

Сообщения действия имеют более тщательно продуманную цепочку респондента, чем делают сообщения о событиях, потому что действия требуют более гибкого механизма во время выполнения для определения их целей. Они не ограничиваются единственным окном, как сообщения о событиях.

Самый простой случай является активным не, документ базировал окно, не имеющее никакой связанной панели или вторичного выведенного на экран окна — другими словами, главное окно, которое является также ключевым окном. В этом случае цепочка респондента является следующим:

  1. Первый респондент главного окна и последовательный респондент возражают иерархии представления

  2. Само главное окно

  3. Делегат главного окна (который не должен наследоваться от NSResponder)

  4. Объект приложения, NSApp

  5. Делегат объекта приложения (который не должен наследоваться от NSResponder)

Эта цепочка показана графически на рисунке 1-8.

  Цепочка Респондента рисунка 1-8 не документа базировала приложение для сообщений действия
Responder chain of a non-document-based application

Поскольку эта последовательность указывает, NSWindow возразите и NSApplication объект дает их делегатам шанс обработать сообщения действия, как будто они были респондентами, даже при том, что делегат не находится формально в цепочке респондента (т.е. a nextResponder обменивайтесь сообщениями к объекту окна, или объект приложения не возвращает делегата).

Когда приложение выводит на экран и главное окно и ключевое окно, цепочки респондента обоих окон могут быть вовлечены в сообщение действия. Как объяснено в Разделении на уровни Окна и Типах Windows, главное окно является frontmost окном документа или окном приложения. Часто главные окна также имеют ключевое состояние, означая, что они - текущий фокус ввода данных пользователем. Но главное окно может иметь вторичное окно или панель, связанную с ним, такую как панель Find или показ окна Info подробные данные выбора в окне документа. Когда это вторичное окно является фокусом ввода данных пользователем, тогда это - ключевое окно.

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

  1. Первый респондент ключевого окна и последовательный респондент возражают иерархии представления

  2. Само ключевое окно

  3. Делегат ключевого окна (который не должен наследоваться от NSResponder)

  4. Первый респондент главного окна и последовательный респондент возражают иерархии представления

  5. Само главное окно

  6. Делегат главного окна (который не должен наследоваться от NSResponder)

  7. Объект приложения, NSApp

  8. Делегат объекта приложения (который не должен наследоваться от NSResponder)

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

  1. Первый респондент главного окна и последовательный респондент возражают иерархии представления

  2. Само главное окно

  3. Окно NSWindowController объект (который наследовался от NSResponder)

  4. Делегат главного окна

  5. Объект приложения, NSApp

  6. Делегат объекта приложения

Рисунок 1-9 показывает цепочку респондента не, документ базировал приложение, использующее объект NSWindowController.

  Цепочка Респондента рисунка 1-9 приложения недокумента с NSWindowController объект (сообщения действия)
Responder chain of a non-document application with an NSWindowController objectResponder chain of a non-document application with an NSWindowController object

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

  1. Первый респондент главного окна и последовательный респондент возражают иерархии представления

  2. Само главное окно

  3. Окно NSWindowController объект (который наследовался от NSResponder)

  4. Делегат главного окна.

  5. NSDocument объект (если отличающийся от делегата главного окна)

  6. Объект приложения, NSApp

  7. Делегат объекта приложения

  8. Контроллер документа приложения ( NSDocumentController объект, не наследовавшийся от NSResponder)

Рисунок 1-10 показывает цепочку респондента основанного на документе приложения.

  Цепочка Респондента рисунка 1-10 основанного на документе приложения для сообщений действия
Responder chain of a document-based application

Другое использование

Цепочка респондента используется тремя другими механизмами в Наборе Приложения:

  • Автоматический пункт меню и включение элемента панели инструментов: В автоматическом включении и отключении пункта меню с a nil цель, NSMenu ищет различные цепочки респондента в зависимости от того, представляет ли объект меню меню приложения или контекстное меню. Для меню приложения, NSMenu консультируется с полной цепочкой респондента — т.е. первый ключ, затем главное окно — для нахождения объекта, реализующего метод действия пункта меню и (если это реализует его), возвраты YES от validateMenuItem:. Для контекстного меню поиск ограничивается цепочкой респондента окна, в котором контекстное меню было выведено на экран, начиная со связанного представления.

    Включение и отключение элементов панели инструментов используют цепочку респондента способом, идентичным тому из пунктов меню. В этом случае ключевой метод проверки validateToolbarItem:.

    Для больше на автоматическом включении пункта меню, посмотрите Пункты меню Включения; для больше на проверке элементов панели инструментов, посмотрите Элементы Панели инструментов Проверки.

  • Приемлемость служб: Точно так же передачи средства Служб validRequestorForSendType:returnType: сообщения вдоль полной цепочки респондента для проверки на объекты, которые приемлемы на услуги, предложенные другими приложениями.

    Для получения дополнительной информации см. Руководство по внедрению Служб.

  • Ошибочное представление: Набор Приложения использует измененную версию цепочки респондента для обработки ошибок и ошибочного представления, центрируемого на NSResponder методы presentError:modalForWindow:delegate:didPresentSelector:contextInfo: и presentError:.

    Для получения дополнительной информации о цепочке ошибочного респондента см. Руководство по программированию Обработки ошибок.