Обработка ввода


Содержание

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

1. Как переопределять работу поля ввода в части ввода по строке

Для переопределения работы поля ввода в части ввода по строке можно обрабатывать события поля ввода «АвтоПодборТекста» и «ОкончаниеВводаТекста».

1.1. Событие АвтоПодборТекста

Событие «АвтоПодборТекста» возникает во время начала ожидания ввода текста (когда в процессе набора текста сделана пауза). При стандартной отработке события происходит поиск по полям, указанным в свойстве «Ввод по строке» соответствующего объекта метаданных. Если найдено единственное значение, то производится автоподстановка окончания текста. Если введенному тексту соответствует несколько значений, то автоподстановки не происходит.

В этом примере при вводе в поле ввода буквы «п» и прерывании редактирования в поле ввода появился слово «пункт», при этом выделена будет его часть «ункт» (начало слова было уже введено и выделение на него не делается):

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

1.2. Событие ОкончаниеВводаТекста

Событие «ОкончаниеВводаТекста» вызывается системой в тех случаях, когда по введенному (отредактированному) в поле ввода тексту нужно сформировать значение, соответствующее этому тексту. При этом, если по имеющемуся в поле ввода тексту уже было ранее успешно сформировано значение, нового формирования значения по этому тексту выполняться не будет (т.е. не будет возникать событие «ОкончаниеВводаТекста»).

Необходимость формирования значения по тексту в поле ввода возникает в различных ситуациях, например при переходе из поля ввода к другому элементу управления, нажатии в поле ввода кнопки выбора (клавиша F4) и в ряде других ситуаций.

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

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

— введем в поле ввода слово «одежда»:

— нажмем на клавишу Tab для перехода к следующему элементу управления: при этом появится выпадающий список из двух значений:

— выберем в выпадающем списке первое значение с помощью клавиши «Enter». выбранное значение будет установлено в поле ввода, а мы перейдем к следующему элементу управления:

2. Использование результатов поиска по строке

При поиске значения по тексту могут быть следующие результаты поиска:
· не найдено ни одного значения;
· найдено одно значение;
· найдено больше одного, но не более некоторого количества значений (в системе используется константа — 50 значений);
· найдено некоторое количество значений или больше (т.е. > 50).

В каждом из этих случаев стандартные (системные) обработчики событий «АвтоПодборТекста» и «ОкончаниеВводаТекста» ведут себя определенным образом.

2.1. Работа стандартного (системного) обработчика события АвтоПодборТекста с результатами поиска по строке

1. По имеющемуся в поле ввода тексту ищется одно подходящее значение

2. Значение найдено?

2.1. Получается текстовое представление найденного значения

2.2. В поле ввода дописываются недостающие завершающие символы текстового представления найденного значения.

Пример : пусть поле ввода имеет тип «СправочникСсылка.Номенклатура»; в свойстве «Ввод по строке» указаны поля «Код», «Наименование»; в справочнике есть два элемента с наименованиями «Рубашка», «Брюки»:

Если мы введем воле ввода текст «Ру», он будет дополнен текстом «башка»:

2.2. Устройство механизма преобразования текста в поле ввода в значение и обработчик события ОкончаниеВводаТекста

Рассмотрим процесс формирования значения по тексту, введенному в поле ввода. Ниже приводится алгоритм преобразования текста в поле ввода в значение:

  1. Начало процесса формирования значения по тексту поля ввода.
  2. Получение текста из поля ввода.
  3. Вызов обработчика события «ОкончаниеВводаТекста».
    В параметры вызываемой процедуры записывается:
    Текст — текст из поля ввода;
    Значение — Неопределено. В обработчике события в него можно записать значение или список значений;
    СтандартнаяОбработка = Истина.
  4. В обработчике события разрешили выполнение стандартной обработки?
  5. Через параметр «Значение» вернули список значений?
  6. Кнопка выбора (клавиша F4) нажата ?
  7. В переданном списке количество значений больше одного?
  8. Открытие выпадающего списка в поле ввода и выбор значения из списка. Если в выпадающем списке выбрано значение, оно выставляется в качестве значения в поле ввода, а в качестве текста в поле ввода устанавливается текстовое представление выбранного значения. Если же значение в выпадающем списке не выбрано, состояние поля ввода не меняется.
  9. В переданном списке храниться только одно значение?
  10. В качестве значения в поле ввода устанавливается единственное значение из переданного списка. В качестве текста в поле вода устанавливается текстовое представление устанавливаемого значения.
  11. В параметре «Значение» вернули не список значений, а конкретное значение?
  12. Установка в поле ввода значения по умолчанию того типа, который сейчас выставлен в поле ввода.
  13. В качестве значения в поле ввода устанавливается значение параметра «Значение», а в качестве текста — представление устанавливаемого значения.
  14. Вызов стандартного (системного) обработчика события «ОкончаниеВводаТекста».
  15. Конец процесса формирования значения по тексту поля ввода.

Из описанного алгоритма видно, что смысл подмены стандартного (системного) обработчика может состоять в том, чтобы сформировать свой список значений из одного и более элементов или одно конкретное значение для поля ввода в зависимости от того текста, который есть в поле ввода.

2.3. Работа стандартного (системного) обработчика события ОкончаниеВводаТекста с результатами поиска по строке

Стандартный (системный) обработчик события «ОкончаниеВводаТекста» работает следующим образом:

  1. Начало работы стандартного обработчика.
  2. Получение текста из поля ввода.
  3. Текст в поле ввода не пустой?
  4. Формирование списка значений на основе текста из поля ввода. Например — поиск товаров, у которых наименование товара начинается с имеющегося в поле ввода текста.
  5. В сформированном в пункте 4 списке значений есть элементы?
  6. Кнопка выбора (клавиша F4) нажата? Это условие проверяется, потому что если она нажата, то будет открываться форма выбора и выпадающих списков появляться не должно.
  7. В сформированном в пункте 4 списке значений есть только одно значение?
  8. Устанавливаем единственное значение из списка в поле ввода. В качестве текста в поле ввода устанавливается представление этого значения.
  9. В сформированном в пункте 4 списке значений более 50 элементов?
  10. Открывается выпадающий список у поля ввода. В качестве списка значений для него используется список, сформированный в пункте 4. Пользователь может выбрать в этом списке одно из значений.
  11. Вывод пользователю сообщения о том, что найдено слишком много значений.
  12. Установка в поле ввода значения по умолчанию того типа, который сейчас выставлен в поле ввода.
  13. Конец работы стандартного обработчика.

3. Настройка состава и порядка полей, используемых в стандартных (системных) обработчиках событий АвтоПодборТекста и ОкончаниеВводаТекста

Для определения состава полей, используемых стандартными (системными) обработчиками событий » АвтоПодборТекста» и «ОкончаниеВводаТекста» , и их порядка, ряд объектов метаданных поддерживают свойство «Ввод по строке», доступное для редактирования через палитру свойств и в форме редактирования объекта метаданных. К таким объектам метаданных относятся «Справочники», «Документы», «Планы видов характеристик», «Планы счетов», «Планы видов расчета», «Планы обмена», «Бизнес-процессы», «Задачи».

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

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

В качестве значения по умолчанию для свойства «Ввод по строке» в 1С:Предприятии 8 используются следующие поля:

План счетов Наименование, Код План обмена Наименование, Код План видов характеристик Наименование, Код Документ Номер документа Справочник Наименование, Код Бизнес-процесс Номер Задача Номер, Наименование План видов расчета Наименование, Код

Отметим, что поле используется для поиска по строке только в том случае, если длина поля больше нуля. Так, например, если длина наименования в некотором справочнике равна нулю, то поиск по полю «Наименование» выполняться не будет.

Пример . Есть справочник товаров , описываемых кодом (число), наименованием (строка) и артикулом (строка).

Если принято использование артикулов товаров, можно указать в свойстве «Ввод по строке» поля «Артикул», «Наименование», «Код». При этом в выпадающем списке сначала будут идти товары, у которых в поле «Артикул» хранится хранится текст, начинающийся с введенного текста, затем — товары, у которых в поле «Наименование» хранится текст, начинающийся с введенного текста, затем — товары, у которых в поле «Код» хранится введенное значение (текст из поля ввода интерпретируется как число).

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

4. Модальные действия в обработчиках событий АвтоПодборТекста и ОкончаниеВводаТекста

Механизм автоподбора текста в поле ввода и преобразования текста в значение не предусматривает возможности использования разработчиком конфигурации интерактивных действий в обработчиках событий. Кроме того, логика работы стандартных (системных) обработчиков событий достаточно сложная и в обработчиках этих событий не всегда можно узнать, по какому поводу он (обработчик) вызван. Например, обработчик события » ОкончаниеВводаТекста» будет вызываться не только при переходе из поля ввода на другой элемент управления формы, но и при нажатии в поле ввода кнопки выбора (клавиша F4).

Рекомендуется в обработчиках событий » АвтоПодборТекста» и » ОкончаниеВводаТекста» работать исключительно с параметрами обработчиков, формируя нужный текст и значения и отдавая их через параметры обработчиков.

5. Управление механизмом автопоиска и автоподбора с помощью прав

Управлять механизмом автопоиска и автоподбора можно на уровне прав пользователей. Для этого в списке прав для различных объектов метаданных существует право «Ввод по строке».

Если у пользователя нет права на ввод по строке для соответствующего объекта метаданных , в поле ввода запрещается редактирование текста и работа механизма автопоиска и автоподбора блокируется.

