Чтоб красиво все оформить
Пожалуй, наивно было бы полагать, что нынешнюю свою известность СУБД смогли бы завоевать, опираясь на одни лишь таблицы и связи между ними.Обычно самым популярным программным продуктом является тот, чей интерфейс наиболее интуитивно понятен, удобен в использовании и не требует от потребителя наличия большого объема специальных знаний, что, правда, не исключает потребности в определенной квалификации. В области СУБД таким фасадом является специально разрабатываемая форма, с одной стороны, закрывающая собой все внутренние механизмы конкретной базы данных, а с другой - обеспечивающая связь между программой и человеком.
Перед тем как перейти к непосредственному описанию механизма создания форм, следует сначала рассмотреть некоторые теоретические моменты. Собственно говоря, речь идет о некоем неформальном наборе правил "хорошего тона", которые нигде не записаны и никем не утверждены к обязательному выполнению, но их подсказывает богатый опыт разработки и сопровождения различных СУБД в разных областях человеческой деятельности.
Первое правило гласит, что любая форма должна быть функционально законченной. Имеется в виду, что для получения всей необходимой информации от человека не должно требоваться перехода на какие бы то ни было дополнительные формы. Как правило, пользователям в таких случаях бывает крайне сложно ориентироваться, что приводит к неминуемым ошибкам и большим потерям рабочего времени, а также лишним расходам машинных ресурсов. Этого не так легко добиться, и уж тем более, этого нельзя добиться, если форма разрабатывается, как говорится, "на вскидку". Таким образом, при разработке формы следует непременно выполнить два подготовительных действия. Первое - четко очертить круг задач, которые должны решаться при помощи данной формы. Второе - сформулировать эти задачи таким образом, чтобы форма предоставляла всю необходимую информацию для их выполнения.
Второе правило говорит, что удобство пользования той или иной формой самым тесным образом зависит от ее эргономических и логических характеристик. Предположим, вы создаете форму для ввода почтового адреса с конвертов. Формально, никто вам не мешает расположить поля таким образом, чтобы они просто красиво смотрелись на экране. Однако если окажется, что, предположим, поле для ввода расположено в левом верхнем углу экрана, а поле для наименования страны или города - в правом нижнем, то такой формой, вероятнее всего, будет крайне неудобно пользоваться. Поэтому, для сокращения количества пустых переходов между полями и улучшения визуальной воспринимаемости вводимой информации, поля ввода формы лучше располагать в том же порядке, в котором информация либо поступает на обработку, либо воспринимается оператором как естественная. Например, фамилию, имя и отчество рациональнее всего располагать именно в таком порядке, либо как имя, отчество, фамилия, но ни в коем случае не как-либо иначе.
Третье правило требует максимального использования в форме встроенных алгоритмов автоматизации. Разрабатывая форму, следует обратить пристальное внимание на то, в каком порядке будет поступать или восприниматься ее информация. Тут следует делать различие между теми формами, которые станут применяться для занесения данных в базу, и теми, при помощи которых эту информацию пользователи будут просматривать. При этом нужно обязательно не только выстраивать поля в должной последовательности, но и настраивать их свойства таким образом, чтобы по окончании ввода фактических данных в одно поле и нажатии клавиши " ВВОД" маркер ввода автоматически перескакивал в следующее поле, в которое должны быть введены следующие данные. Тогда работа оператора сведется лишь к набору каких-то символов с клавиатуры и периодическому нажатию на " ВВОД", без утомительной процедуры переноса маркера ввода при помощи мыши. Это только кажется, что подобная операция не требует от человека каких-либо усилий. Стоит поработать в плохо организованной форме часа два, как все эти тонкости и нюансы тут же отразятся на общем самочувствии. Уж можете мне поверить.
Точно так же, везде, где это возможно, при разработке форм следует пользоваться автоподстановкой и вводом данных по умолчанию. Это значительно облегчает работу как с формой в частности, так и со всей СУБД вообще. Кроме того, автоподстановка, помимо облегчения набора данных, решает еще одну проблему, проблему возникновения сбоев при работе программных модулей и макросов. Дело в том, что любая база данных это палка о двух концах. С одной стороны, формализация информации зачастую требует постоянного ввода даже тех данных, которые человеку совершенно очевидны. Допустим, уже по одному почтовому индексу можно с уверенностью сказать, в какой стране проживает адресат. Однако, это не снимает необходимость наличия в этой же базе отдельного поля, в котором должно храниться название этой страны. Если при обработке разнообразной международной почтовой корреспонденции операторы постоянно проверяют страну, то когда основной поток писем приходит из одного региона, пользователи, как правило, не стремятся каждый раз заполнять поле " Страна" вообще. Мол, и ежику понятно... Ежику-то оно, может быть, и понятно, но СУБД этого не понимает и оставляет такое поле совершенно пустым. Причем с точки зрения любого алгоритма базы данных "пустое" поле и поле, в котором, например, хранится цифра "0", это два совершенно разных поля. Даже если они оба имеют одинаковый формат. Не знаю, куда смотрели разработчики, в частности СУБД Microsoft Access, но как только любой модуль или макрос, не имеющий специального обработчика подобных ситуаций натыкается на "пустое" поле (т.е. на поле, которое было попросту пропущено при вводе данных), то он автоматически прерывает свою работу и выдает сообщение об ошибке. И это в самом лучшем случае. В худшем он таких дров наломает - и за неделю не разберешься! Человека, как известно, заставить сложно. Тем более, в условиях длительной монотонной работы, значительно притупляющей наблюдательность и внимание. И чтобы не писать лишние фрагменты кода, не усложнять жизнь себе и тому компьютеру, на котором вашей базе предстоит работать, лучше всего позаботиться об этом сразу. Если вернуться к приведенному выше примеру с почтовым адресом, то весьма изящным и простым решением будет задать в свойствах поля " Город" условие, согласно которому форма самостоятельно будет подставлять наименование какого-то конкретного населенного пункта (или запись Н/Д, что означает "нет данных"), если пользователем не введено иное. Работает это весьма просто. Если оператор пропустил данное поле, то программа автоматически подставила в него типовое заполнение и "пошла дальше". Если же оператор остановился на данном поле и ввел с клавиатуры свое значение, то автозаполнение не производится.
Четвертое правило гласит, что любой элемент каждой формы должен быть снабжен предельно простым наименованием и сопровождаться интерактивной подсказкой или кратким описанием. Не стоит забывать, что даже сами разработчики по прошествии некоторого времени почти повсеместно забывают, что, где и как конкретно они делали или что именно имели в виду. Что уж тогда можно ожидать от простого оператора, для которого ваша база "тайна великая есть"! Как правило, хорошие, даже заказные, программные продукты снабжаются, как минимум, интерактивной справочной системой, а как максимум - еще и бумажным пособием по эксплуатации. Но и то, и другое не является идеальным решением. На переключение в help или на судорожное листание "мануала" в поисках ответа на, в общем-то, простой вопрос уходит слишком много времени. Особенно если этот вопрос сводится к пояснению назначения того или иного поля какой-то формы. Куда приятнее или удобнее, когда можно просто навести на ее край указатель мыши и прочитать содержание пояснительной надписи, которая автоматически будет выведена на экран. Хорошим тоном при разработке форм базы данных является применение способа, достаточно типичного для многих приложений операционной системы Microsoft Windows 95/98. Суть его сводится к тому, что описанная выше подсказка выводится не в отдельное яркое окно, которое немедленно бросается в глаза, а появляется в нижней части окна формы на фоне самого этого окна. Как это выглядит, можно посмотреть, например, на окне мастера макросов в электронных таблицах Microsoft Excel. Вы выбираете выделением интересующую вас команду, а в нижней части окна мастера тут же выводится краткое описание ее назначения и области применения. Очень удобно и не режет глаз, когда вы случайно вызвали подсказку и не нуждаетесь в ней. Иными словами, подсказка появляется всегда, но происходит это тихо и ненавязчиво, предоставляя человеку свободу выбора: пользоваться ею или нет.
Пятое и последнее правило гласит, что при разработке пользовательской формы нет и не может быть места никакой демократии. Если вы действительно желаете, чтобы ваша база данных на самом деле работала "как надо", а не "спотыкалась" по десять раз в день, то вы должны сразу оставить пользователю лишь те варианты действий, которые ему необходимы. Даже самые опытные разработчики СУБД не могут сказать с абсолютной достоверностью, какие действия пользователя следует принудительно запретить во избежание возникновения логических, синтаксических и прочих сбоев программного алгоритма. Обычно любая СУБД состоит из многочисленных модулей, призванных решать свою собственную отдельную задачу в рамках всего проекта. Это позволяет значительно сократить затраты на программирование и отладку продукта. Но это же порождает серьезную проблему соответствия фактических данных теоретическим. Особенно в больших и многофункциональных базах, оперирующих гигантским массивом самых разнородных данных и обслуживающих множество пользователей единовременно. Поэтому единственным путем "облегчения жизни" является строгое следование принципу "запрещено все то, что не разрешено".
На практике это реализовывается при помощи нескольких приемов, конкретное сочетание которых зависит от каждой решаемой задачи. При разработке любой формы желательно сразу отключать такие ее свойства, как возможность минимизации или изменения размеров в ручном режиме. Само по себе, это действе не наносит вреда, но, "свернув" форму, пользователь может совершенно не к месту попасть в другую, ранее недоступную, форму, работа которой тесно связана с теми данными, которые задаются в только что свернутой форме. Тогда попытка активизации ранее недоступной формы может привести к серьезному сбою самой СУБД. Теоретически учебники по программированию рекомендуют буквально в каждом случае предусматривать собственные алгоритмы проверки корректности процесса работы и аварийного его завершения в случае возникновения ошибки. И, по большому счету, это правильно. Но далеко не всегда подобные рекомендации можно выполнить на практике. Представьте себе форму с двумя десятками полей, каждое из которых "сторожит" отдельный програм-мный алгоритм. Это означает, что вместе с указанной формой в память компьютера должны быть подгружены все эти "сторожа", что, как известно, требует изрядного ее объема. Далеко не каждый компьютер окажется в состоянии "переварить" подобную задачу. Причем в данном случае ситуацию не спасает даже наличие специально разработанного системного модуля по динамическому управлению памятью и своевременному удалению оттуда всего лишнего. Во-первых, написание такого модуля требует довольно большого объема знаний и навыков в системном программировании под Microsoft Windows 95/98. Во-вторых, сами алгоритмы управления памятью в "девяносто пятых окнах" далеко не безгрешны и страдают застарелой болезнью накопления мелких ошибок и ростом степени фрагментации самой свободной памяти. На практике это оборачивается тем, что программы, активно оперирующие компьютерной памятью, после не столь уж и длительного периода непрерывной активной эксплуатации становятся подвержены тотальным сбоям, нередко приводящим не только к собственному "зависанию", но и к "мертвому зависанию" всего персонального компьютера. Что характерно и весьма неприятно, они, так сказать, "подвержены внезапно...". Таким образом, принудительное исключение возможности несанкционированного "ухода" оператора с окна активной формы является самым простым, надежным и удобным решением этой непростой задачи.
К этому же классу задач относится и разработка специального алгоритма "процедуры внесения записи". Предположим простую ситуацию. Оператор начал ввод данных в форму, как внезапно пропало питание и терминал "лег". В случае, если форма длинная, то есть содержит множество полей, или, тем более, если форма сложная, то есть состоит из нескольких взаимосвязанных форм, опирающихся на разные запросы и разные таблицы, может "элементарно" возникнуть ситуация, когда в одни таблицы данные уже будут занесены, в другие - нет. Уж можете мне поверить, ничего более худшего для СУБД и придумать нельзя. Практически повсеместно такая ситуация заканчивается большими повреждениями таблиц данных как в процессе сбоя, так и в процессе последующей их эксплуатации. Чтобы избежать подобной ситуации, часто применяют некую промежу-точную таблицу, выполняющую роль буфера. Непосредственно форма "привязывается" не к самим таблицам или запросам, в которых хранятся данные, а к буферу. Отдельно разработанный макрос или запрос-действие, автоматически переносит информацию из буфера в нужные места СУБД, но делает это не ранее, чем будут соответствующим образом заполнены абсолютно все поля таблицы-буфера и поступит специально установленная команда об окончании процедуры ввода. В этом случае сбой в результате пропадания питания или случайной команды о принудительной "горячей" перезагрузке приведет только к потере содержимого буфера (то есть всего одной, последней, записи), но никоим образом не затронет всю остальную информацию.
Весьма полезно предварять все серьезные действия, особенно критические, отмена которых затруднена или вообще невозможна, специальными дополнительными уведомлениями, обращающими внимание пользователя на важность момента, причем, чтобы активной, то есть по умолчанию подготовленной к исполнению, не оказалась именно та управляющая кнопка, нажатие на которую приводит к выполнению этого действия. Человек часто реагирует инстинктивно, особенно если он устал или занят сразу несколькими делами одновременно. Поэтому ему "ничего не стоит" чисто автоматически нажать на " ВВОД", едва завидев окно с предупреждением и даже толком не прочитав, что на нем, собственно, написано. А теперь представьте себе, пусть утрированную, но все же совершенно реальную ситуацию, что на указанном окне написано: "Вы желаете произвести низкоуровневое форматирование жесткого диска? Да/Нет", а активной клавишей является экранная кнопка " Да"...
Увы, рамки газетной статьи не позволяют перечислить все тонкости и особенности разработки экранных форм, но, по крайней мере, мне удалось привлечь к этому ваше внимание. Во всяком случае, я на это надеюсь. Вообще говоря, разработать хорошую форму (я не трогаю вопрос цветового или любого другого, чисто оформительского, решения) не так уж и сложно. Достаточно придерживаться принципа простоты и не стремиться любой ценой продемонстрировать собственную программистскую лихость. Как правило, наиболее удачными оказываются как раз простые решения.
Александр Запольскис
Перед тем как перейти к непосредственному описанию механизма создания форм, следует сначала рассмотреть некоторые теоретические моменты. Собственно говоря, речь идет о некоем неформальном наборе правил "хорошего тона", которые нигде не записаны и никем не утверждены к обязательному выполнению, но их подсказывает богатый опыт разработки и сопровождения различных СУБД в разных областях человеческой деятельности.
Первое правило гласит, что любая форма должна быть функционально законченной. Имеется в виду, что для получения всей необходимой информации от человека не должно требоваться перехода на какие бы то ни было дополнительные формы. Как правило, пользователям в таких случаях бывает крайне сложно ориентироваться, что приводит к неминуемым ошибкам и большим потерям рабочего времени, а также лишним расходам машинных ресурсов. Этого не так легко добиться, и уж тем более, этого нельзя добиться, если форма разрабатывается, как говорится, "на вскидку". Таким образом, при разработке формы следует непременно выполнить два подготовительных действия. Первое - четко очертить круг задач, которые должны решаться при помощи данной формы. Второе - сформулировать эти задачи таким образом, чтобы форма предоставляла всю необходимую информацию для их выполнения.
Второе правило говорит, что удобство пользования той или иной формой самым тесным образом зависит от ее эргономических и логических характеристик. Предположим, вы создаете форму для ввода почтового адреса с конвертов. Формально, никто вам не мешает расположить поля таким образом, чтобы они просто красиво смотрелись на экране. Однако если окажется, что, предположим, поле для ввода расположено в левом верхнем углу экрана, а поле для наименования страны или города - в правом нижнем, то такой формой, вероятнее всего, будет крайне неудобно пользоваться. Поэтому, для сокращения количества пустых переходов между полями и улучшения визуальной воспринимаемости вводимой информации, поля ввода формы лучше располагать в том же порядке, в котором информация либо поступает на обработку, либо воспринимается оператором как естественная. Например, фамилию, имя и отчество рациональнее всего располагать именно в таком порядке, либо как имя, отчество, фамилия, но ни в коем случае не как-либо иначе.
Третье правило требует максимального использования в форме встроенных алгоритмов автоматизации. Разрабатывая форму, следует обратить пристальное внимание на то, в каком порядке будет поступать или восприниматься ее информация. Тут следует делать различие между теми формами, которые станут применяться для занесения данных в базу, и теми, при помощи которых эту информацию пользователи будут просматривать. При этом нужно обязательно не только выстраивать поля в должной последовательности, но и настраивать их свойства таким образом, чтобы по окончании ввода фактических данных в одно поле и нажатии клавиши " ВВОД" маркер ввода автоматически перескакивал в следующее поле, в которое должны быть введены следующие данные. Тогда работа оператора сведется лишь к набору каких-то символов с клавиатуры и периодическому нажатию на " ВВОД", без утомительной процедуры переноса маркера ввода при помощи мыши. Это только кажется, что подобная операция не требует от человека каких-либо усилий. Стоит поработать в плохо организованной форме часа два, как все эти тонкости и нюансы тут же отразятся на общем самочувствии. Уж можете мне поверить.
Точно так же, везде, где это возможно, при разработке форм следует пользоваться автоподстановкой и вводом данных по умолчанию. Это значительно облегчает работу как с формой в частности, так и со всей СУБД вообще. Кроме того, автоподстановка, помимо облегчения набора данных, решает еще одну проблему, проблему возникновения сбоев при работе программных модулей и макросов. Дело в том, что любая база данных это палка о двух концах. С одной стороны, формализация информации зачастую требует постоянного ввода даже тех данных, которые человеку совершенно очевидны. Допустим, уже по одному почтовому индексу можно с уверенностью сказать, в какой стране проживает адресат. Однако, это не снимает необходимость наличия в этой же базе отдельного поля, в котором должно храниться название этой страны. Если при обработке разнообразной международной почтовой корреспонденции операторы постоянно проверяют страну, то когда основной поток писем приходит из одного региона, пользователи, как правило, не стремятся каждый раз заполнять поле " Страна" вообще. Мол, и ежику понятно... Ежику-то оно, может быть, и понятно, но СУБД этого не понимает и оставляет такое поле совершенно пустым. Причем с точки зрения любого алгоритма базы данных "пустое" поле и поле, в котором, например, хранится цифра "0", это два совершенно разных поля. Даже если они оба имеют одинаковый формат. Не знаю, куда смотрели разработчики, в частности СУБД Microsoft Access, но как только любой модуль или макрос, не имеющий специального обработчика подобных ситуаций натыкается на "пустое" поле (т.е. на поле, которое было попросту пропущено при вводе данных), то он автоматически прерывает свою работу и выдает сообщение об ошибке. И это в самом лучшем случае. В худшем он таких дров наломает - и за неделю не разберешься! Человека, как известно, заставить сложно. Тем более, в условиях длительной монотонной работы, значительно притупляющей наблюдательность и внимание. И чтобы не писать лишние фрагменты кода, не усложнять жизнь себе и тому компьютеру, на котором вашей базе предстоит работать, лучше всего позаботиться об этом сразу. Если вернуться к приведенному выше примеру с почтовым адресом, то весьма изящным и простым решением будет задать в свойствах поля " Город" условие, согласно которому форма самостоятельно будет подставлять наименование какого-то конкретного населенного пункта (или запись Н/Д, что означает "нет данных"), если пользователем не введено иное. Работает это весьма просто. Если оператор пропустил данное поле, то программа автоматически подставила в него типовое заполнение и "пошла дальше". Если же оператор остановился на данном поле и ввел с клавиатуры свое значение, то автозаполнение не производится.
Четвертое правило гласит, что любой элемент каждой формы должен быть снабжен предельно простым наименованием и сопровождаться интерактивной подсказкой или кратким описанием. Не стоит забывать, что даже сами разработчики по прошествии некоторого времени почти повсеместно забывают, что, где и как конкретно они делали или что именно имели в виду. Что уж тогда можно ожидать от простого оператора, для которого ваша база "тайна великая есть"! Как правило, хорошие, даже заказные, программные продукты снабжаются, как минимум, интерактивной справочной системой, а как максимум - еще и бумажным пособием по эксплуатации. Но и то, и другое не является идеальным решением. На переключение в help или на судорожное листание "мануала" в поисках ответа на, в общем-то, простой вопрос уходит слишком много времени. Особенно если этот вопрос сводится к пояснению назначения того или иного поля какой-то формы. Куда приятнее или удобнее, когда можно просто навести на ее край указатель мыши и прочитать содержание пояснительной надписи, которая автоматически будет выведена на экран. Хорошим тоном при разработке форм базы данных является применение способа, достаточно типичного для многих приложений операционной системы Microsoft Windows 95/98. Суть его сводится к тому, что описанная выше подсказка выводится не в отдельное яркое окно, которое немедленно бросается в глаза, а появляется в нижней части окна формы на фоне самого этого окна. Как это выглядит, можно посмотреть, например, на окне мастера макросов в электронных таблицах Microsoft Excel. Вы выбираете выделением интересующую вас команду, а в нижней части окна мастера тут же выводится краткое описание ее назначения и области применения. Очень удобно и не режет глаз, когда вы случайно вызвали подсказку и не нуждаетесь в ней. Иными словами, подсказка появляется всегда, но происходит это тихо и ненавязчиво, предоставляя человеку свободу выбора: пользоваться ею или нет.
Пятое и последнее правило гласит, что при разработке пользовательской формы нет и не может быть места никакой демократии. Если вы действительно желаете, чтобы ваша база данных на самом деле работала "как надо", а не "спотыкалась" по десять раз в день, то вы должны сразу оставить пользователю лишь те варианты действий, которые ему необходимы. Даже самые опытные разработчики СУБД не могут сказать с абсолютной достоверностью, какие действия пользователя следует принудительно запретить во избежание возникновения логических, синтаксических и прочих сбоев программного алгоритма. Обычно любая СУБД состоит из многочисленных модулей, призванных решать свою собственную отдельную задачу в рамках всего проекта. Это позволяет значительно сократить затраты на программирование и отладку продукта. Но это же порождает серьезную проблему соответствия фактических данных теоретическим. Особенно в больших и многофункциональных базах, оперирующих гигантским массивом самых разнородных данных и обслуживающих множество пользователей единовременно. Поэтому единственным путем "облегчения жизни" является строгое следование принципу "запрещено все то, что не разрешено".
На практике это реализовывается при помощи нескольких приемов, конкретное сочетание которых зависит от каждой решаемой задачи. При разработке любой формы желательно сразу отключать такие ее свойства, как возможность минимизации или изменения размеров в ручном режиме. Само по себе, это действе не наносит вреда, но, "свернув" форму, пользователь может совершенно не к месту попасть в другую, ранее недоступную, форму, работа которой тесно связана с теми данными, которые задаются в только что свернутой форме. Тогда попытка активизации ранее недоступной формы может привести к серьезному сбою самой СУБД. Теоретически учебники по программированию рекомендуют буквально в каждом случае предусматривать собственные алгоритмы проверки корректности процесса работы и аварийного его завершения в случае возникновения ошибки. И, по большому счету, это правильно. Но далеко не всегда подобные рекомендации можно выполнить на практике. Представьте себе форму с двумя десятками полей, каждое из которых "сторожит" отдельный програм-мный алгоритм. Это означает, что вместе с указанной формой в память компьютера должны быть подгружены все эти "сторожа", что, как известно, требует изрядного ее объема. Далеко не каждый компьютер окажется в состоянии "переварить" подобную задачу. Причем в данном случае ситуацию не спасает даже наличие специально разработанного системного модуля по динамическому управлению памятью и своевременному удалению оттуда всего лишнего. Во-первых, написание такого модуля требует довольно большого объема знаний и навыков в системном программировании под Microsoft Windows 95/98. Во-вторых, сами алгоритмы управления памятью в "девяносто пятых окнах" далеко не безгрешны и страдают застарелой болезнью накопления мелких ошибок и ростом степени фрагментации самой свободной памяти. На практике это оборачивается тем, что программы, активно оперирующие компьютерной памятью, после не столь уж и длительного периода непрерывной активной эксплуатации становятся подвержены тотальным сбоям, нередко приводящим не только к собственному "зависанию", но и к "мертвому зависанию" всего персонального компьютера. Что характерно и весьма неприятно, они, так сказать, "подвержены внезапно...". Таким образом, принудительное исключение возможности несанкционированного "ухода" оператора с окна активной формы является самым простым, надежным и удобным решением этой непростой задачи.
К этому же классу задач относится и разработка специального алгоритма "процедуры внесения записи". Предположим простую ситуацию. Оператор начал ввод данных в форму, как внезапно пропало питание и терминал "лег". В случае, если форма длинная, то есть содержит множество полей, или, тем более, если форма сложная, то есть состоит из нескольких взаимосвязанных форм, опирающихся на разные запросы и разные таблицы, может "элементарно" возникнуть ситуация, когда в одни таблицы данные уже будут занесены, в другие - нет. Уж можете мне поверить, ничего более худшего для СУБД и придумать нельзя. Практически повсеместно такая ситуация заканчивается большими повреждениями таблиц данных как в процессе сбоя, так и в процессе последующей их эксплуатации. Чтобы избежать подобной ситуации, часто применяют некую промежу-точную таблицу, выполняющую роль буфера. Непосредственно форма "привязывается" не к самим таблицам или запросам, в которых хранятся данные, а к буферу. Отдельно разработанный макрос или запрос-действие, автоматически переносит информацию из буфера в нужные места СУБД, но делает это не ранее, чем будут соответствующим образом заполнены абсолютно все поля таблицы-буфера и поступит специально установленная команда об окончании процедуры ввода. В этом случае сбой в результате пропадания питания или случайной команды о принудительной "горячей" перезагрузке приведет только к потере содержимого буфера (то есть всего одной, последней, записи), но никоим образом не затронет всю остальную информацию.
Весьма полезно предварять все серьезные действия, особенно критические, отмена которых затруднена или вообще невозможна, специальными дополнительными уведомлениями, обращающими внимание пользователя на важность момента, причем, чтобы активной, то есть по умолчанию подготовленной к исполнению, не оказалась именно та управляющая кнопка, нажатие на которую приводит к выполнению этого действия. Человек часто реагирует инстинктивно, особенно если он устал или занят сразу несколькими делами одновременно. Поэтому ему "ничего не стоит" чисто автоматически нажать на " ВВОД", едва завидев окно с предупреждением и даже толком не прочитав, что на нем, собственно, написано. А теперь представьте себе, пусть утрированную, но все же совершенно реальную ситуацию, что на указанном окне написано: "Вы желаете произвести низкоуровневое форматирование жесткого диска? Да/Нет", а активной клавишей является экранная кнопка " Да"...
Увы, рамки газетной статьи не позволяют перечислить все тонкости и особенности разработки экранных форм, но, по крайней мере, мне удалось привлечь к этому ваше внимание. Во всяком случае, я на это надеюсь. Вообще говоря, разработать хорошую форму (я не трогаю вопрос цветового или любого другого, чисто оформительского, решения) не так уж и сложно. Достаточно придерживаться принципа простоты и не стремиться любой ценой продемонстрировать собственную программистскую лихость. Как правило, наиболее удачными оказываются как раз простые решения.
Александр Запольскис
Компьютерная газета. Статья была опубликована в номере 19 за 1999 год в рубрике soft :: субд
