Lisp ide не работает

Обновлено: 15.01.2025

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

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

Счастливым пользователям Linux установить SLIME просто, достаточно установить пакет SLIME (а он есть, наверное, в подавляющем большинстве дистрибьютивов) и можно пользоваться. В случае неудачи поискать подсказку в интернете. Пользователям Windows сложнее, устанавливать SLIME и emacs придётся вручную, либо скачать готовый комплект LispBox. Последний вариант я и рекомендую пользователям альтернативной операционной системы. LispBox — модульная система, emacs с интегрированным в него SLIME скачивается отдельно, LISP отдельно, причём можно выбрать несколько разных вариантов лиспа. Я рекомендую common lisp (впрочем, для Windows это единственный доступный вариант).

О том, как работать с текстами в emacs имеется множество руководств, к ним я вас и отсылаю. Сама среда SLIME очень проста. На стадии знакомства с языком потребуется несколько пунктов меню (или несколько сочетаний клавиш им соответствующим). Это SLIME->Compilation->Compile Defun , пункт меню или соответствующее сочетание клавиш стоит выбирать после задания очередного определения функции. И SLIME->Evaluation->Eval last expression , которое позволяет выполнить (вычислить) выражение после которого стоит курсор. Остальные пункты меню понадобятся по мере освоения среды, к SLIME прилагается весьма неплохая инструкция на английском языке.

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

Можно также попытаться использовать другие IDE для LISP. Например, вполне неплохой IDE имеется в LispWorks. Остальные проекты, на мой взгляд, не заслуживают внимания. Хотя я буду рад текстам и ссылкам с вашими открытиями.

Таким образом, работа с прилагаемыми программами выглядит так:
- запускаем emacs или LispBox
- если запустили emacs, може потребоваться ввести M-x slime (то есть нажать клавишу Ctrl, не отпуская её x и набрать в появившемся приложении slime).
- открыть файл с примером или создать новый и вставить текст примера через буфер обмена
- скомпилировать файл при помощи SLIME->Compilation->Compile File или каждое определение функции отдельно при помощи SLIME->Compilation->Compile Defun , установив курсор в конце определения.
- теперь можно проверять работу программы, я обычно делаю это в нижнем окне REPL (read-eval-print).

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

Позвольте мне начать с пары слов для тех кто не в курсе. Lisp - это семейство языков, включая Common Lisp, Emacs Lisp и несколько диалектов, которые сегодня используются лишь изредка. Иногда даже язык Scheme считается членом этого семейства. Считать ли это верным, зависит от того, каково ваше точное определение Lisp, но это является слишком сложным (и неинтересным) вопросом для этого эссе.

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

Первый вопрос, который часто задают: «Если Lisp настолько хорош, почему он не популярен?». Люди, которые задают такой вопрос, обычно предполагают, что «хороший» подразумевает «популярный», и поэтому ищут какую-то часть Lisp, которая НЕ является хорошей, что могло бы объяснить, почему он не популярен. Однако нет абсолютно никаких оснований предполагать, что «хороший» подразумевает «популярный», поэтому вопрос действительно довольно наивный. Но вместо того, чтобы просто игнорировать этот вопрос в некоторых частях этого эссе, я на мгновение приму его за чистую монету и попытаюсь объяснить, почему Lisp не так популярен, как хотели бы некоторые его последователи.

Однако позвольте мне сделать небольшое замечание. Lisp не настолько непопулярный, как можно думать (и теперь для удобства я добавлю Emacs Lisp). В недавнем подсчете количества строк Lisp занял 4-е место по количеству строк исходного кода (SLOC) в дистрибутиве Debian GNU/Linux (Woody) после C, C++ и bash с примерно 4 миллионами SLOC (около 4%), опередив Perl, Python, ML, Fortran и т. д. Это довольно популярный язык, лишь несколько менее популярный, чем C и C++. Конечно, количество SLOC в Debian GNU/Linux - не единственный возможный показатель популярности, но это показатель, как и любой другой.

Недавно я увидел статью в comp.lang.lisp, в которой автор серьезно «знал», что с Lisp должно быть что-то не так, потому что, если все будет хорошо, рынок обнаружит это, и Lisp начнет использоваться в программных проектах повсюду. Тот факт, что этого не произошло, «доказал» автору, что с Лиспом ДОЛЖНО быть что-то не так, даже если он не знал, что именно.

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

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

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

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

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