6. Работа механизма автопоиска и автоподбора с правами на уровне записей

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

Если же есть необходимость поиска подходящих данных в обработчиках событий автопоиска и автоподбора, в запросе нужно использовать служебное слово «РАЗРЕШЕННЫЕ», указывающее, что при встрече данных, доступ к которым ограничен, нужно их просто пропускать: в противном случае будет выдана ошибка времени исполнения.

Основные методы ввода-вывода (I/O)

Начинающему разработчику зачастую сложно разобраться в средствах ввода-вывода (I/O), поскольку присутствует небольшая путаница в определении различий этих способов. В данном материале попробуем заполнить этот пробел и разобраться в классификации основных типов ввода-вывода.

I/O в аппаратном обеспечении

В современных операционных системах средства ввода-вывода представляют собой способы взаимодействия между обработчиком информации и внешним миром. Сюда можно отнести чтение или запись файлов на жёсткий диск или SSD, отправку и получение данных по сети, отображение информации на мониторе и получение ввода с мыши и клавиатуры.

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

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

4 октября 2020 – 1 марта 2020, Москва и онлайн, беcплатно

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

I/O в программном обеспечении

В среде программного обеспечения существует большое количество видов ввода и вывода: блокирующий, неблокирующий, мультиплексированный и асинхронный. Давайте рассмотрим их по очереди.

Блокирующий метод

Помните, что любая пользовательская программа запускается внутри процесса, а код выполняется в контексте потока? Предположим, вы пишете программу, которой нужно читать информацию из файла. С блокирующим вводом-выводом вы просите ОС «усыпить» ваш поток и «разбудить» его только после того, как данные из файла будут доступны для чтения.

То есть блокирующий ввод-вывод называется так, потому что поток, который его использует, блокируется и переходит в режим ожидания, пока ввод-вывод не будет завершён.

Неблокирующий метод

Проблема метода блокировки заключается в том, что поток будет спать, пока ввод-вывод не завершится. Поток не сможет выполнять никаких других задач, кроме ожидания завершения ввода-вывода. Иногда вашей программе больше и не надо ничего делать. В противном случае во время ожидания ввода-вывода было бы полезно выполнять другие задачи.

Один из способов осуществить это — использовать неблокирующий ввод-вывод. Его идея заключается в том, что когда программа делает вызов на чтение файла, ОС не будет блокировать поток, а просто вернёт ей либо готовые данные, либо информацию о том, что ввод-вывод ещё не закончен. Это не заблокирует поток, но программе придётся позже проверять, завершён ли ввод-вывод. Это означает, что ПО может по-разному реагировать в зависимости от того, завершён ли ввод-вывод и выполнять другие задачи. Когда же программе снова понадобится ввод-вывод, она сможет повторно попробовать прочесть содержимое файла, и если ввод-вывод завершён, то получит содержимое файла. В противном случае ПО снова получит сообщение о том, что операция ещё не завершена и сможет заняться другими задачами.

Мультеплексированный метод

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

Хорошо, если ПО просит ОС прочитать содержимое из файла А, после чего выполняет какие-нибудь сложные вычисления. Затем проверяет, завершилось ли чтение файла А, и если да, то просто продолжает ту работу, для которой нужно было содержимое файла, а иначе снова выполняет некоторое количество сложных вычислений и так далее.

Но что, если программе не нужно выполнять сложные вычисления? Ей просто нужно прочесть файл A и одновременно файл B. Пока ПО ожидает завершения обработки файла А, оно делает неблокирующий вызов чтения содержимого файла В. Во время ожидания обработки программе больше нечего делать, потому она входит в бесконечный цикл опроса, проверяя, готово ли A и готово ли B, снова и снова. Это либо нагрузит процессор проверками состояния ваших неблокирующих вызовов, либо вам придётся вручную добавить какое-то произвольное время, которое ваш поток будет «спать», а значит, программа немного позже заметит, что ввод-вывод готов, что отрицательно скажется на пропускной способности ПО.

Во избежание этого можно использовать мультиплексированный ввод-вывод. Он тоже блокирует поток на операциях ввода-вывода, но вместо того, чтобы производить блокировку по очереди, вы можете запланировать все операции ввода-вывода, которые вам нужно сделать, и блокировать их все. Операционная система разбудит поток, когда какая-нибудь из операций завершится. В некоторых реализациях мультиплексированного ввода-вывода можно даже точно указать, что вы хотите, чтобы поток разбудили, только когда заданный набор операций ввода-вывода будет завершён, например, когда файлы A и C, или файлы B и D будут готовы.

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

Асинхронный метод

Проблема мультиплексированного ввода-вывода в том, что поток всё-таки спит, пока ввод-вывод не будет готов для обработки. Для многих программ это подходит, поскольку у них нет других задач, пока они ждут завершения операций ввода-вывода. Но иногда у них есть и другие задачи.

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

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

Многопоточность или однопоточность?

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

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

В самом деле, есть пятый популярный метод ввода-вывода, который требует многопоточности. Его часто путают с неблокирующим или асинхронным, поскольку он похож по интерфейсу на те два. Он работает просто: он использует блокирующий ввод-вывод, но каждый блокирующий вызов делается в отдельном потоке. В зависимости от реализации, вызов либо принимает функцию обратного вызова, либо использует модель опроса, как если он возвращает Future .

Какая процедура срабатывает при вводе на основании?

Лефмихалыч Лефмихалыч

легко можно заменить на

Лефмихалыч Ненавижу 1С Лефмихалыч Лефмихалыч

Лефмихалыч

(26) подписка на событие ПередЗаписью(), ПриЗаписи()
в дополнительныесвойства пишешь идентификатор списка, формы или просто «Рюшечка1».

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

Все отстльные варинаты от лукавого

просто нужно четко понять, что «пометка» — это модификация, а «удаление» — это стирание записи из базы данных.

обработчики модфикации ПередЗаписью() ПриЗаписи(), обработчики удаления ПриУдалении().

Более того, в теле обработчика ПередЗаписью можно прописать дополнительноесвойство объекта, которое можно анализировать, когда запись(модификация) уже произошла, т.е. в ПриЗаписи().

Но и там и там можно блокировать завершение транзакций по каким-то своим соображениям.

Проектирование процесса автоматизированного ввода бумажных документов

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

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

· определение состава операций, которая должна выполнять система;

· выбор технических средств реализации выполнения этих операций;

· выбор и настройка программного обеспечения;

· разработка технологической документации.

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

1) подготовка документов к сканированию;

2) получение изображения документа;

3) распознавание и ввод данных, содержащихся в документе в ИБ.

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

Подготовка документов для сканирования предполагает выполнение следующих шагов:

· определение самого документа для сканирования;

· выбор конкретных областей документа для сканирования;

· определение технологической цепочки движения документа до сканирования;

· непосредственная подготовка документов для сканирования: открытие конвертов, удаление скрепок или других предметов, мешающих сканированию;

· подготовка пакетов документов для сканирования.

Составление описания каждого документа предполагает выполнение трех операций:

· составления настройки формы документа;

· настройки модели ввода;

· настройки полей формы документа и индексации базы данных.

В основе выполнения этого состава операций лежит понятие форматированного (структурированного) документа (ФД). Типичными примерами форматируемых документов являются «Платежные поручения», «Прайс-листы», «Декларации о доходах», «Счета» и т.д. Основной структурной единицей форматируемого документа является поле документа. Каждое поле описывается в двух аспектах: визуально, в частности геометрически, и содержательно. С изобразительной точки зрения каждое поле должно быть явно обособлено: пустыми промежутками, разделительными линиями, оригинальным типом шрифта, уровнем фона, цветом и т.д.

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

Геометрические и содержательные характеристики полей могут быть как абсолютно независимыми, так и взаимосвязанными. Например, в приходном ордере рядом с полями «количество» и «цена» находится поле «сумма».

Документы, которые подлежат сканированию, могут быть объединены в группы по нескольким признакам. По способу нанесения информации можно выделить документы, в которых используются метки, печатный или рукописный текст. Так, например, Избирательные бюллетени используют меточный способ, в то время как Прайс-листы — печатный, а первичные бухгалтерские документы — в основном рукописные.

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

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

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

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

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

· персональные — низкоскоростные (20-40 строк/мин, например Fujitsu Scan Partner 10, HP ScanJet и др.);

· настольные офисные — среднескоростные (40-60 строк/мин или 80-120 изображений в минуту, например ВапсТес 2610 Bell&Howell6338, Fujitsu3099, Kodak ImageLink 500 и др.);

· высокопроизводительные потоковые (90-185 страниц/мин или 180-370 изображений в минуту, например ВапсТес S-series, Photomatrix 5000, Kodak ImageLink 900 и др.).

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

· с низкой разрешающей способностью (200-400 точек на дюйм);

· со средней разрешающей способностью (600-800 точек/ дюйм);

· с высокой разрешающей способностью (1600-2800 точек/ дюйм);

Для ввода ветхих документов применяют сканеры специального назначения с вакуумным прижимом документов, которые предъявляют весьма низкие требования к документу и обрабатывают его в щадящем режиме. Такие сканеры позволяют сканировать не полностью раскрытые книги и документы плохого качества. Скорость ввода у таких устройств 0,25-3 страницы в минуту.

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

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

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

· предварительной обработки изображений;

· нахождения полей (сегментация документа и чтение текста);

