[gash90]

Добрый день. Необходимо написать программу, работающую с AutoCad и обладающую следующими функциями:

- Создание и сохранение блоков (модулей), состоящих из различных примитивов (треугольники, многоугольники, криволинейные элементы), в каком-либо удобном для работы виде, в том числе, возможно, со связью с базой MySQL.
- Выбор этих блоков в основной программе, выделение отдельных примитивов и связывание этих примитивов с определенными объектами (допустим большинство примитивов из модулей необходимо сопоставить с прямоугольниками определенных размеров и расположить эти примитивы на прямоугольнике исходя из каких-либо заданных условий). Привел пример во вложениях. Также надо привязать эти прямоугольники к определенным записям в базе MySQL для дальнейших просчетов.
-Разнообразный просчет блоков (а точнее примитивов в блоке: отходная часть в кв.м., длины реза и т.д. с анализом внутренних линий (примитивов) в прямоугольнике). А также просчет разных экономических составляющих, пользуясь базой MySQL.
- Загрузка различных помещений, состоящих из блоков (модулей) и других объектов (в большинстве своем полилиний) и просчет этих помещений, как в предыдущем пункте.

Работал с MySQL из Delphi. Сейчас изучаю C++, все в комплекте CodeGear RAD Studio. В чем лучше все это дело писать? Обязателен ли LISP, или есть другие более удачные способы (допустим нужен ли Object ARX с C++ или ActiveX с Delphi). Какого функционала в связи с этим хватит (насколько знаю в Object ARX можно создавать собственные объекты, поля, свойства и методы). Какая литература подойдет? Есть "САПР на базе AutoCad - как это делается" и "AutoCad 2004 Наиболее полное руководство" Н.Н. Полещука. Сколько времени понадобиться на полное изучение программирования с AutoCad'ом и изначально на создание такой вот программы.

[dvim]

Имхо
АRX это очень мощно, но сложно и трудоемко.
Остается 3 решения

- Лисп
- Дельфи +COM
- NET

Для задач создания именно приложения (интерефейсов) и активной связи с СУБД последний вариант (имхо) предпочтительней.

