| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |  Справка по форуму | Файлообменник |

Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Лучшая стратегия создания кастомного приложения

Лучшая стратегия создания кастомного приложения

Ответ
Поиск в этой теме
Непрочитано 06.01.2017, 23:48
Лучшая стратегия создания кастомного приложения
ETCartman
 
Регистрация: 09.12.2008
Сообщений: 4,649

Здравствуйте.
Есть задача автоматизировать процесс создания комплектов чертежей.
Инпут: перечень антенн + всякая другая типовая информация
Выход: типовой комплект чертежей.
Применяются антенны из базы данных (виды) которые должны быть вставлены в автокад.
Вопрос каким путем лучше всего сделать такое приложение.
С учетом того, что лисп знаю на уровне пользователя, С# не знаю и не хочу учить. Basic знаю, Pascal тоже.
Просмотров: 12563
 
Непрочитано 09.01.2017, 21:08
#21
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


Цитата:
Сообщение от ETCartman Посмотреть сообщение
Желательно чтобы автокад вообще не запускался, а обрабатывал данные в пакетном режиме и выплевывал чертежи в заданную папку.
Запуск акада в фоновом режиме или консольная версия акада? Насчет второго - надо еще проверить, поддерживает ли COM-интерфейс (не использовал).

Цитата:
Сообщение от ETCartman Посмотреть сообщение
Думаю насобирать примеров на эту тему
Примеров чего именно? Если программирования - то набираете в поисковике "VBA AutoCAD" и смотрите - по сути коды один в один, только вместо ThisDrawing будет переменная документа в коде VBA Excel.
Сергей812 вне форума  
 
Непрочитано 10.01.2017, 05:10
#22
Александр Ривилис

программист, рыцарь ObjectARX
 
Регистрация: 09.05.2005
Киев
Сообщений: 2,405
Отправить сообщение для Александр Ривилис с помощью Skype™


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
Запуск акада в фоновом режиме или консольная версия акада? Насчет второго - надо еще проверить, поддерживает ли COM-интерфейс (не использовал).
Точно не поддерживается. У консоли нет COM-интерфейса.
Александр Ривилис вне форума  
 
Непрочитано 10.01.2017, 06:58
#23
Владимир_М


 
Регистрация: 05.11.2015
Сообщений: 585


Цитата:
Сообщение от ETCartman Посмотреть сообщение
Я пытаюсь понять оптимальную стратегию, в целом.
По возможности программирование и принцип работы должен быть простым, чтобы с минимальными знаниями можно было это дело постоянно кастомизировать и править по мере надобности.
То есть категорически никакой ни С/С# с объектно-ориентированной структурой (которая требует наличия профессионального программиста, возни с разными библиотеками и компиляторами и прочим).
Delphi/Lazarus в данном случае тоже не очень хорошо. А вот Excel/VBA уже лучше.
Поскольку автокад сам по себе ценен как среда создания приложений, то раз уж предполагается его использование, лучше то что в нем уже есть.
Но нужно нечто другое, в чем собственно исходные данные в виде текста и цифр будут вводиться и храниться. Тут лучше всего наверно Excel + VBA (пока его не отменили)
Пока только Вы сами и можете определить, что для Вас может быть оптимальным. Текст и цифры могут вводится и храниться и в обычном текстовом файле и в файле базы данных и в файле Excel или даже в самом тексте программного кода. Все зависит от объема данных, от того как часто их редактировать придется, от того какова их структура, какие манипуляции предполагается с ними делать или какие между ними есть логические взаимосвязи.
Если вы определились, что это будет файл Excel, то закручивать его в какую-то единую систему с Автокадом (т.е. управлять объектной моделью из Excel) совсем не обязательно. Данные данными, а выполнение графической части отдельно может быть. Можно из файла Excel по мере необходимости (по нажатию кнопки, например) переходить в Acad и уже используя VBA Acad (или Лисп и проч.) выполнять графическую часть. Можно, как обычно, из самого Acad из его меню запустить приложение, которое возьмет нужную информацию из файла Excel. Можно, вообще, как пускалку использовать отдельный exe-файл, который будет управлять и Excel и Acad в любом порядке. Дело вкуса, к чему больше привыкли или что логичней с точки зрения объема выполняемой приложением работы. Вот зачем из макроса Excel создавать примитивы Acad? логики не вижу.
Цитата:
Сообщение от ETCartman Посмотреть сообщение
Желательно чтобы автокад вообще не запускался...
А в чем тут логика? Почему так не хочется сразу же и посмотреть чего же там приложение натворило? Потом же все равно открывать, наверное, печатать? Все не глядя? Визуальный первичный контроль хотя бы Вам сразу покажет, а все ли там было нормально введено в исходных данных задачки.
Владимир_М вне форума  
 
