Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Входной клиентский API метода позволяет клиентским компонентам реализовать интегрированные текстовые входные пользовательские интерфейсы, такие как ввод на месте. API определяет события и методы, которые облегчают передачу между клиентским компонентом и входным методом. Это также позволяет клиентскому компоненту запрашивать входной метод на определенный язык.
Так как API не делает предположений о том, как и где текст оттягивается, это может также использоваться, чтобы реализовать другие входные стили, такие как редактирование сверхпятна. В этом стиле составленный текст оттягивается по окружающему тексту и касается этого вместо того, чтобы быть интегрированным и отформатированным с этим.
Любой клиентский компонент class может стать активным клиентом входного клиентского API метода и таким образом поддерживать интегрированный текстовый входной пользовательский интерфейс, выполняя следующие шаги:
InputMethodListener взаимодействуйте через интерфейс, чтобы обработать поступление InputMethodEvents сгенерированный текущим входным методом, и регистром слушатель.InputMethodRequests интерфейс и переопределение getInputMethodRequests возвратить обработчик запроса.InputMethodHighlight атрибуты наряду с составленным текстом и передают их на подпрограммы рисунка.Дополнительно, клиентский компонент может также использовать следующую функциональность:
Клиентские компоненты не должны иметь дело с установкой входных контекстов, активированием или деактивацией контекстов, или диспетчеризацией событий, чтобы ввести методы, так как все это обрабатывается автоматически AWT.
Входная платформа метода обеспечивает событие class, InputMethodEvent, поддерживать передачу между входными методами и текстовыми компонентами. У class есть два отдельных вида события: текст изменился и измененное каре. Интерфейс слушателя события, InputMethodListener, поддерживает эти два события. Активный клиентский компонент должен реализовать InputMethodListener интерфейс, зарегистрируйте слушателя, и обработайте оба вида событий.
InputMethodEvent экземпляры отправляются клиентскому компоненту, когда есть изменение к входному тексту пользователя, его выделению, или к расположению каре в пределах составленного текста. Событие, за которым посылают, изменения только для каре являются упрощенной версией того для текстовых изменений (у этого только нет информации о тексте), таким образом, следующее обсуждение принимает измененное на текст событие.
У события, сообщая о текстовом изменении есть ссылка на экземпляр AttributedCharacterIterator это представляет или составленный текст или фиксировавший текст или обоих вместе. Фиксировавшее символьное значение количества события определяет, сколько символов в диапазоне iterator является фиксировавшим текстом; все остающиеся символы являются составленным текстом. Фиксировавший текст всегда предшествует составленному тексту. Если компонент не имеет никакого предыдущего составленного текста, фиксировавшая и составленная текстовая замена какой-либо выбранный текст или вставляется в текущей позиции вставки текста компонента. Если есть предыдущий составленный текст, весь предыдущий составленный текст заменяется новым фиксировавшим и составленным текстом. Точка вставки перемещается до конца фиксировавшего текста. Клиентский компонент ответственен за перерисовку обновленного текста.
Событие также содержит информацию о текущем расположении каре в пределах составленного текста (нуль, если никакое каре не должно быть выведено на экран), и о части составленного текста, который является самым важным, чтобы сохранить в поле зрения (нуль, если у входного метода нет рекомендации).
Текстовый компонент обычно тянет составленный текст как часть отредактированного текста, используя его регулярное текстовое расположение и таща функциональность. Однако, это должно добавить, что определенный стиль выделения приписывает составленному тексту, чтобы указать на текущее состояние состава. Платформа определяет эти атрибуты стиля, поскольку краткий обзор разрабатывает (например, "непреобразованный отменявший текст" или "преобразованный выбранный текст"), и отображает их внутренне на зависимые от платформы конкретные стили (например, серое подчеркивание с 2 пикселями).
Выделитесь атрибуты представляются InputMethodHighlight class. Экземпляры этого class используются в качестве значений атрибута экземпляров AttributedCharacterIterator, представляющих составленный текст. Текстовые компоненты должны сохранить эти атрибуты составленным текстом и передать их на подпрограммы рисунка при рисовании составленного текста. Они могут использовать любого drawString методы, которые принимают AttributedCharacterIterator, или создайте a TextLayout от iterator и использования его метод ничьей. Эти методы рисунка взаимодействуют с входной платформой метода, чтобы отобразить краткий обзор на конкретные стили выделения. Текстовые компоненты, используя эти методы поэтому обычно не должны касаться внутренних деталей входных выделений метода. Если текстовый компонент использует некоторый другой механизм, чтобы представить текст, это должно проверить входное выделение метода на конкретную информацию о стиле, и, если ни один не обеспечивается, использовать Toolkit.mapInputMethodHighlight отображаться на конкретный стиль.
Некоторые входные методы могут обработать выделения как "аннотации". Аннотации являются атрибутами, которые применяются к указанному диапазону текста, но не к поддиапазонам или связи диапазонов. Они представляются, переносясь InputMethodHighlight экземпляр в Annotation экземпляр. Входные методы могут использовать выделения аннотации, чтобы разделить текстовые сегменты, которые будут преобразованы как отдельные модули. На некоторых платформах представляются эти выделения, чтобы сделать сегменты видимыми, например, при использовании подчеркиваний с короткими перерывами между сегментами. Текстовые компоненты должны быть в состоянии обработать входные выделения метода, обертываются ли они в Annotation экземпляры или нет. Если текстовый компонент реализует обертывание строки, специальная забота должна быть проявлена, когда диапазон, к которому аннотация выделения применяет кресты граница строки: нормальное поведение (реализованный, например, в AttributedString) должен был бы отбросить атрибут, потому что он не применяется к поддиапазонам. Но, с тех пор в этом случае есть только визуальное повреждение и не логическое повреждение, выделение должно быть сохранено - это должно быть обработано, как будто это применялось к поддиапазонам, которые представляются на отдельных строках. Один способ сделать это, реализовывая AttributedCharacterIterator в пути, который возвращает аннотации выделения даже для поддиапазонов намеченного диапазона.
Входной метод должен получить доступ к информации о компоненте, чтобы выполнить входные операции. Например, входной метод должен знать расположение, где список возможных вариантов можно показать.
Активный клиентский компонент поэтому должен реализовать InputMethodRequests интерфейс, и переопределение getInputMethodRequests возвратить обработчик запроса. Интерфейс включает методы в:
Входные методы обычно распознают некоторые пользовательские действия, которые заканчивают входные операции, например, работу, которая фиксирует весь незафиксированный текст. Однако, есть также пользовательские действия, которые запускают операции, для которых входные операции должны быть закончены, но что входной метод не может распознать. Сохранение документа, содержащего текст, является одним таким примером. В этих случаях компонент должен явно вызвать входной контекст endComposition метод.
В дополнение к входной информации о выделении метода входные методы могут также присоединить другие атрибуты к тексту, который они отправляют текстовому компоненту. Эти атрибуты могут быть полезной информацией для компонента. Они могут также улучшить входную производительность метода если возвращено InputMethodRequest методы. По последней причине рекомендуется, чтобы текстовые компоненты имели в наличии эту информацию атрибута, в то время как текст редактируется, и возвратите это с любым текстом, который требуют.
AttributedCharacterIterator.Attribute class определяет следующие общие атрибуты:
LANGUAGE - язык текста, определенного как a Locale объект.READING - фонетическое представление (yomi на японском языке), определенный как a String объект.INPUT_METHOD_SEGMENT - информация о сегментации используется входными методами.Входные методы, записанные в языке программирования Java, могут определить дополнительные атрибуты.
По умолчанию, один InputContext экземпляр создается на экземпляр Окна, и этот входной контекст совместно используется всеми компонентами в пределах иерархии включения окна. Это сокращает количество экземпляров, создаваемых в целом, и позволяет входным методам комбинировать информацию обо всем тексте, вводимом в это окно (входные методы часто используют информацию о ранее вводимом тексте, чтобы улучшить их точность преобразования). Это означает, однако, что только одна входная работа возможна в любой момент в пределах окна, и что текст должен фиксироваться, перемещая фокус от одного текстового компонента до другого. Если это не требуется, текстовые компоненты могут создать свои собственные входные экземпляры контекста и переопределение getInputContext возвратить их. Компонент, у которого нет его собственного входного контекста, использует тот, используемый его родителем.
Текстовые компоненты могут использовать входной контекст selectInputMethod работа, чтобы выбрать входной метод для данного языка или локали. Это может быть полезно, например, если пользователь щелкает в тексте, который пишется на том языке, так как вероятно, что она хочет продолжать на том же самом языке. Или, текстовый компонент может знать, что приложение только позволяет тексту на определенном языке вводиться.
Текстовые компоненты могут использовать входной контекст setCharacterSubsets работа, чтобы сказать входные методы, какие символы могут быть обоснованно введены. Например, приложение базы данных может знать, что определенные поля должны только получить ввод в hiragana (один из силлабических нижних индексов, используемых на японском языке), другой только латинские символы, третий любой вид символов. Передача этой информации, чтобы ввести методы может позволить входным методам ограничивать диапазон символов, которые могут быть введены, или переключаться на различный режим ввода, который особенно поддерживает указанные символьные подмножества.
Некоторые входные методы могут обеспечить функциональность для клиентских компонентов, которые не могут быть сделаны доступными через входной API платформы метода. Это возможно через входные объекты управления метода. Входной разработчик метода должен опубликовать интерфейс для этих объектов. Клиентские компоненты, которые хотят использовать в своих интересах дополнительную функциональность, могут тогда вызвать InputContext.getInputMethodControlObject, проверьте, является ли возвращенный объект экземпляром известного объекта управления class, и если это, вызовите его методы.
По умолчанию все компоненты, которые обрабатывают ключевые события, являются клиентами входной платформы метода, то есть, входная поддержка метода включается для них. В некоторых случаях компоненты, возможно, не хотят обрабатывать свой ввод входными методами. Например, игры могут хотеть интерпретировать события клавиатуры непосредственно. Эти компоненты должны вызвать enableInputMethods(false), так, чтобы события не стали переданными, чтобы ввести методы.
Этот пример кода показывает, как реализовать различные виды входных клиентов метода, которые возможны с входной платформой метода: активный клиент, пассивный клиент, неклиент, и текстовый компонент, с которым взаимодействуют.
