Среда программирования Библиотеки C++ (стр. 87 )

Некоторые ограничения применяются и описаны в этой секции.

Определение Внешних Функций

Когда ObjectARX-приложение получает запрос kLoadDwgMsg от AutoCAD, это должно определить все его внешние функции, вызывая acedDefun () однажды для каждой функции. AcedDefun () запрос связывает имя внешней функции (прошел как строковое значение) с целочисленным кодом, который является уникальным в пределах приложения. Целочисленный код не должен быть отрицателен, и это не может быть большее чем 32,767 (другими словами, код - короткое целое число).

Следующий запрос к acedDefun () определяет, что AutoLISP признает, что внешняя функция вызвала doit в AutoLISP, и что, когда AutoLISP вызывает doit, это передает функциональный нуль кода (0) к ObjectARX-приложению:

AcedDefun ("doit", 0);

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

Внешние функции определены отдельно для каждого открытого документа в MDI. Функция определяется, когда документ становится активным. Для подробной информации, см. главу 16, “ Многодокументная среда. ”

ПРЕДУПРЕЖДЕНИЕ! Если два или больше ObjectARX-приложения определяют функции (в том же самом документе) которые имеют то же самое имя, AutoLISP признает только наиболее недавно определенную внешнюю функцию. Предварительно загруженная функция будет потеряна.

Это может также случаться, если пользователь вызывает defun с противоречивым именем.

Как в AutoLISP, новая функция может быть определена как команда AutoCAD приписыванием ее имя с “ C: ” или “ c: ”, как показано в следующем примере:

AcedDefun ("C:DOIT", 0);

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

Функции, определенные как команды AutoCAD могут все еще быть вызваны от выражений AutoLISP, при условии, что “ C: ” префикс включен как часть их названий.

Например, учитывая предыдущий acedDefun () запрос, пользователь AutoCAD мог также вызывать команду DOIT как функция с параметрами:

Команда: (c:doit x y)

ПРЕДУПРЕЖДЕНИЕ! Если приложение определяет команду C:XXX, чей конфликты имен со встроенной командой или именем команды, определенным в acad. pgp файле, AutoCAD не признает внешнюю функцию как команда. Функция может все еще вызываться как AutoLISP внешняя функция. Например, после запроса acedDefun ("c:cp", 0), ввод пользователя cp (псевдоним для COPY, определенного в acad. pgp) вызывает команду COPY AutoCAD, но пользователь мог вызывать внешнюю функцию с c:cp.

ОБРАТИТЕ ВНИМАНИЕ Имена функции, определенные acedDefun () могут быть неопределены, вызывая acedUndef (). После того, как функция была неопределена, попытка вызывать это вызывает ошибку.

Оценка Внешних Функций

Как только внешняя функция была определена, AutoLISP может вызывать это с запросом kInvkSubrMsg. Когда ObjectARX-приложение получает этот запрос, это отыскивает целочисленный код внешней функции, вызывая acedGetFunCode (). Тогда инструкция выключателя, условный оператор, или таблица с функциональным запросом могут выбирать и вызывать обозначенный функциональный обработчик. Это - функция, что ObjectARX-приложение определяет, чтобы осуществить внешнюю функцию. Обратите внимание, что имя обработчика и имени, определенного acedDefun () (и поэтому признанный AutoLISP) - не обязательно то же самое имя.

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

ОБРАТИТЕ ВНИМАНИЕ, что функциональный обработчик должен проверить номер, и тип параметров прошел к этому, потому что не имеется никакого способа сообщить AutoLISP, каковы требования.

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

Группа функций ObjectARX известный как функции возвращения значения (типа acedRetInt(), acedRetReal(), и acedRetPoint()) позволяет внешней функции возвратить значение выражению AutoLISP, которое вызвало это.

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

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

( Doitagain pstr iarg rarg)

Принимая, что функция была определена acedDefun(), пользователь AutoCAD может вызывать это со следующим выражением:

Команда: (doitagain “ Стартовая ширина - ” 3 7.12)

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