Непрочитано 10.01.2017, 07:49
#24
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от ETCartman Посмотреть сообщение
Кастомное приложение в принципе означает - есть комплект чертежей, схематических, довольно однообразных.
Нужна простая программа, которая дает возможность генерировать его быстро, без глупых ошибок (которые часто встречаются в простых чертежах методом правки)
По возможности программирование и принцип работы должен быть простым, чтобы с минимальными знаниями можно было это дело постоянно кастомизировать и править по мере надобности.
То есть категорически никакой ни С/С# с объектно-ориентированной структурой (которая требует наличия профессионального программиста, возни с разными библиотеками и компиляторами и прочим).
Delphi/Lazarus в данном случае тоже не очень хорошо. А вот Excel/VBA уже лучше.
Если не связываться с программированием - надо забыть про "кастомные приложения". К Excel/VBA "прилагается" ненавистная Windows.

А программирование под Автокад "без Автокада" - возврат к идеям 28-летней давности, описанным в книге Денниса Джампа AutoCAD. Программирование. Тогда Автокад еще не имел средств разработки (вернее, Джамп делал вид, что о них не знает).
И он описывал, как можно реализовать лозунг "Настоящие программисты используют DXF-файлы и только садисты работают с файлами чертежей - DWG-файлами).

А суть была в том, что писать кучу маленьких программок на C (даже не C++), которые берут данные из текстовых файлов и генерируют текстовые DXF. Да уж. Автор идеи и садист и мазохист одновременно. Если не сказать хуже. То, что можно было сделать уже тогда на Автолисп в несколько строк, предлагалось как раз делать "с разными библиотеками и компиляторами", причем многократно. По сути - создание себе рабочего места на много лет.

Но сейчас-то для разработки приложений для AutoCAD есть всё - и Lisp, и ObjectARX, и .NET, и VBA. Причем худшим выбором является именно VBA как средство написания кода, и Excel - как место хранения данных. Потому что в Excel запросто могут быть введены ошибочные данные (хотя бы по типу). Лучше уж в текстовом формате их хранить. Хотя все современные системы позволяют легко и надежно работать с базами данных любых видов.
ShaggyDoc вне форума  
 
Непрочитано 10.01.2017, 08:18
#25
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
<phrase 1=


Большую часть времени использовать linux, а склоняться к autocad+exel - это сильно))


>>Да уж. Автор идеи и садист и мазохист одновременно.
Вполне оправданный подход для простых случаев. Почему ктото должен для элементарных вещей покупать автокад?
>>По сути - создание себе рабочего места на много лет.
С другой стороны - создание рабочих мест манагерам и адвокатам автодеска)).
zamtmn вне форума  
 
Непрочитано 10.01.2017, 08:22
#26
baksconstructor


 
Регистрация: 05.11.2014
Сообщений: 978


Цитата:
Сообщение от zamtmn Посмотреть сообщение
С другой стороны - создание рабочих мест манагерам и адвокатам автодеска)).
У автора написано Texas, проблем по определению не будет.
baksconstructor вне форума  
 
Непрочитано 10.01.2017, 09:27
#27
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Вполне оправданный подход для простых случаев. Почему ктото должен для элементарных вещей покупать автокад?
А куда потом DXF девать? Он-то как раз для Автокада. И концепция назвалась "Программирование для AutoCAD", не для Paint.
Или простейший случай - что угодно, изображаемое в виде прямоугольника. Он может иметь разные размеры, исходную точку (центр, угол), поворот. Все это надо задать. Или каждый раз в файл записать, или в сторонней программе (только для прямоугольника) иметь варианты ввода. Потом сгенерировать этой программой DXF. Потом запустить Автокад и загрузить этот DXF. И так многократно. Кстати, тогда и диалога выбора фалов в Автокаде не было - надо было ввести вручную.

Да, очень простой случай.
ShaggyDoc вне форума  
 
Непрочитано 10.01.2017, 11:07
#28
trir


 
Регистрация: 18.12.2010
Сообщений: 5,047


python однозначно ;=)
ООП очень облегчает жизнь, а программировать на VBA - мазохизм
А самый простой и удобный формат для хранения - XML

