Коды возврата

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

В заголовочном файле sql.h определены следующие коды возврата:

#define SQL_SUCCESS 0	Функция выполнена успешно
#define SQL_SUCCESS_WITH_INFO 1	Функция выполнена успешно, но с уведомительным сообщением
#if (ODBCVER >= 0x0300) #define SQL_NO_DATA 100 #endif	Больше нет строк для извлечения их из результирующего набора. В предыдущей версии ODBC API этот код возврата обозначался как SQL_NO_DATA_FOUND. В версии 3.x код возврата SQL_NO_DATA_FOUND содержатся в заголовочном файле sqlext.h
#define SQL_ERROR (-1)	При выполнении функции произошла ошибка
#define SQL_INVALID_HANDLE (-2)	Указан неверный дескриптор
#define SQL_STILL_EXECUTING 2	Функция, выполняемая асинхронно, пока не завершена
#define SQL_NEED_DATA 99	Для успешного выполнения данной функции следует предварительно определить необходимые данные

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

Для определения типа кода возврата в заголовочном файле sqltypes.h введено следующее объявление:

typedef signed short RETCODE;

Тема 4.3 Разработка клиентского программного обеспечения Тема 4.5 Основные элементы клиентских программ (интерфейс пользователя, справочная система, инсталляционный пакет и т.Д.)

ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС

Понятие пользовательского интерфейса

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

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

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

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

Совсем другое дело — та часть интерфейса, которая относится к программным средствам. Во-первых, для программы значительно сложнее сформулировать объективные требования по составу и компоновке органов управления; зачастую не только пользователи, но и сами разработчики не могут объяснить, почему программа имеет именно такие «рычаги» и «педали». Во-вторых, их перечень значительно шире, а состав изменяется во много раз динамичнее, чем состав аппаратных средств компьютера.

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

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

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

Во втором же случае незнакомый интерфейс новой версии может оказаться психологическим барьером, не преодолев который пользователь так и не сможет воспользоваться преимуществами новой версии. Яркий пример такой ситуации ~ неожиданно медленный (для Microsoft:) переход пользователей от Windows 3.* к Windows 95.

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

Критерии эффективности разработки пользовательского интерфейса.

В оценке качества пользовательского интерфейса существует 3 направления:

• эффективность – влияние интерфейса на полноту и точность достижения результата;

• продуктивность - влияние интерфейса на производительность пользователя;

• степень субъективной удовлетворенности.

Определим критерии эффективного проектирования интерфейса программного продукта.

Разработка проекта интерфейса ПП делится на два самостоятельных этапа: