[TwoZero]

Здравствуйте,

Есть проблема с созданием диалоговых окон под AutoCAD,
стандартный язык для создания диалогов DCL негодится так как он очень скупой и там нет компонента TreeView, создание приложения на VBA тоже негодится так как программу пишу на ЛИСПЕ (ЛИСП РУЛИТ),
создание диалоговых окон в VB6 как ActiveX dll тоже негодится так как в дальнейшем требуется регистрировать библиотеки и если подключать дополнительные компоненты в VB6 то их придется таскать с сабой (я конечно понимаю что есть программы которые могут все запихать в один файл но такое мазуто мне ненадо), можно написать приложение на Delphi но оно будет как бы отдельное (можно конечно прописать макрос в акаде на запуск этого приложения но мне это неочень подходит так как хотелось бы чтоб все было интегрировано в акад).

Собственно проблема заключается в создании самих диалогов для AutoCAD, есть еще ObjectDCL но он платный и он перестает работать после триала.

Мож кто подскажет есть ли еще какиенить проги для создания диалогов под акад (нужен компонент TreeView).

[Disney]

Сообщение от romabrew Edit Box ов может быть один а может сто в различных случаях

А заполнить надо будет всё равно один или все сто?

[romabrew]

Да, все сто и получить список размеров. Подразумевается, что в каждом edit box имеется значение по умолчанию и сто раз вводить числа не придется. Вообще я сейчас копаю в сторону дот нет. Там такое сделать можно, только вот не соображу пока как.

[Сергей812]

А почему не хотите, действительно, сделать DCL окошко на 10 полей ввода, а потом просто вызывать нужное количество раз, вверху писать типа "21-30" и вызывать нужное количество раз. В дотнете пользователь тоже "замахается" вводить 100 значений подряд - неужели все значения одинаковы по смыслу или есть какие то группы?

[Alan]

Сообщение от Сергей812 сделать DCL окошко на 10 полей ввода, а потом просто вызывать нужное количество раз, вверху писать типа "21-30" и вызывать нужное количество раз.

Вроде в этой теме да и в других решили, что DCL - это громадный шаг назад

[romabrew]

Сообщение от Сергей812 А почему не хотите, действительно, сделать DCL окошко на 10 полей ввода, а потом просто вызывать нужное количество раз, вверху писать типа "21-30" и вызывать нужное количество раз. В дотнете пользователь тоже "замахается" вводить 100 значений подряд - неужели все значения одинаковы по смыслу или есть какие то группы?

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

[Сергей812]

Сообщение от romabrew А несколько окон делать несолидно как то получится

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

----- добавлено через ~20 мин. -----

Сообщение от romabrew Там такое сделать можно, только вот не соображу пока как.

Ну смотря на чем писать будете диалоги - если на WinForm, то можно использовать тот же TabControl. Если WPF - то там вообще принцип матрешки: элементы внутри контейнеров.

[Alan]

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

Ну для меня тоже это проще...
Написал их достаточное количество, поэтому небольшой опыт для сравнения с тем вариантом, что я показывал есть.
Одна диагностика введенной информации во внешней программе чего стоит!
Ну раз DCL для этого не случая не преступление, ваяй!
Вариантов размножения текст-боксов много, сам предлагал да и коллеги подсказывали.
Найди причинно-следственную связь ввода инфы, сделай контроль её ввода и тоже будет не плохо.
Я вот попытался выполнить с помощью DCL выполнить то окно ввода значений кол. и значений шагов.
Получилось ИМХО вполне компактно.

[ShaggyDoc]

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

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

[Alan]

Сообщение от ShaggyDoc Ну и другие визуальные компоненты для отображения данных, которые есть во всех системах разработки, но нет в DCL.

Пытался я >romabrew в п.106 и 127 объяснить это, он вроде загорелся.
Но!... получилось как у многих юзеров: "Я так привык!"

[romabrew]

Сообщение от Alan Я вот попытался выполнить с помощью DCL выполнить то окно ввода значений кол. и значений шагов. Получилось ИМХО вполне компактно.

Да, как вариант. Но все таки я уже направился в сторону .NET. Планирую так, из лисп-функции вызывается лисп-функция дотнетовская, которая возвратит значение в нужном виде. Что то типа такого:

Код:

[Выделить все]

 (defun q2 ()
  (command "_netload" "D:\\lispconnect.dll") ; в dll сборке имеется функция fun, которая описывает диалоговое окно и его поведение
  (setq pppv (fun)); в переменную pppv записывается результат выполнения
(princ)
)

с дотнет функцией, если сам не осилю, надеюсь добрые люди помогут.

Сообщение от ShaggyDoc Использование связей таблиц "master-detail" легко позволяет организовать любую иерархию информации.

можно поподробней?

[Кулик Алексей aka kpblc]

Поподробнее - это практически любое руководство по любой СУБД: таблицы, связи типа "один-к одному" / "один-ко многим" / "многие-ко многим", запросы, отчеты и т.п. Добро пожаловать в мир SQL

[Сергей812]