Некоторые люди думают, что с Лиспом что-то не так, потому что практически невозможно заставить программное обеспечение работать без изменений на всех платформах (комбинациях Лисп-систем и операционных систем), тогда как с чем-то вроде Python или Ruby это легко. Ясно же, что здесь с Лиспом что-то не так, верно?

Подождите секунду! Почему это не проблема для таких языков, как Python и Ruby, которые даже НЕ ИМЕЮТ стандарта ANSI? Почему люди не жалуются громко, что они даже не могут написать кросс-платформенный цикл или оператор присваивания на Python, потому что способ сделать это не стандартизирован? Ответ: потому что эти люди путают теплое с мягким или, в данном случае, язык, определяемый (в основном) одной реализацией, и стандарт с несколькими реализациями. Вот как увидеть, насколько это сравнение абсурдно: если бы я написал новую реализацию Python, в которой не было бы сокетов, разве это внезапно ухудшило бы положение языка Python, в сравнении с тем, что было раньше? Конечно, нет! Точно так же люди, которые хотят использовать язык с единственной реализацией и тем самым рискуют, что язык может измениться в одночасье, что, возможно, сделает большую часть некоторых крупных инвестиций устаревшими, должны принять то же самое с Lisp и выбрать единственную реализацию, которая работает во всех операционных системах. Это будет не хуже, чем у любого языка с одной реализацией.

Некоторые ВНУТРИ Lisp-сообщества думают, что Lisp не так популярен, как он того заслуживает, потому что в Common Lisp есть недостатки. Таким образом, предполагаемое решение проблемы состоит в создании лучшего диалекта Lisp.

Откровенно говоря, если бы это было правдой, то ни у одного другого языка не было бы ни единого последователя, учитывая количество недостатков в других языках по сравнению с недостатками Common Lisp. Одной из типичных попыток создать лучший Lisp был Dylan (больше похожий на Scheme, чем на Lisp, на самом деле), который определяет синтаксис без скобок для Lisp-подобного языка, тем самым по существу лишая Lisp одного из его, пожалуй, величайших преимуществ, а именно почти однозначного соответствия между внешним синтаксисом и внутренним представлением кода, что является важной фичей для создания макросов. А Dylan не более популярен, чем Common Lisp.

В последнее время мы регулярно видим людей (обычно также в сообществе Lisp), у которых есть идеальное объяснение того, почему Lisp не так популярен, как он того заслуживает, а именно, что нет ни одной бесплатной реализации, которая работала бы во всех операционных системах и в которой были бы ВСЕ необходимые библиотеки, как в Python и Ruby для веб-программирования и т. д. (мы уже видели, что в стандарте ANSI Common Lisp их нет). Типичная статья одного из этих людей очень снисходительна. Недавно я видел фразы, похожие на «Простите, ребята, но интерфейсы командной строки больше не подходят», «в наши дни все основано на графическом интерфейсе, а у вас даже нет стандартной библиотеки графического интерфейса».