Последний раз редактировалось trir, 10.01.2017 в 11:44.
trir вне форума  
 
Непрочитано 10.01.2017, 14:21
#29
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


Цитата:
Сообщение от trir Посмотреть сообщение
а программировать на VBA - мазохизм
редактор VBA - это мазохизм) И ООП в зачаточном состоянии есть и в VBA - классы, свойства, методы, публичные и приватные члены, конструкторы и деструкторы. Если написать в виде класса работу с акадом - то потом в основном коде красота: одна строчка - это создание объекта с одновременным подключением к акаду, вторая - уничтожение объекта с одновременным отключением от акада. А между ними вызовы методов из класса - делающие определенную работу в акаде. Для простых вещей вполне годная вещь и ускоряет работу. А дальше переходить на что-то более серьезное - Net, ObjectARX и т.д., если к тому времени интерес не пропадет (лисповцам просьба не обижаться - просто вы другая ветка эволюции программирования, редко кто сочетает продвинутый уровень как в лиспе, так и в "обычных" языках программирования).
Сергей812 вне форума  
 
Непрочитано 10.01.2017, 14:38
#30
Enik

ГИП
 
Регистрация: 07.06.2015
Сообщений: 1,254


Цитата:
Сообщение от Владимир_М Посмотреть сообщение
Текст и цифры могут вводится и храниться и в обычном текстовом файле и в файле базы данных и в файле Excel или даже в самом тексте программного кода.
Цитата:
Сообщение от Владимир_М Посмотреть сообщение
или даже в самом тексте программного кода.
А чё там у лиспа с массивами и индексацией элементов в них? Про списки не будем. Я изначально хотел для своих приблуд создавать базы/контейнеры прямо в коде лиспа. Потом передумал.
Enik вне форума  
 
Непрочитано 10.01.2017, 14:47
#31
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,004


Цитата:
Сообщение от Enik Посмотреть сообщение
А чё там у лиспа с массивами и индексацией элементов в них?
vlax-savearray-...
Сергей812 вне форума  
 
Непрочитано 10.01.2017, 14:59
#32
trir


 
Регистрация: 18.12.2010
Сообщений: 5,047


Цитата:
А чё там у лиспа с массивами и индексацией элементов в них?
просто надо реализовать бинарное дерево. Главная проблема lisp'а - всё надо писать самому. Для популярных языков можно найти готовые библиотеки
trir вне форума  
 
Непрочитано 10.01.2017, 16:14
#33
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от Enik Посмотреть сообщение
А чё там у лиспа с массивами и индексацией элементов в них? Про списки не будем. Я изначально хотел для своих приблуд создавать базы/контейнеры прямо в коде лиспа. Потом передумал.
"Массивы" для LISP просто не нужны, это "для измученных нарзаном бейсиком". Как раз про списки и "будем". И vlax-savearray-... самому LISP не нужен, это "костыли" для связи с объектами, которым нужны именно массивы.

Цитата:
Сообщение от trir Посмотреть сообщение
Главная проблема lisp'а - всё надо писать самому. Для популярных языков можно найти готовые библиотеки
"Можно найти" - это не значит, "они у меня есть и я умею ими пользоваться".

Но стратегически (такая тема ветки) AutoCAD позволяет писать приложения не только в "родных" для него средах программирования, но и в любых, которые умеют работать с COM. И это самое удобное. Вот там и используйте любые библиотеки, а также визуальные компоненты.
ShaggyDoc вне форума  
 
Непрочитано 10.01.2017, 16:50
#34
Владимир_М


 
Регистрация: 05.11.2015
Сообщений: 585


Цитата:
Сообщение от Enik Посмотреть сообщение
А чё там у лиспа с массивами и индексацией элементов в них? Про списки не будем. Я изначально хотел для своих приблуд создавать базы/контейнеры прямо в коде лиспа. Потом передумал.
Ну, для примера одно из моих первых приложений на Лиспе. Это примерно то, о чем писал ТС. Есть типовой проект (довольно-таки приличного объема: альбома 3-4 формата А2) и нужно сформировать комплект для какого-то набора изменяемых исходных параметров. Может быть я был и мазохистом, но все исходные данные из типовика были загнаны в файлах *.Lsp.
функции типа vlax-savearray, наверное, в те времена еще не существовали (я не знал по-крайней мере).
Однако работает все нормально до сих пор.
PS. Это не значит, что я пропагандирую именно такой подход. Это все хорошо, когда один раз эти исходные данные загнал и забыл.
Понятно, что если с этими первоначальными данными нужно сделать предварительно какие-то манипуляции или нужно часто их обновлять, редактировать, а в Экселе есть подходящие инструменты для этих манипуляций (какой-то расчет например), то почему бы и не в экселе сделать базу. Есть и такие примеры и на VBA. Тоже вполне себе рабочие вещи.
Вложения
Тип файла: rar bandicam 2017-01-10 20-30-24-312.rar (7.57 Мб, 20 просмотров)

