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

Конструктор экранов (Screen Builder) побуждает программистов разрабатывать экраны определенного вида и функциональности. Хотя мне и нравится этот стандарт, я не хочу, чтобы у вас создалось впечатление, будто это единственный тип экрана, который возможно создать в FoxPro. Поэтому я начну с концепций, а средства разработчика оставлю на потом. Если вы будете рассматривать конструктор экранов скорее как инструмент, нежели как набор альтернатив, то будете чувствовать себя более комфортно и сможете сделать то, что вам нужно.

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

Простые модели

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

Плоский файл с простым меню

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

В конце программы располагается примерно 10 строк кода, где я использовал старомодный подход для получения значения переменной choice. В версии 2.0 вы можете использовать иной подход:

@ 24,0 CET nChoice PICTURE "* Accept; Ignore"

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

Плоский файл с выпадающими меню

Диалог Locate использует функцию GETEXPR() языка FoxPro, удобную для пользователей- программистов. Обратите внимание, что опция Continue становится активной только после выполнения команды Locate, когда та еще не исчерпала диапазон поиска. Код приложения, управляемого выпадающими меню, снабженного некоторыми дополнениями приведен в листинге 1-2. Эту и предыдущую программы объединяет простота написания и использования. При этом они имеют ряд раздражающих пользователей ограничений. Не всегда видно в каком поле расположен курсор. Типы проверок, которые вы можете организовать с экраном такого типа, ограничены. По этой причине программисты, писавшие на dBASE II, изобрели цикл обработки команды READ (READ loop).

Особые случаи: циклы обработки команды

До появления FoxPro 2.0 единственным способом создать сложные экраны было использование READ loop, названного так, потому что программа включала цикл, внутри которого отслеживалось, какое поле ввода должно быть активизировано следующим. С появлением версии 2.0 число причин использовать такую технику уменьшилось, но некоторое количество все же осталось. Особенно для случая, когда вы хотите дать пользователю возможность свободного перемещения между полями без использования мыши. На основании значения, возвращаемого LASTKEY(), вы можете манипулировать значением переменной _curobj, однако обеспечить быстрый переход к конкретному полю не представляется возможным. По сравнению с простотой программирования под FoxPro 2.0 и использованием мыши, затраты слишком велики. Каждый делает то, что он вынужден делать. Эта методика интересна хотя бы как исторический экскурс и как пример того, насколько стала проще жизнь с появлением READ CYCLE.

SuperGET

Наиболее простым вариантом цикла READ является так называемый цикл SuperGet, использующий структуру DO CASE для определения следующего активизируемого поля. Листинг 1-3 содержит код демонстрирует соответствующий экран. Предлагаемая программа обеспечивает выделение только активного поля. Кроме того, здесь легко организовать проверки ввода.

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

Это будет работать лучше

Если вы построите цикл на использовании массивов вместо структуры DO CASE, производительность будет намного выше. Мне доводилось видеть четырехкратное увеличение скорости при использовании массивов. Программы приведены в листинге 1-4 и листинге 1-5.

Это единственный способ обеспечить свободное перемещение по всему экрану без мыши, с использованием только клавиатуры (a lа Lotus 1-2-3).

Вариации на заданную тему

Рассматриваемая методика имеет значительные возможности расширения. Программа в листинге 1-6 предлагает несколько типов проверок, основанных на перехвате нажимаемых пользователем клавиш.

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

Кроме того, нажатие клавиши Home приводит к переводу курсора в первое поле, а клавиши End - в последнее.

И, наконец, я устроил так, что каждой функциональной клавише назначена строка из двух символов: символ CHR(29) и цифра. Участок кода:

SET CONSOLE OFF ACCEPT TO SecondByte SET CONSOLE ON

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

Способ использования циклов READ в новом смелом мире

Версия FoxPro 2.0 позволяет назначать функциональные и другие клавиши как "Hot keys", что делает приведенный выше маленький трюк не столь актуальным. Кроме того, использование READ...COLOR позволяет принудительно выделять цветом активное поле ввода. Помимо этого структура VALID теперь способна поддерживать до четырех уровней вложенности READ, а значит появились другие способы поддержки процедур анализа ввода, добавляющих новые процедуры анализа по ходу работы.

Ну и зачем тогда, можете вы спросить, заниматься всеми этими премудростями? Вообще говоря, мои заказчики предпочитают иметь возможность перемещения по экрану посредством клавиш управления курсором в любое время. Используя указатель _Curobj и приведенные ранее методы, вы действительно можете привязать структуру VALID ко всем полям для проверки того, какое поле вы только что покинули и какая клавиша при этом была нажата, а конструкция DO CASE обеспечит вам соответствующую реакцию. Но пока такая программа отработает у вас может появиться желание использовать старые подходы.

Экраны и меню в отношении один-ко-многим

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

Базовая модель для экранов с данными из связанных файлов

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

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

Все три подходаобеспечивают достаточное быстродействие. Массивы используют память иначе чем меню pop-up, а BROWSE использует немного или совсем не использует память, выделяемую для пользовательских объектов. Меню pop-up могут иметь текст в нижней части рамки, тогда как меню на базе массивов - нет.

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

Экраны, управляемые "горячими клавишами"

Наиболее интересным нововведением FoxPro 2.0 является возможность предоставления пользователю доступа к любому экрану в любой момент времени. Использование hot-keys   заставляет программу сидеть и ждать нажатия определенной комбинации клавиш, после чего выполнить назначенное данной комбинации действие. Назначение организуется командой
ON KEY LABEL key DO program_name.

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

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

Заключение

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

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