Общий тон, кажется, обвиняет некоторое вымышленное сообщество Lisp в том, что оно не понимает, что именно требуется Lisp с точки зрения библиотек, чтобы стать более популярным. Я согласен, что они правы, что на данный момент нет достаточно хороших библиотек для всех применений. Однако я серьезно сомневаюсь, что решение этой проблемы каким-либо образом повлияет на популярность Lisp. Хуже того, я не понимаю, кому адресованы эти статьи. Некоторые из них, без сомнения, предназначены только для того, чтобы автор отказался от Lisp в пользу более популярного языка, делая это с чистой совестью («это не моя вина, я должен был сделать это, потому что не смог получить нужные мне библиотеки». Все они определенно имеют негативный эффект (желаемый или нежелательный) на людей, которые могут рассматривать использование Lisp. Для людей, которые не знают Lisp и НЕ рассматривают возможность его использования, они определенно не имеют абсолютно никакого эффекта.

Большинство авторов этих статей, кажется, серьезно думают, что каким-то образом они будут серьезно восприняты участниками Lisp-сообщества, и что эти участники осознают свои ошибки и начнут предоставлять высококачественные библиотеки для веб-программирования и синтаксического анализа XML бесплатно и сразу. Я не думаю, что это случится. Чтобы понять, почему, мы можем (для этой цели) разделить членов "сообщества Lisp" на три типа людей:

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

тех, кто не имеет возможности писать такие библиотеки. (из-за недостатка знаний, энергии или времени), и

тех, у кого есть возможность сделать это, но они не делают этого.

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

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

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

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

На Autodesk University 2020 (да и не только там, если честно) постоянно упоминают про VSCode с дополнением от Autodesk для разработки, отладки и т.д. Естественно, я говорю про LISP.

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

Ну, понятно, что нормально тестировать можно только на ACAD2021 (хотя в принципе использовать VSCode как текстовый редактор никто не мешает и в более ранних версиях). В принципе, весьма и весьма достойный редактор - с возможностью сворачивания кусков кода (по определенным правилам, конечно же), быстрого форматирования кода независимо от его размера и т.д. Но - только как редактор. В некоторых случаях Notepad++ может оказаться более функциональным и модульным.

Ну да ладно, вернусь к ACAD2021, VSCode и LISP.

В 2021 появилась новая системная переменная LISPSYS. Частично я про эту переменную говорил здесь.

Немного настроим VSCode и расширение.

Ок, запускаем ACAD, LISPSYS устанавливаем в 1, перезапуск. В ком.строку vlide, открывается VSCode. Ну, ок. Печатаем код наподобие

В меню Выполнить - Начать отладку (Run - Start debugging). Так, ок, перешли в DEBUG CONSOLE вместо ожидаемого acad.exe? Ну ок, жмем (t1):

Аналогичная ситуация будет и при попытке вызвать (t1) из ком.строки ACAD'a. То есть вариант "сделать какую-то функцию на лету, тут же ее запустить" как-то немного пропадает. А лично я при разработке / тестировании нередко подобным пользовался.

То есть получается, что надо файл а) сохранить и б) обеспечить его загрузку в acad (тут уже есть варианты - можно через _.appload в acad, можно через VSCode: правый клик - "Load File into AutoCAD")? VLIDE vs VSCode+ALISP - 1:0 в пользу VLIDE. Кстати, загрузить несохраненный код в acad подобным образом пока невозможно.

Естественно, что после загрузки функция становится доступной. А что будет, если установить точку останова на alert? Правильно, ничего! Надо под VSCode еще и отладку запустить, "присоединившись" (Attach) к процессу acad! Тогда точка останова сработает. В принципе, несложно нажать F5 для начала отладки и Shift+F5 для остановки отладки, но сам факт. Ладно, допустим, я просто привык к другому положению, поэтому в этом раунде обе среды получают по 0 баллов. 1:0

Немного усложним код - вместо t1 поставим testfunction1:

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

Эммм. А где подсказка-то? Ок, попробуем по-другому:

Ага, значит, все-таки как-то да срабатывает!

А что будет, если вместо testfunction1 поставить test-function ?

И это уже более печально: знаки "-" распознаваться отказываются (ни Ctrl+Space, ни Ctrl+Shift+Space не работают!). А у меня несколько проектов построены с применением моих функций, в названии которых есть "-". И что мне теперь делать? Все переписывать?? 2:0 в пользу VLIDE.

Я пока не знаю, как выполнять контроль кода в VSCode (ну там, использование глобальных переменных, сколько функций и с каким количеством параметров объявлено и т.д.). Искренне надеюсь, что это можно там сделать. Но верится с трудом Пока 2:0

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

Че?! Э, але! Внесение изменений в код "на лету" (и иногда даже без сохранения изменений) - это же основная фишка лиспа! 3:0 в пользу VLIDE (хотя очень сильно хочется поставить не 1 балл, а все 10. )

Ладно, а как там с форматированием и чтением настроек форматирования напрямую из lsp-файла? А никак! Что установлено в настройках расширения - то и будет. Кому-то это плюс, кому-то минус. Да и настроек форматирования значительно меньше, чем в VLIDE. Ситуация неоднозначная с моей точки зрения, так что ставим по 1 баллу обоим: 4:1 в пользу VLIDE.

В VSCode + ALISP есть одна очень интересная особенность - сворачивание кода. Можно свернуть содержимое определения функции, или содержимое cond, или if, или. Короче, любой логической конструкции. Правда, оно не сильно доведено до ума, ну да ладно. 4:2 в пользу VLIDE.

А вот теперь мое самое любимое. Диалоги. Разработка, проверка работы, проверка разметки.