Последний раз редактировалось Владимир_М, 10.01.2017 в 17:17.
Владимир_М вне форума  
 
Непрочитано 10.01.2017, 17:52
#35
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
<phrase 1=


trir
>>просто надо реализовать бинарное дерево.
Если вам понадобились "хитрые" структуры данных - пора перелазить на что-то более подходящее.

ShaggyDoc
>>умеют работать с COM. И это самое удобное. Вот там и используйте любые библиотеки, а также визуальные компоненты.
Самый жуткий случай (сугубо ИМХО).
Связать по нужде 2 готовых приложения используя COM - пожалуйста, а вот целенаправлено писать так чтото для автокада... Для скриптов есть лисп, для посеръезней - arx, net. А делфи + автокаду это от нежеланья развиваться - знаю делфи и буду его юзать.

>>И концепция назвалась "Программирование для AutoCAD", не для Paint.
Если "Программирование для AutoCAD" - согласен, странная концепция.

>>изображаемое в виде прямоугольника. Он может иметь разные размеры, исходную точку (центр, угол), поворот
Автокад конечно хорошая программа, но это не единственный способ справиться с элементарной геометрией.
>> Или каждый раз в файл записать, или в сторонней программе (только для прямоугольника) иметь варианты ввода.
Вы о наколенных "библиотеках" DXF из лохматых годов которые кроме как генерить файлы ничего не умели? В нормальной программе есть внутреннее представление данных и это просто вопрос конвертации одного представления в другое

Последний раз редактировалось zamtmn, 10.01.2017 в 18:03.
zamtmn вне форума  
 
Непрочитано 10.01.2017, 19:32
#36
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Связать по нужде 2 готовых приложения используя COM - пожалуйста, а вот целенаправлено писать так чтото для автокада... Для скриптов есть лисп, для посеръезней - arx, net. А делфи + автокаду это от нежеланья развиваться - знаю делфи и буду его юзать.
При чем здесь "делфи"? Я писал про любые среды программирования. И COM не делается "целенаправленно для автокада". Приложение может иметь свою объектную модель, к которой может обратиться любое другое приложение.

Цитата:
Сообщение от zamtmn Посмотреть сообщение
Автокад конечно хорошая программа, но это не единственный способ справиться с элементарной геометрией.
На свою намекаете? Да пожалуйста, научите её делать дело не хуже Автокада и народ потянется.

Цитата:
Сообщение от zamtmn Посмотреть сообщение
Вы о наколенных "библиотеках" DXF из лохматых годов которые кроме как генерить файлы ничего не умели?
Про наличие накопленных библиотек не я упомянул, а trir. Ни разу в жизни DXF не генерировал, хотя таких библиотек у меня несколько есть. Даже и для DWG.

DXF - это старый, убогий и неудобный формат.

А о стратегии поясню на примере. Есть у меня программа ГИС-Обозреватель. Предназначена для просмотра электронных карт разных форматов без наличия программ, в которых эти карты сделаны. Она работает с базами данных, в которых содержатся пространственные данные. Т.е. координаты различных объектов - зданий, сетей, дорог и прочего. В БД находятся только координаты вершин, но нет никакой информации о том как изображаются объекты - цвет, тип линии, заливки и прочее.

Вот отобразить карту можно разными способами, в зависимости от назначения. И выгрузить отобранные объекты для использования в любой другой программе. Например, в Мапинфо - удобнее всего в виде MIF/MID (текстовый формат для координат) и Workspace (для настройки внешнего вида). А можно и в AutoCAD, но не в виде DXF, а в виде текстового списка точек, который будет прочитан Лиспом и нарисован как надо. Она и не знает о существовании Автокада и не умеет в нем ничего рисовать (хотя можно было бы и научить, тоже через COM). Но пусть Автокад рисует сам, средствами LISP. Или еще чем.
А в какой-то другой системе - своими средствами.

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