Параметры, к которым doitagain () функциональный обработчик отыскивает запросом

AcedGetArgs (). Для примера поиска параметров таким образом, см. первый пример в “ Списки и Другие Динамически Размещенные Данные ” на странице 546.

Обработка ошибок

Среда AutoCAD сложна и интерактивна, так что приложения ObjectARX должны быть устойчивы. ObjectARX обеспечивает несколько средств обработки ошибок.

Коды результата, возвращенные в течение “подтверждения связи” с AutoLISP указывают, условия ошибки, также, как и результат закодируют библиотечные функции, возвращенные приложению. Функции, которые запрашивают относительно ввода от пользователя AutoCAD, используют{*нанимают*} встроенные проверяющие ввод возможности AutoCAD. Кроме того, три функции позволяют приложению уведомлять пользователей относительно ошибки: acdbFail (), acedAlert () и acrxAbort ().

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

Инструкция в следующем примере вызывает acdbFail () от программы, названной test. arx:

AcdbFail (" недействительный osnap point\n ");

AcdbFail () функция отображает следующее:

Приложение test. arx ОШИБКА: недействительная точка osnap

Вы можете также предупреждать пользователя относительно условий ошибки, отображая окно предупреждения. Чтобы отображать окно предупреждения, вызовите acedAlert (). Окна предупреждения - более решительный путь предупреждения пользователя, потому что пользователь должен выбрать ХОРОШО перед продолжением.

Для фатальных ошибок, acrxAbort () должен быть вызван. Эта функция запрашивает пользователя сохранять работу в прогрессе перед переходом. Стандартный выход C++ () функция не должен быть вызван.

Чтобы получить детальную информацию относительно неудачи функции ObjectARX, осмотрите переменную системы AutoCAD ERRNO. Когда некоторая функция ObjectARX вызывает (или функция AutoLISP вызывает) вызывают ошибку, ERRNO установлен в значение, которое приложение может отыскивать запросом к acedGetVar (). ObjectARX определяет символические названия для кодов ошибки в файле заголовка, который может быть включен ObjectARX-приложениями, которые исследуют ERRNO.

Эти коды показываются в ObjectARX Ссылке. Типовое ObjectARX-приложение, ads_perr, отображает сообщения об ошибках, основанные на значении ERRNO.

Связь между Приложениями

Функция ObjectARX acedInvoke () в одном приложении используется, чтобы вызвать внешние функции, определенные и осуществленные другими приложениями ObjectARX.

Внешняя функция, вызванная acedInvoke() должна быть определена в настоящее время загруженным ObjectARX-приложением.

AcedInvoke() функция вызывает внешнюю функцию именем, что его приложение определило в acedDefun() запрос, который является именем функции, что AutoLISP вызывает, чтобы вызвать функцию. Если внешняя функция была определена как команда AutoLISP, с “ C: ” как префикс к его имени, эти символы должны быть включены в строку, как которая acedInvoke () определяет (когда команда вызвана с выражением AutoLISP).

ПРЕДУПРЕЖДЕНИЕ! Поскольку приложения, загруженные в то же самое время не могут иметь двойные имена функции, Вы должны брать это во внимание при проектировании приложения, которое использует больше чем единственный программный файл; избегите проблемы со схемой обозначения или соглашением, которое гарантирует, что имя каждой внешней функции будет уникально. Лучшее решение состоит в том, чтобы использовать ваш Зарегистрированный Символ Разработчика (RDS) как префикс.

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

Следующая типовая функция вызывает acedInvoke () чтобы вызвать факт функции факториала () в типовой программе fact. cpp:

static void test()

{

int stat, x = 10;

struct resbuf *result = NULL, *list;

// Get the factorial of x from file fact. cpp.

list = acutBuildList(RTSTR, "fact", RTSHORT, x, RTNONE);

if (list!= NULL) {

stat = acedInvoke(list, &result);

acutRelRb(list);

}

if (result!= NULL) {

acutPrintf("\nSuccess: factorial of %d is %d\n", x, result->resval. rint);