· проверки распознанной информации;

· ввода данных в информационную базу.

Предварительная обработка изображения документов использует следующие специальные функции:

· очищение изображения применяется для снятия с изображений отдельных элементов (например, точки, пятна);

· снятие фона и выделений (например, с ценных бумаг);

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

· снятие элементов форм (для того чтобы эффективно обрабатывать форму, необходимо удалять с изображения элементы формы: линии, разграфки, таблицы и т.д.);

· определение идентификатора форм (так как приходится вводить в систему самые разнообразные формы, отличные как по содержанию, так и по структуре; для того чтобы система могла работать со множеством форм, она должна определять, какая форма поступила на обработку, и загружать соответственно заранее настроенное и подготовленное описание формы);

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

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

· вращение изображения на произвольный угол;

· регулирование уровня серого цвета;

· компрессия и декомпрессия изображения.

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

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

Наиболее сложная ситуация возникает при работе с гибкими формами документов. Термин «гибкая» означает, что известны состав полей, их примерное расположение, некоторые особенности по строению полей, но отсутствует полная и точная ориентация по их расположению.

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

Распознавание документа, анализ содержания документа и извлечение данных осуществляются в настоящее время с помощью следующих систем распознавания текстов, отличающихся по стоимости, качеству и скорости работы:

· OCR (Optical Character Recognition) — технология оптического распознавания печатных символов, т.е. перевода сканированного изображения печатных символов в их текстовое представление;

· ICR (Intelligent Character Recognition) — распознавание раздельных печатных символов, написанных от руки;

· OMR (Optical Mark Recognition) — распознавание отметок (обычно перечеркнутые крест-накрест либо галочками квадраты или круги);

· стилизованные цифры — распознавание рукописных цифр, написанных от руки по шаблону, как на почтовых конвертах.

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

· Распознавание on-line осуществляется в тот момент, когда человек пишет специальным пером на сенсорном экране, воспринимающем дополнительную информацию о траектории движения руки, наклоне пера, силе нажима и т.д. Применяется в основном в персональных электронных записных книжках типа 3Com PalmPilot для рукописного ввода числовых и символьных данных.

· Распознавание off-line — распознавание произвольного рукописного текста, введенного в компьютер через сканер.

Распознавание рукописных символов является подмножеством технологии распознавания off-line. Применяется, как правило, для ввода стандартных форм. Очевидно, что распознавание рукописного текста значительно сложнее, чем печатного. Если в последнем случае мы имеем дело с ограниченным числом вариаций изображений шрифтов (шаблонов), то в рукописном варианте число шаблонов неизмеримо больше.

Для OCR-систем в основном используются три технологии:

· описательная (основана на описании правил построения символов);

· нейронная (основана на использовании нейронных сетей).

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

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

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

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

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

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

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

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

· тип обрабатываемых документов и вид содержащихся в них данных;


· наличие эффективной системы редактирования;

· настраиваемость системы на требования конкретного заказчика и способность изменяться согласно меняющимся внешним условиям без программирования;

· наличие поддержки сканеров различных типов, а также разного рода плат обработки изображений документов;

· наличие редактора форм, настраивающего систему на новые формы или изменения старой формы, на которую система была предварительно ориентирована;

· наличие редактора схем обработки документов, открытого интерфейса подключения различных модулей распознавания (в зависимости от типа формы можно для повышения качества распознавания подключать тот или иной модуль, который наиболее подходит для данного типа формы);

· наличие редактора схем экспорта в базу данных (данные, которые извлекаются при обработке формы, должны быть переданы в базу данных для хранения или в другие бизнес-приложения для обработки).

Рассмотрим в качестве примера систему Cognitive Forms компании Cognitive Technologies. Cognitive Forms — российская сис­тема промышленного (иногда говорят поточного) ввода стандартных форм документов, которая работает под управлением операционных систем Windows 95/NT и MacOS. Система принадлежит к классу OCR/ICR/OMR и позволяет вводить в базы данных и информационные системы формы с печатным, рукописным заполнением и отметками (checkbox).

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

Эта система позволяет осуществлять распределенную поточную обработку (сканирование, распознавание, редактирование и контроль) в сети с производительностью распознавания до 14 000 страниц формата А4 в смену на одном компьютере и осуществлением автоматического контроля результатов распознавания. Экспорт данных может осуществляться в базы данных, банковские системы типа операционный день и системы создания электронных архивов и автоматизации документооборота.

Внедрение системы позволяет обеспечить ускорение ввода стандартных форм документов в 5-10 раз по сравнению с ручным вводом.

Сканированные образы могут быть сохранены в электронном архиве банка для ведения истории делопроизводства организации.

Cognitive Forms состоит из трех основных модулей:

· Cognitive FormDesigner отвечает за проектирование описания формы документа для программ распознавания и редактирования.

· Cognitive FormReader обеспечивает автоматическое распознавание потока стандартных форм, поступающих со сканера. В автоматическом режиме осуществляет поточное распознавание форм по заданному описанию и контекстную проверку результатов.

· Cognitive FormEditor предназначен для операторского контроля распознанных форм и сохранения информации из введенных форм в записи базы данных и позволяет оператору визуально контролировать и редактировать распознанные поля форм.

Cognitive Forms дает возможность осуществлять распределенную в рамках локальной сети, обработку вводимых форм и добиться эффективного доступа к данным в режиме реального времени. Например, на Pentium II-233 время распознавания системой Cognitive Forms одного бланка составляет около 2 с. Для промышленного ввода применяются высокопроизводительные сканеры: Kodak, Bell+Howell, BancTec, Fujitsu и другие, а также сетевые устройства (Hewlett-Packard). Производительность некоторых моделей достигает сотен страниц в минуту.

Технология использования системы сводится к выполнению четырех шагов.

1. Вначале сотрудники Cognitive Technologies или заказчик собственными силами создают описание формы (файл с расширением *.frm) или нескольких форм документов в программе Cognitive FormDesigner.

2. Посредством любого сканера бумажные экземпляры вводятся в компьютер и сохраняются в виде графических изображений (*.tif).

3. Для распознавания стандартных форм, удовлетворяющих требованиям Cognitive Technologies к оформлению, используется программа Cognitive FormReader.

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

Система Cognitive Forms была разработана для применения в банковской сфере для печати и ввода новых форм платежных поручений.

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

Вопросы для самопроверки

1. Каково содержание основных операций технологического процесса получения первичной информации?

2. Каковы методы и средства выполнения операции съема первичной информации и ее контроля?

3. Каковы методы и средства выполнения операций регистрации и сбора первичной информации и контроля правильно­сти их выполнения?

4. Каковы методы, технические и программные средства обеспечения передачи первичной информации в ЭИС?

5. Какой перечень операций входит в состав технологической сети проектирования процессов получения и передачи пер­вичной информации?

6. Каков состав процедур ведения ИБ?

7. Каковы требования, предъявляемые к процедуре загрузки?

8. Каков состав основных операций, включаемых в процедуру загрузки?

9. Каково содержание операции Прием, контроль и регистрация первичной информации и от какого фактора оно зависит?

10. Перечислите методы ввода первичной информации в компьютер и методы контроля вводимой информации.

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

12. Какой состав методов семантического и синтаксического контроля первичной информации, используемых при загрузке данных?

13. Каков состав операций проектирования процедуры загрузки данных в ИБ?

14. Какие средства частичной автоматизации проектирования процедуры загрузки вы знаете и какие факторы влияют на их выбор?

15. В чем особенность и каков состав операций, выполняемых при вводе информации с бумажных носителей?

16. Каков состав операций по проектированию системы ввода информации с бумажных документов?

17. Что такое форматированный документ и каковы способы его описания?

18. Что такое сканирование и факторы, влияющие на выбор сканерных устройств?

19. Что такое распознавание текста и каковы методы, приме­няемые для распознавания текстовой информации?

20. Перечислите методы контроля, используемые для проверки распознанного текста.

21. Каков состав требований, предъявляемых к системе ввода бумажных документов?

22. Каковы особенности структуры и технологии использования системы Cognitive Forms?

23. Каково содержание процедуры актуализации и каков состав операций проектирования процедуры актуализации ИБ?

24. Каков состав операций проектирования процесса обеспечения надежности хранения данных в ИБ?

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Студент — человек, постоянно откладывающий неизбежность. 10527 — | 7315 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Обработка ввода

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

Действия, которые управляют игрой

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

Распространённой практикой является отведение части экрана под виртуальный геймпад как часть интерфейса. Такое решение использует большую часть экрана, и в отличие от своих реальных аналогов (игровых контроллеров) обеспечивают очень плохую тактильную обратную связь.

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

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

Но представьте себе хоть немного, что если бы популярный хит Angry Birds использовал показанную выше схему управления. Вы всё еще играете? Будет ли механика стрельбы из рогатки бедными птичками с помощью виртуального геймпада полезнее натягивания и отпускания резинки? Я твёрдо убеждён, что наглядное/органичное управление лучше всего. Мобильные устройства имеют огромный сенсорный экран, который может быть целиком использован для ввода. Вместо болтов традиционных схем управления в мобильном устройстве мы можем гораздо умнее использовать сенсорный экран.

Ниже мы видим скриншот игры Craigen, в которой бесконечный бегун должен прыгать через препятствия и бить монстров.

Экран Craigen, прыжок и уничтожение монстра

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

Объяснения по управлению Craigen