И если уж решили переходить на Net - то подумайте, стоит ли тащить за собой основную программу на lisp. Поддержка взаимодействия между старым lisp кодом и внедряемыми net-функциями может оказаться "дороже", чем переписать код. Благо "дружелюбность" редактора той же Visual Studio Express в несколько раз повышает скорость написания кода.

[ShaggyDoc]

Сообщение от Кулик Алексей aka kpblc Поподробнее - это практически любое руководство по любой СУБД: таблицы, связи типа "один-к одному" / "один-ко многим" / "многие-ко многим", запросы, отчеты и т.п. Добро пожаловать в мир SQL

Ну, так можно вообще перепугать Одно "Введение в SQL" 1160 страниц.
На самом деле для начала всё гораздо проще, тем более что в современных средах программирования значительная часть кода делается автоматом, а сложнейший функционал просто спрятан в компонентах.

А примером того, как не надо делать является весьма популярная на форуме программа «Прокат» Василия Кондрата. Она делает простые, но учень нужные всем вещи - разрезы прокатных профилей. Потому и популярна. Но организована безобразно. Но замечу, что претензий к автору нет - когда-то, где-нибудь в AutoCAD R10 (т.е. 25 лет назад) делать можно было если не совсем так, то примерно так - не было инструментальных средств. Хотя и тогда можно было использовать БД.

1. Для такой программы нужны данные - размеры профилей, которые бывают разных видов (уголки, двутавры и т.д.). Причем возможно появление новых видов. У Кондрата данные хранятся в текстовых dat-файлах в виде ЛИСП-списков, наподобие

Код:

[Выделить все]

 ("10Б1" "12Б1" "12Б2" "14Б1" "14Б2" "16Б1" "16Б2" "18Б1" "18Б2" "20Б1" "23Б1" "26Б1" "26Б2" "30Б1" "30Б2" "35Б1" "35Б2" "40Б1" "40Б2" "45Б1" "45Б2" "50Б1" "50Б2" "55Б1" "55Б2" "60Б1" "60Б2" "70Б1" "70Б2" "80Б1" "80Б2" "90Б1" "90Б2" "100Б1" "100Б2" "100Б3" "100Б4" "20Ш1" "23Ш1" "26Ш1" "26Ш2" "30Ш1" "30Ш2" "30Ш3" "35Ш1" "35Ш2" "35Ш3" "40Ш1" "40Ш2" "40Ш3" "50Ш1" "50Ш2" "50Ш3" "50Ш4" "60Ш1" "60Ш2" "60Ш3" "60Ш4" "70Ш1" "70Ш2" "70Ш3" "70Ш4" "70Ш5" "20К1" "20К2" "23К1" "23К2" "26К1" "26К2" "26К3" "30К1" "30К2" "30К3" "35К1" "35К2" "35К3" "40К1" "40К2" "40К3" "40К4" "40К5" "24ДБ1" "27ДБ1" "36ДБ1" "35ДБ1" "40ДБ1" "45ДБ1" "45ДБ2" "30ДШ1" "40ДШ1" "50ДШ1")
("0" 100.0 55.0 5.7 94.3 4.1 0.0 7.0 0.0 ("G = 8,1 кг" "h = 100 мм" "b = 55 мм" "s = 4,1 мм" "t = 5,7 мм" "R = 7,0 мм" "r 1 мм max" "A = 10,32 см2" "Jx = 171 см4" "Wx = 34,2 см3" "ix = 4,07 см" "Sx = 19,7 см3" "Jy = 15,9 см4" "Wy = 5,8 см3" "iy = 1,24 см"))
...
("90" 496.2 303.8 21.0 475.2 14.2 0.0 26.0 0.0 ("G = 155,0 кг" "h = 496,2 мм" "b = 303,8 мм" "s = 14,2 мм" "t = 21,0 мм" "R = 26,0 мм" "r 3,0 мм max" "A = 198,00 см2" "Jx = 86010 см4" "Wx = 3470,0 см3" "ix = 20,80 см" "Sx = 1950,0 см3" "Jy = 9830,0 см4" "Wy = 647,0 см3" "iy = 7,05 см"))

Таких файлов имеется 18 штук. Что в них написано, кто знает? Конечно, разобраться можно, но с трудом. А как их редактировать? Можно, конечно, но вероятность ошибок очень велика.

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

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

4. Еще нужны и иллюстрации к профилям. Они сделаны в виде "слайдов" (которые еще надо сделать) и помещены в библиотеку (которую надо собрать). Надо еще программно и безошибочно показать нужный слайд.

Ну и так далее. А как можно было бы сделать:

1. Создать файл базы данных, например формата MDB от MS Access. С помощью самой Access создать несколько таблиц:
а)Виды проката с полями ID, NAME, IMAGE, NOTE и LISP. В поле ID - уникальный номер, NAME - название вида профиля, NOTE - какое-нибудь длинное описание, IMAGE - растровая картинка, а LISP - имя функции рисования.