Оно и во VLIDE-то не особо хорошо работало, а как здесь? А никак! dcl, в отличие от lsp, напрямую загрузить в acad невозможно. Просмотреть, как будет выглядеть окошко - из-под VSCode мне не удалось. Проверить правильность кода - тоже. Не, я понимаю - можно на WinForms / WPF нарисовать окошко, прописать его вызов, все дела. Но, блин, что мне делать, если в уже работающее окно dcl надо внести какие-либо изменения?! VLIDE хоть что-то предоставляет! Да, кривое, косое, недоработанное. Но VSCode и этого лишает! 5:2

Вопросы компиляци fas / vlx просто не затрагиваю.

Вопросы с кодировкой создаваемых файлов lsp тоже не трогаю.

И тем не менее, по моему кривому, косому, неправильному мнению в части разработки на AutoLISP / VisualLISP : VLIDE пока что сильнее как минимум в 2.5 раза по отношению к VSCode + Lisp Extension (от Autodesk). Может быть, есть другие расширения, более функциональные и вменяемые? С удовольствием обсужу их

Методы разработки приложений под AutoCAD с использованием DCL

Начиная с версии 12 AutoCAD предусматривает возможность самостоятельного написания диалоговых окон, отличных от определенных в системе. Для этой цели был разработан специальный язык - DCL (Dialogue Control Language, или другими словами - язык управления диалоговыми окнами). Следует отметить, что Autodesk свято как правило свято придерживается принципов совместимости своих программных стандартов, и при пререходе на Windows-версию AutoCAD, язык DCL не притерпел никаких серьезных изменений, и приложения написанные для AutoCAD R12 (DOS) работают и под AutoCAD R14 (Windows), равно как и под всеми последующими версиями AutoCAD.

DCL Code Generator

DCL Code Generator v.1.01

Не смотря на то, что версия 1.01 рассчитана на AutoCAD R12, она вполне нормально (спасибо Autolisp) работает и под AutoCAD R14, AutoCAD 2000 и последующими версиями AutoCAD. Недостает только новых функций DCL (а таковых не много - text_part, concatination и paragraph) и возможности загрузить DCL-файл - здесь используется WCEDIT (exp-приложение для AutoCAD R12 DOS). Справка к DCL Code Generator переведена мною в WinHelp формат и включена в комплект, который можно скачать ниже.

В настоящее время поддержка данной программы прекращена разработчиком. В сети так же можно встретить версию DCL Code Generator 2.0 , но это урезаная DEMO-версия без возможности сохранения созданных диалогов.

Protobox

Еще один редактор DCL-файлов, работающий внутри AutoCAD. Реализован в двух вариантах - как приложение Autolisp (PBmain.lsp), и Visual Lisp-приложение (PBmain.vlx), добавлена поддержка новых функций DCL, можно создавать и редактировать свои DCL-обьекты (Прототипы) а так же подсистемы (к примеру указывать позволяет работать с несколькими блоками как с одним). Кроме этого приложение может генерировать загружающий DCL файл на Lisp или С, а так же записывать файл с перечнем диалогов, их имен, ключевых слов и меток.

Рис. 2. Protobox v.2.2

К сожалению версия 2.2 не может загружать уже созданные DCL-файлы (на выбор предлагается загрузить example.dcl, DDMODES.DCL и DDCHPROP.DCL, но я подозреваю, что они включены в исходный код редактора).

DCL&Lisp Generator

В отличии от встроенной в AutoCAD среды разработки VisualLisp IDE, которая поддерживает создание файлов диалоговых окон DCL в текстовом редакторе, DCL&Lisp Generator осуществляет визуальное создание диалогов подобно как в среде разработки Visual Basic. После создания диалога достаточно нажать на кнопку "Generate" чтобы программа автоматически сгенерировала файл определения диалога и код AutoLisp для загрузки диалога в AutoCAD. Кроме этого DCL&Lisp Generator осуществляет помощь пользователю в назначении обработчика событий и переменных для компонентов диалога. Сильной стороной программы так же является удобный редактор AutoLisp и DCL файлов, содержащий много общих AutoLisp-подпрограмм, размещенных на панели инструментов, что поможет разработчику писать код быстрее.

DCL&Lisp Generator может работать под всеми версиями AutoCAD, начиная с AutoCAD 12.

Рис. 4. DCL&Lisp Generator

Полнофункциональную облегченную версию DCL&AutoLisp Generator Lite можно скачать с сайта разработчика.

В отличии от полной версии DCL&AutoLisp Generator имеет следующие ограничения:
вы не можете создавать диалоги со столбцами, строками группами переключателей и списками изображений (ImageList).
Панель инструментов позволяет вставлять код AutoLisp только для функций getpoint и drawline.
не поддерживается опция Drawing2Lisp, которая позволяет конвертировать чертежные примитивы из чертежа AutoCAD в код AutoLisp.