Автор просто разделил экран на две половины и касание одной стороны означает прыжок, а другой стороны — удар. Вам не нужно касаться определённой точки, это можно сделать в любом месте на одной или другой половине. Это приводит к приятному опыту и счастливым пользователям.

Соображения по сенсорному вводу

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

Палец/рука игрока будет двигаться по экрану и иногда скрывать часть экрана в поле зрения. Старайтесь, чтобы взаимодействия располагались ближе к границе экрана. Если что-то происходит в середине областей, то сделайте так, чтобы игрок мог коснуться и быстро убрать палец, дабы избежать слепых зон.

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

Ввод с клавиатуры

Ввод с клавиатуры довольно прост. Мы должны отметить одну вещь — при написании мобильной игры вы также должны рассмотреть поддержку стандартной клавиатуры. Одним из преимуществ является то, что это помогает при разработке и позволит вам развернуть игру на мобильных и настольных устройствах.

Ввод с геймпада

Геймпады для настольных компьютеров и мобильных устройств становятся всё более популярными у казуальных игроков. Множество контроллеров совместимо с мобильными устройствами; предлагая в своём приложении поддержку таких контроллеров вы получите больше игроков. Существует HTML5 Gamepad API, который вы можете использовать в собственных играх.

Главное что надо знать о геймпадах — это то, что иногда они сильно отличаются друг от друга расположением кнопок. Если вы поддерживаете геймпады, ты должны предложить экран, на котором игрок может изменить конфигурацию контроллера, вроде того, какую кнопку нажать для стрельбы или прыжка. Как анекдот позвольте рассказать вам, что у меня есть дешёвый китайский геймпад, неправильно спаянный (я верю, что произошла ошибка), и у него перевёрнуто направление осей. Я не могу использовать этот контроллер во всех тех играх, которые не позволяют мне поменять направление осей.

Управление нашей игрой

Для краткости мы собираемся реализовать только прикосновения и ввод с клавиатуры. Phaser поддерживает геймпады из коробки, но это выходит за рамки простой игры которую мы строим, потому что я не хочу делать экран настроек в данный момент. Если вы хотите узнать больше об этом API в Phaser, обратитесь к документации по геймпаду.

Что требуется Foxnoid для управления игрой? В сущности игрок управляет ракеткой, которая движется влево или вправо. Как в игре Craigen мы разделим экран на две половины и касание любой половины заставит ракетку двигаться в этом направлении. Также добавим поддержку ввода с клавиатуры с помощью клавиш со стрелками.

Обработка прикосновений

Как объяснялось в главе об игровом цикле мы должны получать данные от игрока на каждом цикле. Это значит, что мы собираемся создать дополнительную функцию в game.js и вызывать её из update() .

game.js: функция handleTouchInput()

Для обработки прикосновений мы используем шаблоны Phaser Input. Чтобы узнать о них больше, обратитесь к документации Phaser.Input.

По умолчанию Phaser поддерживает ввод двумя пальцами, прикосновение первого пальца привязано к this.input.pointer1 , если второй палец в это же время касается экрана, то он привязан к this.input.pointer2 . В нашем случае требуется единственное касание на одной или другой стороне экрана. Так что мы просто проверяем this.input.pointer1 .

Свойства this.input.pointer1.worldX дают нам координаты по оси X, где произошло касание. Так как наш игровой мир имеет ширину 320 пикселей, то легко выяснить, какой стороны коснулся игрок. В зависимости от стороны мы задаём скорость ракетки в том же направлении. Значение этой скорости находится в константе this.playerSpeed , указанной в функции this.initWorld() .

Система Arcade Physics, используемая в Phaser, вычисляет положение ракетки на основе её скорости. Вот в чём красота проверенных фреймворков — не приходится больше возиться с формулами из физики.

Ввод с клавиатуры

Код для клавиатуры очень похож на один из приведённых выше, в том смысле, что мы просто проверяем, какую стрелку на клавиатуре нажал игрок, а затем задаём скорость ракетки.

У Phaser есть удобный способ для настройки обработчика клавиатуры, включая стрелки. Мы можем использовать его вместо регистрации каждой клавиши для отслеживания. Можно воспользоваться и обычным слушателем событий HTML, но поскольку у нас есть Phaser, то применим собственные функции, потому что они красиво привязаны к остальному циклу через update() .

game.js: функция handleKeyboardInput()

Чтобы использовать этот код, мы должны кое-что добавить в функцию initWorld() . Следует сказать Phaser настроить менеджер клавиатуры для нашей работы со стрелками.

game.js: новая функция initWorld()


С этой строкой в конце initWorld() мы сможем проверить this.cursors в функции update() . Без этого изменения в initWorld() переменная this.cursors будет undefined . Чтобы узнать больше о вводе с клавиатуры посмотрите документацию по Phaser.Keyboard.

Функция update()

Вот как функция update() выглядит с новыми шаблонами ввода.

game.js: новая функция update()

Теперь в нашу игра можно играть!

Резюме

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

В следующей главе мы собираемся добавить в игру Foxnoid состояния победы и проигрыша.

alexdev_ru

alexdev

Александр Пермяков [ insider ]

Здравствуйте, дорогие читатели!

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

В работе над этой статьей, я использовал Microsoft Visual Studio 2008 Standard с установленным SP1.

Для наших экспериментов, возьмем очень простой код:

using namespace std;

int main()
<
int a, b;
// Вводим первое число
cout «Enter \»A\»: » ;
cin >> a;
cout «You have entered: «

// Вводим второе число
cout «Enter \»B\»: » ;
cin >> b;
cout «You have entered: «

// Do something with a and b

cout «Thanks a lot. Press any key for exit.» while (!_kbhit());
>

Код очень простой, но я все же поясню, что тут происходит.
Мы объявили две переменные типа Integer и назвали их «a» и « b », соответственно. Далее, мы два раза просим пользователя ввести число, после чего выводим его на экран. А последняя строчка нашей главной функции программы, просто ждет нажатия любой клавиши от пользователя.

Для начала, посмотрим как выглядит корректная работа программы.

А теперь, давайте посмотрим, что произойдет, если мы введем вместо первого числа, какой-нибудь символ.

Как вы видите, программа естественно сработала не правильно.

Проверка ввода

Итак, давайте сделаем проверку ввода. Для этого слегка изменим исходный код нашей программы.
Мы добавим следующий код, после строчки « cin >> a; » :

cout «Incorrect input.»

Таким образом, мы сразу же после ввода смотрим, была ли ошибка во время чтения из входного потока. И если это так, то выводим текст об ошибке и выходим из программы.

Казалось бы, что все, но нет. Давайте разберемся, почему:

1. Программа показывает нам число «-858993460», когда пользователь вводит текст

2 Что хранится во входном потоке.

3. Почему пользователю не предоставилась возможность ввести второе число и как это исправить.

Почему -858993460?

Ответ на этот вопрос прост. В Visual Studio, этим значением, инициализируются неинициализированные локальные переменные. Это если компилировать программу в Debug-режиме. А в Release сборке, числа будут случайными.

Как это происходит? Когда пользователь вводит текст, то естественно, строчка “ cin >> a ;” выполняется с ошибкой, потому, что ожидается число. Естественно, в переменную a ничего не записывается и происходит ее неявная инициализация.

Для того, чтобы в переменной, при не правильном вводе хранилось какое-то число(отличное от
-858993460), то можно либо в блоке, где мы проверяем входной поток на ошибки, добавить явную инициализацию ( “a = -1;” ), либо инициализировать переменную при объявлении. Таким образом в переменной уже будет храниться число и оно не измениться при некорректном вводе.

Что храниться во входном потоке?

Ну, а это самый просто вопрос. Что пользователь вводил, то и храниться.

Как заставить работать второй пользовательский ввод?

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

Обработка ввода

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

Подсистема Microsoft Win32 получает доступ к клавиатуре, используя поток необработанного ввода (Raw Input Thread, RIT), который является частью системного процесса csrss.exe. Операционная система при старте создает RIT и системную очередь аппаратного ввода (system hardware input queue, SHIQ).

RIT открывает объект «устройство» драйвера класса клавиатуры для эксклюзивного использования и с помощью функции ZwReadFile направляет ему запрос ввода-вывода (IRP) типа IRP_MJ_READ. Получив запрос, драйвер Kbdclass отмечает его как ожидающий завершения (pending), ставит в очередь и возвращает код возврата STATUS_PENDING. Потоку необработанного ввода приходится ждать завершения IRP, для чего используется вызов асинхронной процедуры (Asynchronous Procedure Call, APC).

Когда пользователь нажимает или отпускает одну из клавиш, системный контроллер клавиатуры вырабатывает аппаратное прерывание. Его обработчик вызывает специальную процедуру обработки прерывания IRQ 1 (interrupt service routine, ISR), зарегистрированную в системе драйвером i8042prt. Данная процедура считывает из внутренней очереди контроллера клавиатуры появившиеся данные. Обработка аппаратного прерывания должна быть максимально быстрой, поэтому ISR ставит в очередь вызов отложенной процедуры (Deferred Procedure Call, DPC) I8042KeyboardIsrDpc и завершает свою работу. Как только это станет возможно (IRQL понизится до DISPATCH_LEVEL), DPC будет вызвана системой. В этот момент будет вызвана процедура обратного вызова KeyboardClassServiceCallback, зарегистрированная драйвером Kbdclass у драйвера i8042prt. KeyboardClassServiceCallback извлечет из своей очереди ожидающий завершения запрос IRP, заполнит максимальное количество структур KEYBOARD_INPUT_DATA, несущих всю необходимую информацию о нажатиях/отпусканиях клавиш, и завершит IRP. Поток необработанного ввода пробуждается, обрабатывает полученную информацию и вновь посылает IRP типа IRP_MJ_READ драйверу класса, который опять ставится в очередь до следующего нажатия/отпускания клавиши. Таким образом, у стека клавиатуры всегда есть по крайней мере один ожидающий завершения IRP, и находится он в очереди драйвера Kbdclass.