б) Профили для каждого вида проката с его данными. Теми, которые необходимы и для рисования сечений и для разных расчетов. При этом не дублировать информацию, т.е. не писать в одном поле число 55.0, а в другом поле "b = 55 мм". Немного пошевелив мозгами можно придумать и единую структуру данных для всех видов проката, т.е. значительно упростить работу.

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

Здесь самое главное, что для работы с данными можно использовать компоненты классов TDataSet и TDataSource, а для отображения и редактирования данных - любые визуальные компоненты, связываемые с DataSource - навигаторы, сетки, деревья, отдельные поля. Программа сразу умеет двигаться по данным, безошибочно их редактировать, искать, фильтровать и многое другое. Не надо писать ни строчки кода.

3. Такой "диалог" запускается из LISP-программы известными способами. При выборе нужного профиля диалог закрывается, а в LISP возвращается имя функции рисования и список данных. Lisp, благодаря своим фундаментальным возможностям, выполняет функцию с заданным именем и с переданными данными. Разумеется, такая функция в этот момент должна быть определена, например в библиотеке.

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

Освоение таких технологий даст безграничные возможности. А время на это надо будет потратить меньше, чем на мучения с ублюдочным DCL. Его время закончилось одновременно с появлением еще Windows-95.

[Сергей812]

Сообщение от ShaggyDoc 1. Создать файл базы данных, например формата MDB от MS Access. С помощью самой Access создать несколько таблиц:

На Access часто экономят при покупке офиса. Наглядный пример - одна российская фирма (имени называть не буду во избежание рекламы) выпустила для продвижения своей продукции расчетную программу для расстановки оборудования. И, не долго думая, влепили БД на Аccess. Прошел год - и вышла новая версия программы, которая для своей работы уже не требовала Access - т.е. к ним поступила далеко не единичное замечание от пользователей по этому поводу. Иначе они бы и не "чесались")

[ShaggyDoc]

Сообщение от Сергей812 На Access часто экономят при покупке офиса. Наглядный пример - одна российская фирма (имени называть не буду во избежание рекламы) выпустила для продвижения своей продукции расчетную программу для расстановки оборудования. И, не долго думая, влепили БД на Аccess. Прошел год - и вышла новая версия программы, которая для своей работы уже не требовала Access - т.е. к ним поступила далеко не единичное замечание от пользователей по этому поводу. Иначе они бы и не "чесались")

Для использования в программах базы данных в формате Access, т.е. MDB сама программа MS Access совершенно не обязательна. Я просто упомянул её как инструмент для создания структуры БД, да и то для начинающих. Причем инструмент самый неудобный, но "с кнопками". Зато у неё нет окна для прямого ввода и выполнения SQL, что замедляет работу в десятки раз.

Для работы необходим "движок" Jet, который распространяется Microsoft бесплатно. Но и это только если захочется работать с БД через механизмы ADO. Например, чтобы прямо из LISP выполнить SQL-запрос и получить данные вообще без лишних посредников. Но можно и работать через компоненты прямого доступа к MDB.

Вообще-то есть разные локальные БД, в том числе гораздо быстрее и удобнее MDB. Я, например, использую Absolute Database - она просто встраивается в программу, не имеет никаких "движков", DLL, хранит любые виды данных и полностью совместима с SQL. Но это уже вопросы религии - кто "продал душу дьяволу" (т.е. Microsoft) на такое пойтить не может.

[Сергей812]

Сообщение от ShaggyDoc Я, например, использую Absolute Database

Если имеется в виду эта БД, то там есть

An individual may use Absolute Database Personal in a project if he / she is the only user of this project. If your project is public or if you represent a company, you must order commercial edition of Absolute Database.

[ShaggyDoc]

Если имеется в виду эта БД, то там есть

Ну так и покупаю. Делов-то. Зато имеются все исходники и работа многократно упрощается. Но есть и другие СУБД, бесплатные. Например Firebird, который может быть и сервером, и "embedded", т.е. локальной СУБД. Есть SQLite - для всех платформ.
А для большинства MDB подойдет. Только надо с умом использовать, и применять более удобные инструменты разработчика, которые тоже имеются бесплатные.

[trir]

Зато у неё нет окна для прямого ввода и выполнения SQL

есть

[ShaggyDoc]

Сообщение от trir есть

А ну-ка скриншот. Может быть в какой-то последней версии. Только не надо путать конструктор SQL-запроса, из которого можно потом скопировать выражение (это есть) с обычным окном текстового редактора, в который можно вписать что угодно и выполнить.

Вот такое окно - непременный элемент всех (кроме Access) программ класса "database desktop". Именно с его помощью можно делать любые "чудеса" с базами данных.

А MS Access - программа для "конечных" пользователей, и, по мнению Microsoft, им это не надо. Пусть, мол, кнопки жмут, да "мастерами" пользуются. А еще и создает в MDB кучу ненужных служебных таблиц, раздувающих базу. Потому сторонние программисты и пишут множество заменителей Access.

[trir]

Кажется всегда был "Режим SQL" (в 2003 точно), в нём можно создавать хранимые процедуры и скрипты (создание таблиц с индексами и т. п.)
Хотя сделать можно и не всё...