ObjectDCL

разработчик изначально 3rd Day Software, теперь DuctiSoft Inc.

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

Посудите сами. Все виды диалогов применительно к AutoCAD можно разделить на четыре группы:

Modal - эти диалоги поддерживаются стандартным DCL. Пользователь не может выполнить никакой операции в AutoCAD до закрытия диалогового окна.
Modeless - В этом случае пользователь может выполнять операции в AutoCAD, но диалоговое окно будет оставаться на экране и ждать пользовательского ввода (как плавающая панель инструментов).
Dockable - диалог, который можно разместить на панели AutoCAD.
Configuration Tab - позволяет пользователю создавать собственную панель в диалоге настройки AutoCAD.

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

Новым так же является подход к программированию диалоговых окон. В ObjectDCL диалоги программируются в соответствии с принципами визуального программирования ( т. е. так как в Delphi или Visual C++ ), о чем наглядно говорит даже сам вид редактора ObjectDCL, напоминающий редакторы языков визуального программирования. Элементы перетаскиваются на рабочее поле с левой панели, а на правой панели отображаются их свойства.

Label - аналог директивы Text в DCL
TextButton - аналог директивы Button в DCL
GraphicButton - отображает bmp,ico или jpg-файл
Frame - аналог директивы BoxedRow и BoxedColumn в DCL
TextBox - аналог директивы Edit_box в DCL
CheckBox - аналог директивы Toggle в DCL
OptionButton - аналог директивы Radio_Button в DCL
ComboBox - аналог директивы Popup_list в DCL
ListBox - аналог директивы List_box в DCL
ScrollBar - аналог директивы Slider в DCL
SliderBar - развите ScrollBar, более удобно позволяет указать с помощью мыши числовое значение.
PictureBox - отображение рисунка предопределенного пользователем при создании диалога.
TabControl - отображение таблиц (типа картотечных закладок)
MonthPicker - календарь
TreeControl - отображает древовидные структуры
Rectangle - декоративный элемент в виде прямоугольника
ProgressBar - отображает визуально время оставшееся до завершения выполнения операции
SpinButton - используется совместно с TextBox
UrlLink - ссылка на URL в диалоговом окне
AngleSlider - отображает выбранный угол в градусах
BlockView - позволяет отображать блоки, встроенные в текущий чертеж
SlideView - эквивалент Image и Image_button в DCL

Теперь о том, как это работает:
ObjectDCL состоит из двух частей - визуального редактора (приложения Windows) и загрузчика ObjectDCL ARX-runtime, который позволяет загружать скомпилированные диалоговые окна (файлы с расширением ODC). Редактор предназначен только для создания диалогов, а загрузчик должен быть в каждой системе, где эти диалоги должны работать.

Рис. 4. Среда разработки ObjectDCL

В настоящий момент ObjectDCL поддерживает AutoCAD 2004-2008, включая AutoCAD 2008 64-битный. Последняя версия ObjectDCL 2007 также включает ObjectDCL Distribution Kit - аналог загрузчика ObjectDCL.arx для распространения вместе с программами, разработанными с помощью ObjectDCL

OpenDCL

В 2006 году Chad Wanless, владелец 3rd Day Software, открыл код своего программного продукта ObjectDCL 3.0 на условиях GNU-лицензии. Таким образом OpenDCL является результатом серьезной переработки кода ObjectDCL 3.0 сообществом разработчиков, которые исправили существовавшие баги, добавили новые возможности и внесли множество изменений.

В настоящий момент доступен OpenDCL версии 5.0, который поддерживает создание визуального пользовательского интерфейса для AutoLISP и Visual LISP в версиях AutoCAD от 2004 до 2008. Как и ObjectDCL, OpenDCL состоит из редактора и ObjectARX-приложения (runtime). Редактор позволяет вам создавать и модифицировать проекты диалогов и сохранять их в .odcl (или .odcl.lsp) файлы для распространения вместе с вашими AutoLISP или Visual LISP приложениями. ObjectARX-приложение (OpenDCL.16.arx или OpenDCL.17.arx файл) так же должно распространяться вместе с вашим приложением и загружаться в AutoCAD чтобы отображать диалоги, определенные .odcl (или .odcl.lsp) файлами.

Рис. 5. Среда разработки OpenDCL

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