Рисунок 4. Поток необработанного ввода

RIT обрабатывает поступившую информацию по следующему принципу(рис.4). Все пришедшие клавиатурные события помещаются в системную очередь аппаратного ввода, после чего они последовательно преобразуются в сообщения Windows (типа WM_KEY*, WM_?BUTTON* или WM_MOUSEMOVE) и ставятся в конец очереди виртуального ввода (virtualized input queue, VIQ) активного потока. В сообщениях Windows скан-коды клавиш заменяются на коды виртуальных клавиш, соответствующие не расположению клавиши на клавиатуре, а действию, которое выполняет эта клавиша. Механизм преобразования кодов зависит от активной раскладки клавиатуры, одновременных нажатий других клавиш (например, SHIFT) и других факторов.

Когда пользователь входит в систему, процесс Windows Explorer порождает поток, который создает панель задач и рабочий стол (WinSta0_RIT). Этот поток привязывается к RIT. Если пользователь запускает MS Word, то его поток, создавший окно, немедленно подключится к RIT. После этого поток, принадлежащий Explorer, отключается от RIT, так как единовременно с RIT может быть связан только один поток. При нажатии клавиши в SHIQ появится соответствующий элемент, что приведет к тому, что RIT пробудится, преобразует событие аппаратного ввода в сообщение от клавиатуры и поместит его в VIQ потока приложения MS Word.

Обработка сообщений конкретным окном

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

while(GetMessage(&msg, 0, 0, 0))

С помощью функции GetMessage события от клавиатуры извлекаются из очереди и перенаправляются с помощью функции DispatchMessage оконной процедуре, которая производит обработку сообщений для окна, где в данный момент сосредоточен фокус ввода. Фокус ввода — атрибут, который может присваиваться окну, созданному приложением или Windows. Если окно имеет фокус ввода, соответствующая функция этого окна получает все клавиатурные сообщения из системной очереди. Приложение может передавать фокус ввода от одного окна другому, например, при переключении на другое приложение с помощью комбинации Alt+Tab.

Перед функцией DispatchMessage обычно вызывается функция TranslateMessage, которая на основе сообщений WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP создает «символьные» сообщения WM_CHAR, WM_SYSCHAR, WM_DEADCHAR и WM_SYSDEADCHAR. Образованные символьные сообщения помещаются в очередь сообщений приложения, причем оригинальные клавиатурные сообщения из этой очереди не удаляются.

Обработка Ввод начальных остатков

Читайте также:

  1. Автоматизированная обработка выписок банка
  2. Ввод начальных остатков по другим счетам
  3. Ввод начальных остатков по ОС
  4. ВИДЫ НТИ И ЕЕ ОБРАБОТКА
  5. Вопрос 3 (10 мин.) Организация контроля за устранением недостатков, выявленных в ходе инспектирования
  6. Вопрос 3 Специальная обработка медицинского имущества
  7. Вопрос 4 (20 мин.) Организация контроля за устранением недостатков, выявленных в ходе инспектирования
  8. Вторичная ОБРАБОТКА ДАННЫХ
  9. Гигиеническая обработка рук
  10. Дискретизация сигналов. Преобразование аналоговых и цифровых сигналов. Обработка измерительной информации
  11. Итог остатков на конец месяца по дебету всех синтетических счетов равен итогу остатков по кредиту всех счетов.
  12. Камеральная обработка результатов горизонтальной и вертикальной съемок трассы

В 1С:Бухгалтерии есть специальная обработка (Предприятие > Ввод начальных остатков), которая предназначена для упрощения процесса ввода начальных остатков по счетам (рис. 4.43).

Рис. 4.43. Обработка Ввод начальных остатков

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

Выше мы заполняли документы самостоятельно, после установки даты ввода остатков (31.12.2008) система прочитала данные из документов и заполнила ими поля таблицы, рассчитав итоговые показатели (рис. 4.44).

Рис. 4.44. Обработка Ввод начальных остатков, информация по остаткам, введенным ранее

При необходимости обработкой Ввод начальных остатков можно воспользоваться после того, как остатки по некоторым счетам введены самостоятельно. Ей же можно пользоваться и тогда, когда ничего еще не введено — в таком случае она позволит вам пройти по тому же пути, который вы прошли самостоятельно выбирая и заполняя нужные документы.

| следующая лекция ==>
Проверка правильности ввода начальных остатков | Дата актуальности учета

Дата добавления: 2014-01-03 ; Просмотров: 584 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Форум

Справочник

Поиск по форуму
Расширенный поиск
К странице.
Страница 1 из 2 1 2 >
Нужно проверять именно DOMControlValueChange и его аналоги.

совсем не обязательно, можно еще по таймеру проверять содержимое value Сообщение от subzey Нужно проверять именно DOMControlValueChange и его аналоги.

И какие у него аналоги?!

  • DOMControlValueChanged — опера
  • input — XUL (гекконы)
  • propertychange (где property=»value») — ослик
  • DOMCharacterDataModified, DOMSubtreeModified — вебкит

Все это расписано в статье по ссылке выше.

Здравствуйте! Есть код:

Во всех браузерах прекрасно работает эта функция:

А вот такая функция не работает в FireFox3 (значение при вводе не меняется):

Где ошибка?? (Необходимо ограничить ввод иных символов кроме цифр на основной клаве и цифровой, Backspase и Delete)
Спасибо!

AVRASM: Библиотека процедур для интеллектуальной обработки ВВОДА в МК: событий от Кнопок и Энкодеров (часть 1: авторская методика и реализация)

Микроконтроллерное устройство может работать исключительно в автономном режиме: получать сигналы с датчиков, и выдавать управляющие импульсы, иногда оно ещё взаимодействует с ЭВМ или другими микроконтроллерами… Но большинству микроконтроллерных устройств требуется поддерживать интерфейс с пользователем-человеком: для вывода используются светодиоды или дисплеи, а для ввода — традиционные Кнопки и Энкодеры, редко используются и другие экзотические устройства ввода…
В данной работе будут рассматриваться только традиционные инструменты ввода: «цифровые Кнопки / Клавиатуры» и «инкрементальные Энкодеры», поскольку именно они используются почти всегда.

Назначение

Данная реализация «Библиотеки процедур для интеллектуальной обработки ВВОДА» написана на языке ассемблера, для компилятора AVRASM. Соответственно, она предназначена для разработки программных прошивок (firmware) на языке ассемблер, для микроконтроллеров Atmel AVR (8-bit).

Особенности

Среди прочего, библиотека реализует следующие функции:


1) Математическое подавление ошибок, от наведенных электрических помех и дребезга контактов, для всех «физических каналов» подключённых Кнопок и Энкодеров, с заданной и регулируемой величиной помехоустойчивости. (используется оригинальная авторская методика «интегрирующей защёлки»: на двунаправленном инкрементальном счётчике)

2) Сложные поведения реальных кнопок — сводятся к стандартизованным кодам в «Статусных Регистрах» Кнопок, на основании которых можно легко реализовывать очень сложную и гибкую логику поведения устройства:

  • распознаются разные жесты с кнопками: серии нажатий и удержаний кнопок;
  • различаются варианты кнопочных аккордов: одновременное нажатие/удерживание нескольких кнопок;
  • кнопки различается по времени удержания: обычное, «короткое» или «длинное» удержание. А для продвинутых случаев, для наиболее функциональных кнопок, также допустимо различать ситуации: «сколько КОНКРЕТНО удерживается кнопка, в пределах 0..16сек?» и программировать различные реакции.
  • и что особенно полезно для низкоуровневого ассемблерного кода: дана чёткая и прозрачная методика написания прикладного кода обработчиков «реакции на события» (предлагаются макросы для тестирования и обработки статус-кодов кнопок). Также, имеется простая возможность назначать одинаковые обработчики различным альтернативным кнопочным жестам.
  • Простой и понятный механизм «сброса статусных кодов» для уже обработанных кнопок — исключает «побочные эффекты»: типа «залипания» или «ошибочные повторные нажатия» кнопок… (защита от дурака: при правильно организованном коде обработчиков, пользователь может жать на всё подряд — приложение отреагирует чётко и правильно)

3) Для распознавания и обработки кодовой последовательности, поступающей от инкрементального Энкодера по двум физическим каналам — предлагаются три разные реализации кода, обладающие разными функциональными возможностями и подходящие для разных ситуаций (лёгкий и простой код, для хорошего и быстрого железа; или усложнённый код, с коррекцией ошибок, для медленного или сбойного железа).
Разработчик выбирает вариант кода обработки энкодера — только директивами условной компиляции. Вся активность энкодера обрабатывается библиотекой автоматически и сводит все особенности к простому «Счётчику тиков», который затем используется в прикладном коде обработки событий. (Формат счётчика особой специальной структуры не содержит — это просто знаковое целое число: Signed Int = [-128..127]).