Подобную программу все знают - это Дубль-ГИС (теперь "ДваГИС) . Отображает карты любых городов, причем в разном виде. А пространственные данные там тоже в БД находятся, мы даже раньше одну СУБД с ними использовали. В картах нашего города до сих пор множество объектов по моим данным находятся. И 2ГИС, как правильная программа, имеет свой API, позволяющий разрабатывать сторонние приложения. В том числе Open Source.
ShaggyDoc вне форума  
 
Автор темы   Непрочитано 10.01.2017, 19:49
#37
ETCartman


 
Регистрация: 09.12.2008
Сообщений: 4,649


Я не собираюсь генерировать dxf по точкам, потому что это конечно сложно и долго. Хотя например кроме автокада - тот же qcad имеет средства пользовательского программирования.
Что касается выбора Excel и электронных таблиц вообще - тут вопрос больше в том, как вводить данные и где их хранить
А вот как раз электронные таблицы для этого в основном и используются. Гораздо чаще чем Access например
ETCartman вне форума  
 
Непрочитано 10.01.2017, 20:12
#38
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
<phrase 1=


Я ни на что не намекаю, о своем в других топиках. Тут упомянул только в контексте паскаля.

>>DXF - это старый, убогий и неудобный формат.
Формат хранения данных на диске дело десятое. Есть набор примитивов, есть набор свойств этих примитивов - хочешь дружить с автокадом - будь добр придерживайся правил. Напимер аналогу вхождению блока в svg можно задать преобразование скоса, но автокад такое не поддерживает и "влоб" такими чертежами не "обменяться"
Что DXF что DWG это лишь способ хранения на диске. Чем DXF хуже DWG? по сути это одно и тоже - один бинарный и закрытый, другой текстовый и полуоткрытый.
Поэтому если "DXF - это старый, убогий и неудобный формат" то и Автокад с его набором примитивов и их свойств тоже старый и убогий))

>>А о стратегии поясню на примере. Есть у меня программа
Дак и я про тоже: правильный пример взаимодействия программ - обмен стандартизированными данными, поддержка форматов этих данных с обоих сторон.
Не правильный: в лиспе нет возможности делать сложные окошки - заюзаем COM и вызовем чтото чужеродное (vlax-safearray хоть и ненужен, но придется его попользовать ) показывающее сложное окошко с данными, потом эти данные какимито костылями заполучим, потом вызовем чтото еще, что нам в чертеже их прорисует...

Последний раз редактировалось zamtmn, 10.01.2017 в 20:18.
zamtmn вне форума  
 
Непрочитано 10.01.2017, 20:34
#39
ShaggyDoc

Thượng Tá Quân Đội Nhân Dân Việt Nam
 
Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Чем DXF хуже DWG? по сути это одно и тоже - один бинарный и закрытый, другой текстовый и полуоткрытый.
Поэтому если "DXF - это старый, убогий и неудобный формат" то и Автокад с его набором примитивов и их свойств тоже старый и убогий))
Они оба хуже. В свое время Autodesk разработала DesignXML - вот это был шаг вперед. Но решилась использовать только в одной версии и только для описания блоков. И сразу сделала два шага назад - отказалась.
А причина простая - тогда бы появилось множество приложений, легко работающими с описаниями чертежей. Сейчас бы уже наверняка были и получше самого AutoCAD. Он же действительно "старый и убогий" (хотя и популярный и необходимый), а все изменения за последние лет 10-15 - косметические "бантики".

Добротная "чертилка" с 3D, но завышенная по цене раз в десять. Но "пипл хавает".
ShaggyDoc вне форума  
 
Непрочитано 10.01.2017, 20:47
#40
zamtmn

КИПиА
 
Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
<phrase 1=


Надо отдать должное автодеску - DWG надежно вшит нам в мозги)) Сейчас давно уже есть куча "клонов" - а ничего пооткрытей (в смысле формата данных) не появляется - бабло побеждает зло))
zamtmn вне форума  
Ответ
Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Лучшая стратегия создания кастомного приложения

Размещение рекламы
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Изменить порядок создания объектов в AutoCAD hwarang AutoCAD 13 26.08.2021 22:12
Какая программа нужна для создания инженерных расчетов Sasha87 Прочее. Программное обеспечение 69 07.04.2016 09:14
Какое минимальное количество людей необходимо для создания человечества? Кочетков Андрей Разное 50 18.06.2012 22:31
Переопределение установок режимов создания атрибутов wluk1958 Программирование 7 18.04.2012 15:04
Приложения для создания выносок Dies77_66 Прочее. Программное обеспечение 29 24.05.2006 06:04