Из минусов по объектной net-модели автокада мало документации (http://through-the-interface.typepad.com сей блог есть главный источник)
Из + - все остальное.

[gash90]

А что-нибудь по-конкретней? Допустим какие книги, кроме перечисленных, достаточно широко освещают процесс создания подобной программы? Как лучше организовать блоки, создавать отдельные объекты или воспользоваться тем что есть? Достаточно ли функционала для описанных выше операций?

[dvim]

Если говорить про .Net

"Также надо привязать эти прямоугольники к определенным записям в базе MySQL для дальнейших просчетов." - фактически просто можно id entity автокада записать в БД, либо в самом прямоугольнике хранить данные о "сопровождающей" записи.

"Разнообразный просчет блоков (а точнее примитивов в блоке: отходная часть в кв.м., длины реза и т.д. с анализом внутренних линий (примитивов) в прямоугольнике)." - в принципе вы сможете получить массив с координатами линий в вашем блоке.
Далее пишите свою геометрию. Это технически возможно, но считать геометрию сложно. (отвлекитесь от када, представте что у вас есть координаты линий и прямоугольников и напишите алгоритм по вычислению отходной части...)

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

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

что читать ? по .Net книг полно. Про кад + .Net есть названный мной сайт + техдокументация автодеска.
Нормальной литературы нет.


Ps
Про создание отдельных объектов - это к ObectARX
Смотрел сию технологию 2 лет назад . Понял, что при всей ее мощности я не могу "окупить" такую трудоемкость.

[gash90]

А реализацию в LISP возможно сделать без применения .NET? Или, допустим, в делфях с ActiveX создать сервер автоматизации и работу программы связать с ним? А если все же в .NET, то на чем писать (VB или С#)?

P.S. Какое время понадобиться для освоения сред и написания программы. Умею работать в Delphi, знаком с VB и C++, осваиваю VLISP.

[ShaggyDoc]

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

При постановке определитесь с основными вопросами:

1. Зачем вообще вам нужна база данных. И нужна ли вообще? Надо ли в базе данных хранить "блоки"? Что это за блоки (модули)? Это "блок" в терминологии Автокада, т.е. по сути двоичный DWG, каким-то образом затолканный в таблицу БД? А может быть достаточно хранить в БД координаты этих самых "треугольники, многоугольники"?

2. Что должно делаться внутри AutoCAD? Например, рисование этих "многоугольников".

3. Какая именно должна быть работа с БД, например в её визуальной части. А может такая работа и не нужна?

4. Почему именно MySQL? Это замечательная СУБД но для своего применения, например в Интернет. А для десктопных программ не самый лучший выбор...

Продумав основные вопросы сразу увидите и возможную реализацию. Например, если важна визуальная часть работы с БД, тут, возможно, лучше использовать Delphi - там есть такие библиотеки, которых в .NET и не бывало. А если не важно - можно на чем угодно делать.

Определитесь, где должна основная часть работы происходить. Скорее всего, внутри AutoCAD, а это значит - LISP и вызов из него COM-серверов или .NET-сборок. Это уж кому как удобнее... Но, скорее всего, чем-то одним не обойтись.

Без четкой постановки никто вам конкретных советов не даст.

А если все же в .NET, то на чем писать (VB или С++)

Видимо .NET вы не знаете, раз такой вопрос. Значит придется изучать и тогда уж лучше работать с C#. Хотя можно и на Delphi и на Basic....

[gash90]

ShaggyDoc

Двоичные файлы никто не собирается в базу заталкивать, конечно. Я как раз и хочу понять, как лучше реализовать хранение этих блоков (вы как раз предлагаете хранение координат деталей, составляющих блок, как я понимаю). В целом, все что Вы написали, я как раз и хочу осуществить. С MySQL хочу работать, так как, возможно, потом доступ к базе будет с разных PC и с разными уровнями доступа. Как я себе представляю, работа с БД будет производиться не визуально (ну кроме может кнопки "отправить SQL-запрос"), зато работа с автокадом будет скорее всего либо через "рабочие окна" (с рисунком блока, различными компонентами для задания размеров деталей внутри блока или, допустим, задания связи деталей с размерами прямоугольников, которые могут храниться в БД, о которых я говорил) в самой программе (приложении, работающем с автокад), либо в самом автокаде (с использованием какого-либо интерфейса в отдельном окне, выполняющем приблизительно те же фнукции).

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

[VVA]

Добавлю к #6. Вполне может выяснится, что обычного LISP + ADOLISP_Library будет достаточно.
Управление MySQL из LISP
AutoLisp и база данных SQL-сервера
Как получить доступ к таблице Access
Подборка для работы с Базами Данных из Лиспа

[gash90]

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

1.1. Выбор блока из существующих (блок должен включать в себя какой-то рисунок, составленный из примитивов, допустим, каких-то стандартных размеров).
1.2. Задание характеристического размера блока (так как чаще всего это квадраты, то всего один размер). Размеры заданы в БД.
1.3. Задание связи элементов блока с прямоугольниками, выбираемыми в отдельном окне из стандартных (заданных) размеров. Размеры заданы в БД.
1.4. Оптимизация расположения примитивов на прямоугольнике из принципа уменьшения отходов, то есть уменьшения незадействованной площади прямоугольника. (привел экземплы в первом посте)
1.5. Просчет и вывод в окно или документ (файл, допустим) информации об используемом материале для создания одного блока, отходной части и длины реза элементов в прямоугольниках. Потом перемножив соответствующие числа на заданные в БД цены можно получить стоимость изготовления такого блока.

В более полном варианте:
2.1. Выбор помещения (допустим задав на чертеже точку внутри помещения и выбрав ближайший контур, как для штриховки).
2.2. Пункты 1.1. - 1.5.
2.3. Задание диапазона отступа от контура помещения для фриза (прямоугольников, с диапазоном размеров отступа и определенной шириной, выбираемой из стандартных (из БД), расположенных узкой стороной к контуру помещения, для получения внутреннего прямоугольника внутри помещения, кратного, за вычетом ширины обрамляющей рамки, размеру блока). В итоге, получим целое число блоков в этом внутреннем прямоугольнике.
2.4. Выбор ширины обрамляющей рамки из стандартных размеров (из БД) для прямоугольного массива блоков.
2.5. Вывод конечного помещения, заполненного блоками, обрамленных рамками и фризом. Вывод сопутствующей информации (площадь фриза, рамки, блоков, материала, потраченного на изготовление; общей длины резов внутри блоков; стоимости работ по изготовлению (цена на соответствующие геом. размеры).

[hwd]

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

В качестве "удобного вида" использую XML. Под связью с MySQL автор видимо подразумевает динамическую связь (т.е. изменилось в чертеже - изменение сразу стало доступно из MySQL) - в этом случае (насколько я знаю) придётся писать плагин, в котором обрабатываются события, через которые происходит синхронизация с БД.

Сообщение от gash90 - Выбор этих блоков в основной программе, выделение отдельных примитивов и связывание этих примитивов с определенными объектами (допустим большинство примитивов из модулей необходимо сопоставить с прямоугольниками определенных размеров и расположить эти примитивы на прямоугольнике исходя из каких-либо заданных условий). ... Также надо привязать эти прямоугольники к определенным записям в базе MySQL для дальнейших просчетов. -Разнообразный просчет блоков (а точнее примитивов в блоке: отходная часть в кв.м., длины реза и т.д. с анализом внутренних линий (примитивов) в прямоугольнике). А также просчет разных экономических составляющих, пользуясь базой MySQL. - Загрузка различных помещений, состоящих из блоков (модулей) и других объектов (в большинстве своем полилиний) и просчет этих помещений, как в предыдущем пункте.

Подобную привязку можно реализовывать с помощью расширенных данных, в которых хранить уникальные ключи (например GUID), если опасаетесь использовать родные "хэндлы" (я на практике не раз сталкивался с тем, что в чертеже попадались объекты с одинаковыми "хэндлами").
Если говорить применительно к .Net, то используя LINQ можно манипулировать объектами базы данных чертежа почти так же, как это делается в базе данных (я именно так и делаю).

2 ShaggyDoc

возможно, лучше использовать Delphi - там есть такие библиотеки, которых в .NET и не бывало

Например?
2 gash90

Двоичные файлы никто не собирается в базу заталкивать, конечно. Я как раз и хочу понять, как лучше реализовать хранение этих блоков

Если речь о сериализации определений блоков с тем, чтобы хранить их в записях таблиц БД - то тут ничего не получится, т.к. классы не помечены атрибутом Serializable. Попытка наследования с последующей реализацией оного атрибута положительного результата так же не даст.

[gash90]

hwd

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

[ShaggyDoc]

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

Все это делается в LISP. Возможно с использованием указанного в #8.
Само заполнение БД как будет? Тут без "визуализации" не обойтись. А как будет "выбор из существующих"? Тут тоже нужна визуализация, причем желательно с иллюстрациями.

С MySQL хочу работать, так как, возможно, потом доступ к базе будет с разных PC и с разными уровнями доступа

Для этого не нужен MySQL. Если уж думать о гипотетической перспективе перехода в будущем на клиент-сервер, то лучше ориентироваться на системы, позволяющие легко перейти от локальной БД к клиент-серверной. Firebird, MSSQL, даже Access. А с MySQL придется разворачивать локальный сервер.

Да и вообще все можно реализовать в XML. А уж сами "секретные блоки" хоть на удаленном сервере с разделением доступа хранить.

Вообще "настоящая" БД для хранения такого ничтожного ассортимента (несколько сотен или несколько тысяч) сомнительное решение.

Например?

Например, Developer Express, Info Power, FastReport или хотя бы EhLib

[hwd]

Сообщение от ShaggyDoc Например, Developer Express, Info Power, FastReport или хотя бы EhLib

Неправда.
На .Net полно аналогичных решений, и не просто аналогичных, но порой и более удобных:
1. Developer Express существует не только для делфи но и для .Net: Developer Express. Кроме того, WPF позволяет разработчикам легко и быстро создавать свои контролы любого уровня сложности (насколько хватит фантазии).

2. Вместо FastReport можно использовать FastReport.Net, но гораздо более мощным является линейка продукции StimulSoft.

3. Info Power - существуют аналоги как для winforms, так и для wpf (отдаю предпочтение последним). Возможности WPF не на одну голову выше, чем все существовавшие ранее технологии создания GUI.
4. EhLib - всё это можно делать и на Winforms/WPF. Причём на WPF это можно делать гораздо быстрее/красивее/функциональней.
5. Касательно работы с БД - не говоря уже про ADO.NET, скажу только одно слово - LINQ. Самая мощная технология, с помощью которой можно легко манипулировать любыми данными.

Offtop: п.с. ShaggyDoc, Ваши сведения о .Net безвозвратно устарели. (((

[gash90]

ShaggyDoc

Вы наверно несколько иное имели ввиду под визуализацией. Визуализация предполагается посредством самого AutoCad и компонент вызывающей программы. Сами запросы в БД ясное дело будут уже в коде (мб за исключением админской кнопки "отправить SQL-запрос", а визуальное оформление "ответов" БД будет уже после обработки выводиться кадом или программой. И оно включает естественно графическое оформление и интерактивный удобный пользовательский вид. Вообще предполагаю, что LISP с его огромным багажом функций позволит не привлекать особо другие программные средства, но с помощью SendCommand в принципе можно иметь выход и из Delphi в сам LISP без объектной модели посредством позднего связывания, что позволит получить доступ в БД из Delphi (у меня есть как раз пакет UniDac для удобства) и не терять функционала LISP'а (особенно в интерактивности его работы с AutoCad'ом при разных рабочих документах и т.п.). Клиент-сервер, в любом случае, планируется сразу при вводе в эксплуатацию, тем более с MySQL я работал, да и сама база небольшая, не знаю даже, чем СУБД Вам не нравится так. )

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

Offtop: ADOLisp вряд ли будет работать на 64-разрядных системах...

[gash90]

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

Рабочие системы в офисе еще на 32-х разрядниках сидят.

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

Мне нравится слово еще

[VVA]

Сообщение от Кулик Алексей aka kpblc Offtop: ADOLisp вряд ли будет работать на 64-разрядных системах...

Это можно утверждать положительно Так как по ссылке нужна регистрация, приведу цитату здесь

Сообщение от Kerry Brown because Microsoft have not released a 64 bit version of the Jet Driver ADO.LSP will not work in an AutoCAD 64bit System.

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

VVA, я краем уха слышал, что какие-то работы в этом направлении могут вестись (правда, неизвестно - силами MS или нет). Так что гарантировать неизменность ситуации я бы не стал.

[ShaggyDoc]

Неправда. На .Net полно аналогичных решений

Перечисленное далее создано для Delphi и портировано под .NET. В последних версиях Delphi можно делать .NET-приложения, вот и библиотеки (практически все от солидных фирм) можно использовать. Но это дополнительные компоненты, которых в ядре нет. Это дополнительная поставка. Работая из другой среды их не увидишь.

А смысл .NET в числе прочего и в том, чтобы иметь, независимо от языка программирования, единый набор "стандартных" решений.

Вы наверно несколько иное имели ввиду под визуализацией. Визуализация предполагается посредством самого AutoCad и компонент вызывающей программы. Сами запросы в БД ясное дело будут уже в коде (мб за исключением админской кнопки "отправить SQL-запрос", а визуальное оформление "ответов" БД будет уже после обработки выводиться кадом или программой.

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

В CAD важное значение имеет не только описание изделия или какого-то элемента, но и его внешний вид. Чем, например, внешне отличается изделие ХХХХХ-01 от ХХХХХ-02. Или как найти то, не знаю как называется, но знаю, как выглядит.

Соответственно и реализация БД должна быть (неважно, какая она физически).

Два примера на иллюстрациях:

1. Выбор пользователя из меню по картинке и описаниям. Структура может быть любая, размещено может быть где угодно - все в XML. А может быть и в БД. Результатом выбора является строка, которую можно интерпретировать как угодно. Это может быть и LISP-выражение и SQL-запрос к БД, и URL на удаленном сервере.

2. Окно программы ведения спецификаций - база любого оборудования. У каждого изделия имеются и все текстовые атрибуты, и иллюстрации, и паспорта (документация). Могут быть и ссылки на блоки. Все внешние файлы могут быть где угодно расположены.

Это автономное приложение, в нем можно полностью работать со спецификациями, включая вывод на печать в любой форме. Но, если это приложение запущено из-под AutoCAD (вернее из ruCAD, работающего в AutoCAD), то появляются дополнительные кнопки и пункты меню - Сосчитать (получить "количество" из чертежа) и Начертить (нарисовать объект в AutoCAD). Метод "рисования" содержится в БД.

Вот что я понимаю под "визуализацией". Кстати, БД спецификаций может быть любой - подключение идет через ADO. И есть вариант, где вся "БД" является файловой системой. Этим решается масса вопросов, связанных с наполнением базы из разных источников.

PS. На втором рисунке как раз использованы компоненты для работы с БД из Developer Express. Заодно еще пару-тройку иллюстраций приложу, для комплекта