4) КОД библиотеки УНИВЕРСАЛЕН и не требует (даже не рекомендует) каких-либо вмешательств и переделок под ваше конкретное устройство!
Единственная процедура, код которой требуется адаптировать к вашей конкретной физической схеме — это KEY_SCAN_INPUT (через неё осуществляется связь с физическими каналами ввода).
Также, под вашу конкретную физическую схему, требуется адаптировать блок определения данных в DSEG (см. в файле ): определения блоков регистров Интегратора, статусных регистров Кнопок и Энкодеров, и некоторые константы.

5) Данная библиотека испытана в реальном физическом устройстве — и зарекомендовала себя как «реально работоспособная», гибкая и эффективная! Пример использования данной библиотеки, реализация клиентского прикладного кода, приведен в файлах: и .

Код и Зависимости

Код библиотеки процедур для интеллектуальной обработки ВВОДА «celeronkeyinputlib.inc» опубликован на GitHub (это веб-сервис для хостинга IT-проектов и их совместной разработки), на условиях лицензии MIT (разрешительной opensource, т.е. практически без ограничений к использованию). Ответвляйтесь!

Используется, и требует подключения, нестандартная внешняя Библиотека базовых Макроопределений «macrobaselib.inc» — расширяющая стандартный набор ассемблерных инструкций микроконтроллеров Atmel AVR (8-bit AVR Instruction Set), и рекомендующая парадигму программирования: с хранением «модели прикладных данных» в ОЗУ и использованием нескольких «временных регистров»…

Примечание: GitHub был выбран для распространения кода — как наиболее прогрессивный, удобный и функциональный метод взаимодействия opensource-разработчиков. Развивайте и дополняйте библиотеку — затем, сможете легко контрибутить.

Ликбез для неискушённых пользователей: те кто не используют системы управления версиями, могут просто скачать архив с кодом: нажав на кнопку «Download ZIP» на странице репозитория GitHub, по ссылкам выше.

Как это работает?

1. Физический канал

Предположим, к вашему микроконтроллеру подключена ЛЮБАЯ кнопка. Это может быть одна или много кнопок. Схемотехнически, Кнопка может быть организована по разному:

Однако, какой бы ни была схема подключения и мультиплексирования кнопок, в результате сканирования физического канала Кнопки — получаем цифровой код её состояния (принятая в библиотеке кодировка: «0»-кнопка отпущена или «1»-нажата).
Замечу, что если сканируется клавиатура на резистивных делителях, то после преобразования через АЦП и «табличку соответствия напряжений кодам кнопок» — также получаем цифровые коды «нажатых» и «отпущенных» кнопок…

1.1. Код сканирования «физических каналов» программист пишет сам

Замечу: код сканирования «физических каналов» находится в процедуре KEY_SCAN_INPUT библиотеки. Эта процедура обеспечивает взаимодействие микроконтроллера с внешней аппаратной периферией ввода. При адаптации библиотеки к своему «железу», программист должен переписать код этой процедуры, с нуля! Таким образом, достигается универсальность и гибкость применения данной библиотеки, адаптивность к любым схемотехническим решениям подключений кнопок и энкодеров, без ограничений! Причём, это единственная процедура, в библиотеке, требующая вмешательства в код. Остальной код математического конвейера — универсален и неизменен, он подвязывается и запускается из этой процедуры KEY_SCAN_INPUT.

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

При обработке Энкодеров — отличия небольшие: нужно помнить, что канала два; и вызывается другой метод Обработки…

2. Интегратор канала

Интеграция «сырого» статуса входного канала (процедура математического подавления звона и помех KEY_PROCESS_INTEGRATOR) вызывается после опроса физической кнопки (любой реализации) и получения цифрового кода её текущего статуса: «0» или «1».

В процедуру KEY_PROCESS_INTEGRATOR передаются следующие параметры:

  • Через status bit «T» передаётся «сырой» цифровой код текущего состояния кнопки = «0» или «1».
  • Регистровым параметром «IntegratorAddress» передаётся адрес «регистра интегратора» в памяти (ОЗУ).
  • Регистровым параметром «IntegratorLatchDepth» специфицируется «глубина защёлки» для текущего канала. (Примечание: наличие этого параметра позволяет дифференцированно применять разную «глубину защёлки» для разных «физических каналов». Предполагается, что сигналы от тактовых кнопок и энкодера, например, требуют разных «глубин защёлки» — ввиду их различной динамичности и надёжности. )
2.1. Кодировка входного сигнала

Кодировка входного сигнала:

  • По принятому СТАНДАРТУ, статус входного «физического канала» приходит в следующей кодировке: «0»=(кнопка отпущена) или «1»=(кнопка нажата).
    Примечание: И только так! И не перенастраивается!
  • Рекомендация: А если ваша схемотехническая реализация кнопок возвращает другой, инверсный код? Тогда просто добавьте, в код процедуры KEY_SCAN_INPUT, безусловную математическую XOR-инверсию, после чтения кода из Порта.

Вопрос: А зачем так жёстко фиксировать СТАНДАРТ кодировки сигнала? Ведь достаточно изменить только одну инструкцию BRTS/BRTC, чтобы кодировка входного сигнала стала инверсной? Можно было бы настраивать директивой условной компиляции…
Ответ: Для минимизации путаницы — код конвейера обработки кнопок не модифицируется, логика неизменна! Также, допускается, что разные группы Кнопок и Энкодеров, могут возвращать свои статусы в разных кодировках, вперемешку… Гораздо проще, понятнее и универсальнее: добавить безусловные XOR-инверсии к некоторым конкретным «физическим каналам»… Простота -> Ясность -> Выгода!

2.2. Формат «Регистра Интегратора»

(Справка: Расположены в секции DInputIntegrator в файле )

В целом, регистр хранит одно число signed short int = [-128, 0, +127].
Результат интеграции — отражается в Sign bit (он же Negative Flag «N»), означает: «0»=(кнопка отпущена) или «1»=(кнопка нажата)…

Семантически — это инкрементальный двунаправленный счётчик:

  • Если физический канал (кнопка) возвращает статус «1» (нажата) — то на этой итерации производится декрементация (-1) регистра счётчика.
  • Если физический канал (кнопка) возвращает статус «0» (отпущена) — то на этой итерации производится инкрементация (+1) регистра счётчика.
  • Максимальное, по модулю, значение в регистре счётчика определяется константой «глубины защёлки» (LatchDepth) = [-LatchDepth, 0..+(LatchDepth-1)].
    Причём замечу: здесь, значение =0 включается в статус «кнопка отпущена»!
  • Начальное состояние = 0b00000000. Что означает: примерно среднее неопределённое положение защёлки, но кнопка всё же на стороне «отпущена» (что соответствует обычной ситуации: когда кнопки, конструктивно, «нормально разомкнутые»).

2.3. Настройка интегратора: выбор «глубины защёлки»

«Глубина Защёлки» интегратора, по своему действию, аналогична «постоянной времени» помехоподавляющей RC-цепи…

Допустимые значения для регистрового параметра IntegratorLatchDepth = [1..128].

Выбор оптимального значения «глубины защёлки» зависит от разных факторов:

  1. Следует учитывать, по какому событию запускается процедура сканирования «физических каналов» KEY_SCAN_INPUT: по таймеру, периодически или по «Pin change Interrupt (INT0)»?
    • Если по таймеру, периодически — тогда нужно брать IntegratorLatchDepth > больше количества «замеров», за период самой длинной помехи (это требуется замерять экспериментально).
    • Если по изменению уровня на порте ввода-вывода (INT0), то выбор проще: на «тактовую частоту» микроконтроллера можно не смотреть, а выбрать IntegratorLatchDepth=[2..3].
  2. «Глубину защёлки» следует устанавливать и в расчёте на будущий износ кнопок: для плохого железа и лучшей помехозащищённости — требуется бОльшая разрешительная «глубина». Лучше взять значение IntegratorLatchDepth чуть больше, чем отрабатывается на лабораторном стенде (на порядок больше, для худших случаев).
  3. Но следует помнить, что большАя «глубина защёлки» — сильно замедляет реакцию микроконтроллера на события: кнопки становятся значительно «инертнее», а кратковременные нажатия могут быть и вовсе пропущены, что сильно ухудшает эргономику! Также, на медленных микроконтроллерах или при редкой частоте сканирования «физических каналов» — «глубину защёлки» следует брать поменьше.
  4. При опросе контактных групп Энкодера — «глубина защёлки» интегратора, обычно, задаётся на порядок меньше, чем для кнопок! Поскольку контакты Энкодера более стабильны и помехоустойчивы, а кроме того, Энкодер переключается ГОРАЗДО чаще, чем тактовые Кнопки (требуется выше быстродействие).
  5. Замечу: при IntegratorLatchDepth=1 — интегратор, фактически, отключён! При этом, код Интегратора будет отрабатываться, как часть конвейера, и потреблять ресурсы АЛУ, но исправлять ошибки не будет.
  6. Напомню: максимальное значение IntegratorLatchDepth=128. Однако, если микроконтроллер работает слишком быстро, и процедура KEY_SCAN_INPUT запускается слишком часто — то вам, возможно, не хватит этого максимума, для демпфирования долгих помех. Тогда, очевидно, запуск процедуры KEY_SCAN_INPUT следует запланировать пореже.
3. Работа с Кнопками

Всё что происходит с кнопкой — отражается в её «статусном регистре». Этот регистр имеет сложную структуру и семантическое наполнение, кодирует множество ситуаций…

Статус-код кнопки формируют две процедуры: KEY_UPDATE_BUTTON_STATUS (определяет нажатие-отжатие кнопки) и KEY_ENHANCE_TIME_FOR_ALL_BUTTONS (наращивает счётчики «времени удержания» кнопок).

Прикладной код обрабатывает события, опираясь, исключительно, на значения в «статусных регистрах» кнопок. Условие для запуска обработчика может приниматься, анализируя статусы сразу нескольких Кнопок — так появляется возможность различать «аккорды» и кнопки-модификаторы. А наличие в статусном регистре кодов, различающих события: «нажатие», «отжатие», «время удержания», отдельно для каждой кнопки — позволяет довольно гибко и функционально комбинировать начальные условия для запуска обработчика события!

После обработки событий, связанных с кнопкой, прикладной код сбрасывает «регистр статуса», соответствующий кнопке. Имеется также глобальная процедура KEY_RESET_STATUS_FOR_ALL_BUTTONS, которая сбрасывает статусы ВСЕМ кнопкам и энкодерам в системе — вызывается прикладным кодом асинхронно, и используется для подавления «ошибочных реакций» из-за того, что «пользователи давят на всё подряд»…

3.1. Формат «регистра Статуса» Кнопки

(Справка: Расположены в секции DButtonStatus в файле )

Описание битов «регистра статуса» кнопки:

Три бита DButtonStatus[7:5], кодирующие итоговый «статус-код кнопки», могут принимать следующие значения:

Специальные значения:

  • «регистр статуса» = 0b00000000, означает начальное состояние: кнопка «не нажата и не нажималась», исходное положение для всех кнопок — бывает только после «сброса в ноль» или при включении микроконтроллера.
    (Здесь, статус-код кнопки = «не нажата»; счётчик времени предыдущего нажатия = обнулён.)
  • «регистр статуса» = 0b11111111, означает служебное исключительное состояние «ОТЛОЖЕННЫЙ СБРОС»: «фиксация, до ожидания следующего отпускания» кнопки
    (Здесь, якобы, кнопка «удерживается и отпущена одновременно» — это запрещённый «статус-код кнопки», что запрещает прикладному коду реакцию на эту кнопку.)
    (Замечу: При следующем отпускании физической кнопки, статус-регистр будет АВТОМАТИЧЕСКИ «сброшен в ноль» — в исходное положение! А если кнопка уже отпущена — то «сброс в ноль» будет осуществлён сразу же.)

Процедура KEY_UPDATE_BUTTON_STATUS — фиксирует статус кнопки в «статусном регистре», в зависимости от динамически изменяющегося [проинтегрированного] состояния «физического канала» (определяет нажатия-отжатия). В неё передаются следующие параметры:

  • Регистровым параметром «IntegratorAddress» передаётся адрес «регистра интегратора» (в памяти ОЗУ), который кодирует текущее «физическое» состояние кнопки.
  • Регистровым параметром «StatusAddress» передаётся адрес «статусного регистра кнопки» (в памяти ОЗУ), который следует обновить.
3.2. «Время удержания» Кнопки

Процедура KEY_ENHANCE_TIME_FOR_ALL_BUTTONS наращивает таймеры для удерживаемых кнопок (должна запускаться по событию таймера, точно раз в 0.5 сек).
Для Энкодеров не используется — предназначена только для обработки Кнопок! С физическими кнопками также не работает, а только перебирает/обрабатывает их Статусные регистры!

Алгоритм её работы таков:

  • Для кнопок удерживаемых в нажатом состоянии, наращивает «счётчик времени удержания» (если он ещё меньше своего максимума BSC_LongHold.

Процедура KEY_ENHANCE_TIME_FOR_ALL_BUTTONS не имеет регистровых параметров, но использует один константный параметр (захардкоден в прошивке), для настройки времени «длительно удерживаемых» кнопок:

3.3. Обработка статус-кодов Кнопок («жесты» и «аккорды»)

Советы по порядку тестирования Кнопок:

Совет: В большинстве случаев, обработчик события привязывается к значению BUTTON_STATUS_CODE в «статусном регистре» кнопки — это самый простой для кодирования и функциональный метод. Полагаю, для описания большинства распространённых «жестов» с кнопками — хватит 4 ситуации…
Для тестирования состояния кнопок по паттерну BUTTON_STATUS_CODE, рекомендуется использовать библиотечные макросы: IF_BUTTON_HAVE_STATUS, AND_BUTTON_HAVE_STATUS, OR_BUTTON_HAVE_STATUS (последние два используются в комбинации, для тестирования «кнопочных аккордов»). Пример, см. ниже.

Совет: кроме тестирования чистого «статус-кода кнопки», можно также смотреть на «счётчик времени удержания кнопки» — и различать также ситуации «очень длительных» удерживаний кнопок! Но замечу, что эти ситуации уже не кодируются в «статус-коде кнопки», т.к. довольно редки. Если требуется данный функционал — его следует самостоятельно реализовать в прикладном коде, на основании арифметического сравнения с абсолютным значением счётчика BUTTON_HOLDING_TIME (инструкцией CPI). Это самый функциональный способ! Пример, см. ниже.

Совет: чтобы разнообразить варианты ввода, прикладной код также может воспринимать «кнопочные аккорды» — тестировать группы кнопок на наличие одновременных нажатий/удержаний. Однако, делать это нужно в определённом порядке приоритетов:

  1. Сначала, проверить были ли нажатия отдельных кнопок, при удержании других «кнопок-модификаторов» (подобно: «Shift/Ctrl/Alt + X»)?
    Подсказка: У основной кнопки, которая «нажималась» — статус BUTTON_STATUS_CODE==«ShortPress/LongPress»; при этом, у модификаторов, при «удержании в нажатом состоянии» — установлен бит BUTTON_IS_HOLDDOWN==1.
  2. Затем, проверить простые одиночные нажатия отдельных кнопок: у которых статус==«ShortPress/LongPress»?
  3. Затем, проверить группы кнопок на одновременное удержание: у которых статус==«LongHold»? Причём, таким образом, можно проверить, последовательно, несколько групп: от более общих множеств, к более частным — с меньшим числом входящих кнопок.
  4. И наконец, проверить отдельные кнопки на длительное удержание: у которых статус==«LongHold»?

Совет: во избежание ложных повторных срабатываний событий, после обработки статуса кнопки прикладным кодом и произведения ответной реакции, «СБРОСьте» статусный регистр — это простой способ сообщить остальному прикладному коду, что данное событие уже обработано и не требует дальнейшего участия…

3.4. Сброс «регистра статуса» Кнопки (завершение обработки события)

Сделал дело — прибери за собой!

После отработки события — обработчик сбрасывает статусные регистры вовлечённых кнопок: обычно для всех кнопок, составляющих «аккорд». Сброс статусного регистра — фактически, обнуляет историю произведённого с кнопкой действия ДО обработки события. Теперь, кнопки готовы к новым отдельным действиям с ними.

В то же время, нужно помнить, что если прикладной код вовремя не обнулит «статусный регистр» отдельной кнопки — то она продолжит считаться «нажатой» (что особенно опасно) или «удерживаемой», что в будущем, может вызвать «побочную реакцию»!
Обычно, интерфейс устройства состоит из разных подсистем, и не во всех режимах используются [и обрабатываются] все кнопки интерфейса. Если, в некотором режиме интерфейса, часть кнопок не задействована — то они не опрашиваются, не срабатывают, их статус не обнуляется, а запоминается и хранится (такая кнопка становится «миной отложенного действия»). Следует также учитывать «защиту от дурака»: пользователь будет нажимать на всё подряд!
Поэтому, при реализации прикладной логики вашего Устройства: когда переключаете интерфейс в другую Подсистему — следует безусловно обнулять все статусные регистры, вызовом процедуры KEY_RESET_STATUS_FOR_ALL_BUTTONS (это «разминирует все заложенные ловушки»).

Это важный концептуальный момент: Обработчики событий программируются так, чтобы срабатывать по наступлению некоторого события в срезе времени. Обработчики не контролируют никаких состояний и данных ДО и ПОСЛЕ события — следовательно, их код проще и прозрачнее (аспектно-ориентированный). Но поэтому, так важно разделять события, во времени, на атомарные реакции… После отработки события, обработчик просто сбрасывает статусные регистры вовлечённых кнопок — таким образом, «подсистеме обработки ввода» указывается, что событие было обработано и данная кнопка готова к принятию нового, следующего ввода.

Есть два вида сброса:

  1. «Сброс статус-регистра В НУЛИ» (мгновенный) Такие кнопки не требуют явного отпускания кнопки, перед тем как они смогут повторно зафиксировать событие «нажатие». Здесь, возможен побочный эффект: если сбросить статус кнопки «в ноль» до того как физическая кнопка будет реально отпущена (т.е. пока она «удерживается»), то уже на следующей итерации, по состоянию «физического канала» = «1»(нажата) — будет опять зафиксирована новая ситуация «нажатие»…
    Этот способ не рекомендуется использовать НЕПОСРЕДСТВЕННО. Вместо этого: Для тактовых кнопок рассчитанных на одиночные «законченные нажатия (BSC_*Press)» — всегда используйте «сброс В ЕДИНИЦЫ» (отложенный, автоматический). А если требуются серийные реакции на событие «удерживание кнопки (BSC_*Hold)» — просто не сбрасывайте статус-регистр, пока кнопка удерживается.
  2. «Сброс статус-регистра В ЕДИНИЦЫ» (отложенный) Такие кнопки ждут «отдельных нажатий» (реальная кнопка должна быть отпущена и нажата заново) — это исключает «побочные эффекты», типа «залипания» или «ошибочные повторные нажатия» кнопок.

Для понимания ситуации, как это работает, рассмотрим несколько сценариев:

  1. После обработки статус-кодов BSC_*Press (замечу, что физическая кнопка уже отпущена), статус-регистр можно «сбросить в ноль (CLR)» -> так сразу установится исходное положение для всех кнопок «не нажата».
  2. После обработки статус-кодов BSC_*Hold (замечу, что физическая кнопка ещё удерживается), статус-регистр требуется «сбросить в единицы (SER)» -> так в регистре установится ошибочный статус-код, который не будет спутан ни с одной из разрешённых комбинаций, что запретит прикладному коду реагировать на эту кнопку, в дальнейшем. (Это служебное, исключительное состояние статус-регистра: «фиксация, до ожидания следующего отпускания» кнопки — ОТЛОЖЕННЫЙ СБРОС.)
  3. В то же время, как только физическая кнопка будет отпущена, сразу же, статус-регистр АВТОМАТИЧЕСКИ будет «сброшен в ноль», в исходное положение. (Это исключительная реакция конвейера обработки кнопок: лишнее нажатие на кнопку не будет зафиксировано!)

Рекомендуется: ВО ВСЕХ СЛУЧАЯХ, после обработки любых статус-кодов, СБРАСЫВАТЬ статус-регистры отработанных кнопок «В ЕДИНИЦЫ»! Так установится статус «ОТЛОЖЕННЫЙ СБРОС», который, даже если кнопка уже отжата, то при следующем цикле конвейера — будет автоматически «сброшен в ноль». Это безопасный стиль программирования!
Замечу: При таком стиле программирования — кнопка работает «с триггером-защёлкой состояния». Вариант поведения «с триггером»: заставляет пользователя отпускать кнопку каждый раз, перед её следующим нажатием — что обычно полезно, ибо предотвращает серии ошибочных повторных срабатываний кнопки.

Хотя, в некоторых случаях, можно и отходить от этого правила: кроме кнопок-модификаторов, упомянутых выше… Ещё бывает полезно использовать кнопки «без триггера-защёлки состояния» — для умышленной организации серийных реакций на нажатую и удерживаемую кнопку.
Например, рецепт: как двумя кнопками «больше/меньше» организовать эргономичный интерфейс подстройки параметра: «пользователь нажал кнопку и удерживает — после секундной паузы, значение начинает автоматически набегать +1, +1,… а через некоторое время, начинает набегать быстрее +5, +5. » Пример, см. ниже.

4. Работа с Энкодерами

В отличие от кнопок, Энкодер — гораздо проще в управлении! У него всего одна степень свободы: он может вращаться «по часовой» или «против часовой» стрелки. Скорость и динамика вращения не контролируются. Значение имеют лишь: количество сосчитанных тиков и направление вращения, которые отражаются числом в «регистре счётчика» Энкодера.

От энкодера, по двум «физическим каналам», поступает «2-битный рефлексивный код Грэя». Обычно, канал «B» сдвинут на 90°, относительно канала «A», при повороте по часовой стрелке:

4.1. Выбор алгоритма обработки Энкодера

Вся магия обработки энкодера реализована в процедуре KEY_UPDATE_ENCODER_STATUS — она Фиксирует статус Энкодера (устанавливает значения в «статус-регистре» и «счётчике тиков» Энкодера), в зависимости от динамически изменяющихся [проинтегрированных] состояний его двух управляющих «физических каналов»: AC и BC.

В процедуру KEY_UPDATE_ENCODER_STATUS передаются следующие параметры:

  • Регистровым параметром «IntegratorAddress» передаётся адрес ПЕРВОГО «регистра интегратора» (из пары последовательно расположенных регистров в памяти ОЗУ, которые кодируют текущее «физическое» состояние Энкодера).
    (Примечание: в целях оптимизации кода, при исполнении процедуры, указатель «IntegratorAddress» передвигается на (+1) байт вперёд. И после исполнения процедуры — указывает на следующую ячейку памяти.)
  • Регистровым параметром «StatusAddress» передаётся адрес «статусного регистра энкодера» (в памяти ОЗУ). При этом, предполагается, что следом за ним расположен регистр «счётчика тиков» этого Энкодера. Их оба — следует обновить…
    (Примечание: в целях оптимизации кода, при исполнении процедуры, указатель «StatusAddress» передвигается на (+1) байт вперёд. И после исполнения процедуры — указывает на следующую ячейку памяти.)

Существует три варианта реализации кода процедуры KEY_UPDATE_ENCODER_STATUS, которые выбираются директивами условной компиляции:
Выберите один из трёх вариантов, раскомментировав определение соответствующего символа в файле :

  1. .EQU ENCODER_USE_SIMPLIFIED_CODE = 1 «Упрощённый код» (простой алгоритм, маленький и быстрый код! не защищён от ошибочных входных сигналов; предделитель фиксирован = 4 раза)
    Рекомендуется использовать на стабильном железе: быстром Микроконтроллере и при низком уровне помех по входным каналам. Примечание: в этом варианте, код «предварительного делителя счётчика» не используется — но делитель есть и фиксирован: показания «счётчика тиков» делятся в 4 раза.
  2. .EQU ENCODER_USE_ACADEMIC_CODE = 2 «Академический код» (самый компактный код и поражает воображение своим изяществом! но не защищён от ошибочных входных сигналов)
    Преимущества: он проще/меньше/быстрее параноидального кода, и с ним работает полноценный «предварительный делитель счётчика»! Но обычно, не рекомендуется его использовать: т.к. он является «серединкой на половинку» среди других вариантов, и особых преимуществ не даёт…
    Замечу что, на плохом железе: «Академический код» глючит столь же интенсивно, как и «Упрощённый код», но они по разному ощущаются — выбери себе глюки по вкусу! ;)
  3. .EQU ENCODER_USE_PARANO >Предполагается, будет математически сглаживать и преодолевать последствия некоторых ошибок опроса физических каналов энкодера (при пропуске одного такта — запрещённая комбинация по входу, будет проигнорирована). Используйте этот вариант на плохом железе: при медленном микроконтроллере, или когда опрос энкодера происходит с ошибками.

Во-вторых, выберите коэффициент «предварительного делителя счётчика тиков» энкодера:

  • Здесь, допустимые значения предделителя = 2,3,4 переключения / на один тик счётчика. Рекомендуется = 4.
  • Если символ закомментирован — то предделитель отключён (т.е. установлен = 1 переключение/тик счётчика)!
  • Примечания: Предделитель не используется в режиме ENCODER_USE_SIMPLIFIED_CODE (там коэффициент деления фиксирован и, вследствие особенностей алгоритма, установлен = 4 раза).
4.2. Формат «регистра Статуса» Энкодера

(Справка: Расположены в секции DEncoderStatus в файле , первый из пары)

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

Замечу, однако, что прикладной код никогда не использует «статусный регистр энкодера» напрямую! Он, вспомогательный, нужен лишь для вычисления направления вращения энкодера, например, используя булеву функцию: F2(x1,x2,y1,y2) = (НЕ(x1) * y2) + (x1 * НЕ(y2)). Вращения энкодера, если таковые были произведены, и их направление — инкрементируются к регистру «двунаправленного аддитивного счётчика тиков» энкодера. (Всё это происходит в служебных процедурах «конвейера обработки кнопок», в частности, в коде процедуры KEY_UPDATE_ENCODER_STATUS.)

8-битный регистр разделён на две «тетрады»:

  • В первой тетраде DEncoderStatus[3:0] = закодировано предыдущее состояние энкодера.
  • Во второй тетраде DEncoderStatus[7:4] = закодировано последнее состояние энкодера.
  • Биты DEncoderStatus[2:3] содержат «предварительный делитель счётчика» = 1..4, через который «по 4 переключения входных сигналов на один тик» преобразуются к фактическому числу тиков, накапливаемому в регистре «счётчика тиков» энкодера.
  • (бит номер 6 — не используется, и равен 0)

Описание битов «регистра статуса» энкодера:

Кодировка значения функции вращения:

  • F = 0 C.W., вращение по часовой («правый винт») -> (+1) к счётчику
  • F = 1 C.C.W., вращение против часовой («левый винт») -> (-1) к счётчику

Причём, кодировка входных каналов X и Y (=0 или 1?), здесь, в принципе, не важна — используется лишь порядок их переключения.

Предупреждение: Начальное состояние статус-регистра = 0b00000000, не является «разрешённой комбинацией» входных сигналов, но алгоритм не сломает. Ну, в худшем случае: сразу после RESET, в «регистр счётчика» энкодера может попасть +1/-1… (не важно!)

4.3. Формат «регистра Счётчика» Энкодера

(Справка: Расположены в секции DEncoderStatus в файле , второй из пары)

Регистр «счётчика тиков» особой специальной структуры не содержит — это просто знаковое целое число: Signed short int = [-128..127].
Начальное состояние = 0b00000000.

Илон Маск рекомендует:  Что такое код cpdf_rlineto
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL