[ETCartman]

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

[Boxa]

Сообщение от ETCartman Вопрос каким путем лучше всего сделать такое приложение.

Вот "Лучшая стратегия создания кастомного приложения":
1. Написать подробное ТЗ.
2. Выполнить ТЗ.

ЗЫ.
Как лучше написать КРАСНУЮ КНОПКУ...

[Enik]

Широко берёте.

Разбейте задачу на несколько составляющих и решайте их по отдельности.
Типа такого:
1. Создать шаблон и базу элементов автокад (подшивки, дин. блоки, лиспы...)
2. Разработать алгоритм наполнения чертежей элементами и реализовать в программном коде.
3. Реализовать печать и брошюровку листов в один какой-нибудь пдф.

А не так, что всё и сразу, да ещё без тз и на форуме.

[Denbad]

Лет 17 назад парни из АСКОНа рекламировали Компас с надстройкой выдающей рабочие чертежи мачт высоковольтных ЛЭП исходя из выбранных параметров, можешь у них заказать.

[zamtmn]

>>Basic знаю, Pascal тоже.
Если паскаль - кроме зкада вариантов нет

[maratovich]

Сообщение от Boxa Вот "Лучшая стратегия создания кастомного приложения": 1. Написать подробное ТЗ. 2. Выполнить ТЗ.

3. Выдать ТЗ в тему "Поиск исполнителей".

Сообщение от ETCartman Вопрос каким путем лучше всего сделать такое приложение.

Самый лёгкий путь - заказать.

[ETCartman]

Заказать не простой путь. Потому что у всех чертежей своя специфика, дольше составлять ТЗ. Я просто пытаюсь понять стандартный способ именно применительно к Автокаду 15 (то есть для себя бы я вообще автокад не рассматривал, ввиду его дороговизны и зависимости от политики производителя)
Можно ли оперировать объектной моделью автокада из VBA например Excel?
Тут я тоже рассматриваю не как для себя, потому что Excel я бы не стал пользовать по той же причине (я вообще использую linux большую часть времени и взял бы qcad или zcad)
Если кто то имеет опыт автоматизации чертежей для базовых станций - то можно было бы и купить.

[Сергей812]

Сообщение от ETCartman Можно ли оперировать объектной моделью автокада из VBA например Excel?

Да - правда это процесс не быстрый, но через COM можно делать большую часть того же, что в самом VBA Акада (причем сам VBA enabler может и не стоять) и совершенно аналогично по синтаксису. Т.е. примеров в инете..

[trir]

если делать dxf, то сгодится и python
и автокад не нужен

[Enik]

Сообщение от Сергей812 Да - правда это процесс не быстрый, но через COM можно делать большую часть того же, что в самом VBA Акада (причем сам VBA enabler может и не стоять) и совершенно аналогично по синтаксису. Т.е. примеров в инете..

Что, простите? Можно объектную модель из экселя через COM в автокаде воспроизвести? Не прочитать содержимое двух ячеек и вогнать в переменную точки вставки н-ого блока, а так, чтобы всерьёз. И чтобы обмен данными в обе стороны был. Можно? И это реально работает?

[Сергей812]

Сообщение от Enik Что, простите? Можно объектную модель из экселя через COM в автокаде воспроизвести? Не прочитать содержимое двух ячеек и вогнать в переменную точки вставки н-ого блока, а так, чтобы всерьёз. И чтобы обмен данными в обе стороны был. Можно? И это реально работает?

что подразумеваете под воспроизведением объектной моделью для начала? Можно из экселя запрашивать данные от пользователя (выберите примитив в акаде и т.д.), можно выгрести данные из той же модели и подтянув формулами недостающие данные, создать вполне законченный кусок спецификации, можно обратный процесс - добавлять примитивы в акад по каким то условиям, атрибуты блоков задать и т.д.. Что в интерфейсе акада реализовано - то и будет работать. Но все это весьма неторопливо. В Net API это на 2..3 порядка быстрее работает.

[Enik]

Сообщение от Сергей812 что подразумеваете под воспроизведением объектной моделью для начала?

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

Линейная задача. Если по-простому, в Экселе рассчитал, в автокаде начертил. Нужен пример для наглядности. Вот взять, допустим, трассу трубопровода. В экселе задаются точки, количество труб, уклон и пр. И там же рассчитываются все необходимые параметры. Всё, что в экселе, назовём информационной моделью. Из информационной модели нужно "выдернуть" нужные данные и по ним отрисовать объектную модель в автокаде. Например, профиль трассы. Offtop: Не надо сейчас про сивил, его функционал недостаточен. Шаг влево, шаг вправо от проектирования - и приходится дочерчивать всё руками.

Если так посмотреть, то вроде бы ничего сложного. И вроде бы есть оно всё давно уже в готовом виде. Но как эту проблему решить изящно? Чтобы, например, каждый участник процесса строительства мог за два щелчка получать только ту информацию, которая ему нужна. Монтажники - своё, геодезисты - своё...

Вот, как бы такая постановка задачи.

И давайте немного условимся о контексте. Я смотрю на вопрос не только с позиции проектирования. Ещё с точки зрения производства строительно-монтажных работ и сдачи объекта в эксплуатацию. Не нужна ещё одна чертилка для проектировщиков. Необходим комплексный продукт для всех.

[Сергей812]

Сообщение от Enik Линейная задача. Если по-простому, в Экселе рассчитал, в автокаде начертил. Нужен пример для наглядности. Вот взять, допустим, трассу трубопровода. В экселе задаются точки, количество труб, уклон и пр. И там же рассчитываются все необходимые параметры. Всё, что в экселе, назовём информационной моделью. Из информационной модели нужно "выдернуть" нужные данные и по ним отрисовать объектную модель в автокаде. Например, профиль трассы.

Нечто подобное делал swell в связке нанокад-эксель для своей области деятельности: в экселе расчетная часть - в нанокаде отрисовка (насколько понял из его видео). Что рисовать руками в акаде, что добавлять программно - разницы нет, вся соль в вводе, в хранении и обработке данных. Но что точно не стоит реализовывать на экселе - это функции ГИС:

Сообщение от Enik Чтобы, например, каждый участник процесса строительства мог за два щелчка получать только ту информацию, которая ему нужна. Монтажники - своё, геодезисты - своё...

на экселе можно слепить локальную вспомогательную приблуду, с достаточно сложным функционалом - но под "узкие" вещи. На самом деле то, что хочет ТС реализовать - на мой взгляд, из 3/4 состоит в наработке исходных данных, блоков, шаблонов (причем заточенных под автозаполнение), анализа и алгоритмизации процесса - и лишь на четверть: сама программная реализация с отладкой.

[Enik]

Сообщение от Сергей812 Но что точно не стоит реализовывать на экселе - это функции ГИС

Не уверен, что мне ясна причина этого. Вроде бы посредством решения простых геодезических задач это сводится к линейному алгоритму... Или нет?

Сообщение от Сергей812 На самом деле то, что хочет ТС реализовать - на мой взгляд, из 3/4 состоит в наработке исходных данных, блоков, шаблонов (причем заточенных под автозаполнение), анализа и алгоритмизации процесса - и лишь на четверть: сама программная реализация с отладкой.

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

[Сергей812]

Сообщение от Enik Не уверен, что мне ясна причина этого. Вроде бы посредством решения простых геодезических задач это сводится к линейному алгоритму... Или нет?

Процесс строительства, куда входит и проектирование, обычно "размазан" в пространстве и во времени - это вызывает необходимость передачи и контроля не искаженности информации с использованием доступных каналов связи. Это явно не уровень экселя, он всего лишь электронная таблица. Кстати, Visio по сути - тоже электронная таблица, но заточенная под рисование.

[baksconstructor]

Прошу разъяснить понятие кастомное приложение... Это чего за зверь ? Или как всегда "ресепционисты" в в новом творчестве ?

[Сергей812]

baksconstructor, думаю, что это от custom - заказное или пользовательское

[kp+]

Сообщение от ETCartman Basic знаю, Pascal тоже.

В "САПР на базе Autocad..." один из разделов как раз посвящен созданию COM-приложения на DELFI.

[Владимир_М]

Сообщение от ETCartman Есть задача автоматизировать процесс создания комплектов чертежей. Инпут: перечень антенн + всякая другая типовая информация Выход: типовой комплект чертежей. Применяются антенны из базы данных (виды) которые должны быть вставлены в автокад.

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

[ETCartman]

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

[Сергей812]

Сообщение от ETCartman Желательно чтобы автокад вообще не запускался, а обрабатывал данные в пакетном режиме и выплевывал чертежи в заданную папку.

Запуск акада в фоновом режиме или консольная версия акада? Насчет второго - надо еще проверить, поддерживает ли COM-интерфейс (не использовал).

Сообщение от ETCartman Думаю насобирать примеров на эту тему

Примеров чего именно? Если программирования - то набираете в поисковике "VBA AutoCAD" и смотрите - по сути коды один в один, только вместо ThisDrawing будет переменная документа в коде VBA Excel.

[Александр Ривилис]

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

Точно не поддерживается. У консоли нет COM-интерфейса.

[Владимир_М]

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

Пока только Вы сами и можете определить, что для Вас может быть оптимальным. Текст и цифры могут вводится и храниться и в обычном текстовом файле и в файле базы данных и в файле Excel или даже в самом тексте программного кода. Все зависит от объема данных, от того как часто их редактировать придется, от того какова их структура, какие манипуляции предполагается с ними делать или какие между ними есть логические взаимосвязи.
Если вы определились, что это будет файл Excel, то закручивать его в какую-то единую систему с Автокадом (т.е. управлять объектной моделью из Excel) совсем не обязательно. Данные данными, а выполнение графической части отдельно может быть. Можно из файла Excel по мере необходимости (по нажатию кнопки, например) переходить в Acad и уже используя VBA Acad (или Лисп и проч.) выполнять графическую часть. Можно, как обычно, из самого Acad из его меню запустить приложение, которое возьмет нужную информацию из файла Excel. Можно, вообще, как пускалку использовать отдельный exe-файл, который будет управлять и Excel и Acad в любом порядке. Дело вкуса, к чему больше привыкли или что логичней с точки зрения объема выполняемой приложением работы. Вот зачем из макроса Excel создавать примитивы Acad? логики не вижу.

Сообщение от ETCartman Желательно чтобы автокад вообще не запускался...

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

[ShaggyDoc]

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

Если не связываться с программированием - надо забыть про "кастомные приложения". К Excel/VBA "прилагается" ненавистная Windows.

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

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

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

[zamtmn]

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


>>Да уж. Автор идеи и садист и мазохист одновременно.
Вполне оправданный подход для простых случаев. Почему ктото должен для элементарных вещей покупать автокад?
>>По сути - создание себе рабочего места на много лет.
С другой стороны - создание рабочих мест манагерам и адвокатам автодеска)).

[baksconstructor]

Сообщение от zamtmn С другой стороны - создание рабочих мест манагерам и адвокатам автодеска)).

У автора написано Texas, проблем по определению не будет.

[ShaggyDoc]

Сообщение от zamtmn Вполне оправданный подход для простых случаев. Почему ктото должен для элементарных вещей покупать автокад?

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

Да, очень простой случай.

[trir]

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

[Сергей812]

Сообщение от trir а программировать на VBA - мазохизм

редактор VBA - это мазохизм) И ООП в зачаточном состоянии есть и в VBA - классы, свойства, методы, публичные и приватные члены, конструкторы и деструкторы. Если написать в виде класса работу с акадом - то потом в основном коде красота: одна строчка - это создание объекта с одновременным подключением к акаду, вторая - уничтожение объекта с одновременным отключением от акада. А между ними вызовы методов из класса - делающие определенную работу в акаде. Для простых вещей вполне годная вещь и ускоряет работу. А дальше переходить на что-то более серьезное - Net, ObjectARX и т.д., если к тому времени интерес не пропадет (лисповцам просьба не обижаться - просто вы другая ветка эволюции программирования, редко кто сочетает продвинутый уровень как в лиспе, так и в "обычных" языках программирования).

[Enik]

Сообщение от Владимир_М Текст и цифры могут вводится и храниться и в обычном текстовом файле и в файле базы данных и в файле Excel или даже в самом тексте программного кода.

Сообщение от Владимир_М или даже в самом тексте программного кода.

А чё там у лиспа с массивами и индексацией элементов в них? Про списки не будем. Я изначально хотел для своих приблуд создавать базы/контейнеры прямо в коде лиспа. Потом передумал.

[Сергей812]

Сообщение от Enik А чё там у лиспа с массивами и индексацией элементов в них?

vlax-savearray-...

[trir]

А чё там у лиспа с массивами и индексацией элементов в них?

просто надо реализовать бинарное дерево. Главная проблема lisp'а - всё надо писать самому. Для популярных языков можно найти готовые библиотеки

[ShaggyDoc]

Сообщение от Enik А чё там у лиспа с массивами и индексацией элементов в них? Про списки не будем. Я изначально хотел для своих приблуд создавать базы/контейнеры прямо в коде лиспа. Потом передумал.

"Массивы" для LISP просто не нужны, это "для измученных нарзаном бейсиком". Как раз про списки и "будем". И vlax-savearray-... самому LISP не нужен, это "костыли" для связи с объектами, которым нужны именно массивы.

Сообщение от trir Главная проблема lisp'а - всё надо писать самому. Для популярных языков можно найти готовые библиотеки

"Можно найти" - это не значит, "они у меня есть и я умею ими пользоваться".

Но стратегически (такая тема ветки) AutoCAD позволяет писать приложения не только в "родных" для него средах программирования, но и в любых, которые умеют работать с COM. И это самое удобное. Вот там и используйте любые библиотеки, а также визуальные компоненты.

[Владимир_М]

Сообщение от Enik А чё там у лиспа с массивами и индексацией элементов в них? Про списки не будем. Я изначально хотел для своих приблуд создавать базы/контейнеры прямо в коде лиспа. Потом передумал.

Ну, для примера одно из моих первых приложений на Лиспе. Это примерно то, о чем писал ТС. Есть типовой проект (довольно-таки приличного объема: альбома 3-4 формата А2) и нужно сформировать комплект для какого-то набора изменяемых исходных параметров. Может быть я был и мазохистом, но все исходные данные из типовика были загнаны в файлах *.Lsp.
функции типа vlax-savearray, наверное, в те времена еще не существовали (я не знал по-крайней мере).
Однако работает все нормально до сих пор.
PS. Это не значит, что я пропагандирую именно такой подход. Это все хорошо, когда один раз эти исходные данные загнал и забыл.
Понятно, что если с этими первоначальными данными нужно сделать предварительно какие-то манипуляции или нужно часто их обновлять, редактировать, а в Экселе есть подходящие инструменты для этих манипуляций (какой-то расчет например), то почему бы и не в экселе сделать базу. Есть и такие примеры и на VBA. Тоже вполне себе рабочие вещи.

[zamtmn]

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

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

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

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

[ShaggyDoc]

Сообщение от 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.

[ETCartman]

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

[zamtmn]

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

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

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

[ShaggyDoc]

Сообщение от zamtmn Чем DXF хуже DWG? по сути это одно и тоже - один бинарный и закрытый, другой текстовый и полуоткрытый. Поэтому если "DXF - это старый, убогий и неудобный формат" то и Автокад с его набором примитивов и их свойств тоже старый и убогий))

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

Добротная "чертилка" с 3D, но завышенная по цене раз в десять. Но "пипл хавает".

[zamtmn]

Надо отдать должное автодеску - DWG надежно вшит нам в мозги)) Сейчас давно уже есть куча "клонов" - а ничего пооткрытей (в смысле формата данных) не появляется - бабло побеждает зло))

[trir]

Почти нет никакой разницы между работать с entmake и генерировать dxf - одни и те же dxf-пары
И работу с dxf всегда можно спрятать в удобную обёртку
dxf плох лишь когда нужно работать с solid3d и прочим brep

[zamtmn]

trir
Разница оч большая.
Сохрани в автокаде пустой dxf >=2000
Открой в блокноте, попробуй чтонить добавить-убавить

[trir]

А в чём проблема?

[zamtmn]

Проблем нет. Есть ошибки и вылеты при попытке открыть в автокаде не очень валидный dxf. Документация кое-как годящаяся для чтения и никак для "генерации"... да мало ли чего.
В случае entmake думаю максимум - примитив отрисуется не так как залумано.

[ShaggyDoc]

Сообщение от trir Почти нет никакой разницы между работать с entmake и генерировать dxf - одни и те же dxf-пары И работу с dxf всегда можно спрятать в удобную обёртку dxf плох лишь когда нужно работать с solid3d и прочим brep

"Почти нет разницы" - это потому, что и то и другое плохо. Зачем человек должен разбираться и держать в уме какие-то нечеловеческие коды и пары?
Конечно, "можно" ко всему приспособиться. И в начале, когда ничего лучше DXF-кодов не придумали, приходилось это изучать. И сейчас приходится. Но теперь хоть альтернативы есть.

Но насколько удобнее использовать функции или методы с "человеческими" именами! И внешние данные гораздо удобнее хранить в "человеческом" виде, например в XML. Это все понимают, в том числе в Autodesk. Но шевелиться не спешат, потому что "пипл хавает".

Вот про XAML сколько лет назад орали - "бу сделано". Идея-то замечательная - хранить в единой форме и внешний вид форм, и свойства контролов, и их действия. Могло бы быть единым для всех приложений. Но это же мозгой шевелить надо, а "пипл хавает".

[zamtmn]

Имхо. Идея внутренней хранения графических данных в XML - неправильная, он абсолютно неподходит для этого, только наружнее хранение на диске.

>>Зачем человек должен разбираться и держать в уме какие-то нечеловеческие коды и пары?
если я правильно понимаю "обертки" переводящие "нечеловеческие" коды в чтото человеческое делаются в 5 минут. Если это не сделано - значит особо никого не напрягает.
DXF хороший формат - главное качество расширяемый, как минус его текстовость - возможность менять местами и пропускать некоторые пары, плохая документированость
DWG - если отбросить то что туда добавлено для затруднения чтения сторонними средствами и отсутствие документации - очень хорошо продуманый бинарный формат, но не универсальный - много автокадспецифик сущностей.

По моему претензий к форматам не должно быть никаких, главный их фатальный недостаток - отсутствие нормальных свободных бтблиотек для манипуляций с данными в этих форматах

[ShaggyDoc]

Сообщение от zamtmn Идея внутренней хранения графических данных в XML - неправильная, он абсолютно неподходит для этого, только наружнее хранение на диске.

Ну, разумеется, данные хранятся на диске в файле. Только во время чтения парсер (причем стандартный) создает объектную модель в памяти в виде дерева элементов. И прикладному программисту надо только с ней и разбираться.

Кроме того XML вообще имеет ряд преимуществ. Надо только чтобы он был "валидным", т.е. соответствовал простым правилам (вложенность элементов, явное открытие и закрытие тегов):

1. Можно вводить любые собственные элементы и атрибуты. Другие программы, которые их не знают, просто пропустят эти места. А своя будет знать, что с ними делать.

2. Можно редактировать как обычным текстовым редактором, так и специальными, отображающими структуру в виде дерева.

3. Вместе с графическими данными может храниться и семантическая информация. И даже можно в атрибуте держать текст функции (или ссылку на нее) для рисования таких объектов.

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

А не используют только из шкурных интересов производителей софта. Шоп "нигде кроме, как в Моссельпроме".

Сообщение от zamtmn главный их фатальный недостаток - отсутствие нормальных свободных бтблиотек для манипуляций с данными в этих форматах *

А у XML этого недостатка нет. В каждой среде имеются разные варианты, в зависимости от потребностей. Даже с "запросами", наподобие SQL в СУБД.

[zamtmn]

>>Только во время чтения парсер (причем стандартный) создает объектную модель в памяти в виде дерева элементов. И прикладному программисту надо только с ней и разбираться.
Обычно внутреннее представление графических данных - дерево классов line, circle и т.п. Какой стандартный парсер сумеет мне вернуть такое дерево состоящее из моих классов? а не дерево состоящее из его TXMLTreeNode c элементами NAME=Line, X1=0.01, Y1=0.01...?
XML слишком универсальный. Самописный хмл парсер такое сумеет, или "надстройка" над стандартным парсером.
Но для надстройки разница невелика над чем ее делать - над каким либо стандартным хмл парсером или сразу над FileStream/MemoryStream и использовать не xml формат

1. Поддержка этих атрибутов будет нужна во внутреннем "дерево классов line, circle и т.п." иначе они потеряются при повторнй "сериализации"
2. Всетаки обычный текстовый файл гораздо приятней редактировать текстовым редактором. но можно, да
3. Это развитие 1.

Если не использовать "дерево классов line, circle и т.п.", а работать с "дерево состоящее из TXMLTreeNode c элементами NAME=" то это будет тормозилка и отъедалка памяти

>>Но сейчас с большими размерами файлов нет проблем, а когда-то файлы стремились довести до двоичного формата именно ради размеров
Это касается только "наружнего" хранения на диске, для внутреннего представления попрежнему экономия очень актуальна, поэтому у "дерево классов line, circle и т.п." альтернатив пока нету, а dwg, dxf, xml, что там еще - это лишь способ сериализации внутреннего формата.

[Do$]

Сообщение от Enik Offtop: Не надо сейчас про сивил, его функционал недостаточен. Шаг влево, шаг вправо от проектирования - и приходится дочерчивать всё руками.

Offtop: Есть кое-какие наработки по Civil 3d, которые сильно помогают в проектировании трубопроводов. Если интересно - смотрите тут: http://iteris-soft.ru/videos/iterisnets_project_sample
Будут вопросы - обращайтесь в ЛС или через контакты на том сайте.

[Enik]

Сообщение от Do$ Есть кое-какие наработки по Civil 3d, которые сильно помогают в проектировании трубопроводов.

Спасибо! Посмотрел видео с интересом и нескрываемым удивлением. Очень правильные и нужные вещи делаете. В принципе, с таким подходом и при такой технике работы ваши приложения могут быть полезны для ПТО в плане разработки исполнительной документации, а также исполнительных чертежей для геотреста.

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

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

Offtop: Без пафоса: как бывший проектировщик, чуть слюной не захлебнулся.

[Дима_]

В добавление к оффтопу о хранении данных.
Я в последнее время (в общем уже и не малое), для хранения данных использую СУБД (в зависимости от задачи и "корпоративной обстановки" MSSQL, MySql, SQLite). Да тот-же XML, XLS(x) и другие гораздо менее популярные форматы я тоже использую, но только для экспорта в сторонний софт. Вся сериализацию/десериализацию в свои объекты происходит автоматом с помощью провайдеров типов, ими-же если данные достаточно сложные делаю и тот самый экспорт. Метод настолько удобен практически, что в сторону "классических" преобразований даже смотреть не хочется - реально забываешь про все ошибки данных любой сложности - и "крутить" их можно как хочешь. А хранение в стандарной СУБД снимает с себя необходимость разработки большей части API для сторонних разработчиков - просто даешь им "поясниловку" по полям таблиц и все - главное чтоб данные не загубили - но это уже их проблемы (я на практике в этом разрезе сталкивался в основном с 1С'никами - у них как правило вопрос только в чтении данных), плюс сразу решаешь все вопросы о "многопользовательстве", доступу, резервному копированию и пр. - все это уже есть "из коробки" на высшем уровне + не надо обучать (нормальные админы это и так знают) - в общем никаких велосипедов.

[maratovich]

Пишите чаще и больше друзья.
Offtop: Пока другие делают...

[zamtmn]

Дима_
У меня с "автосериализацией" както несложилось. Одна из основных причин - большая версиозависимость - чтото добавил\убрал в формат - ранее наработаное перестало нормально грузиться - приходится костылять

maratovich
непофлеймишь-неподелаешь

[Дима_]

Сообщение от zamtmn Одна из основных причин - большая версиозависимость - чтото добавил\убрал в формат - ранее наработаное перестало нормально грузиться - приходится костылять

Если мы говорим про провайдеры типов - то все новое добавится при первой-же компиляции + плюс новое надо добавлять всего с учетом двух правил (не использовать select * ...), хотя в случае, например, linq такого и не будет (если посмотреть sql код запроса в который преобразуется linq выражение, там, даже если запрашиваются объект из всех полей, все равно они запрашиваются "поштучно"), тогда любое расширение можно добавить как null'абле поле, и в отличии например от xml есть уверенность, что никакой "левый" софт при обновлении данных не затрет неизвестные ему поля (если их нет в update - он их и не тронет, а вот если загрузил выгрузил - из xml то с большой вероятностью все что ему "не понадобилось" умрет при трансформации туда обратно - только малая часть софта оставит полную "родную" структуру - большинство просто запишет "свой" вариант). Ну и всегда есть 100% вариант - создавать новую таблицу с ссылкой на id поля в изначальной, куда и добавлять все что угодно, тогда и select * от чужого софта (или своего, предыдущей версии) не страшен.

[zamtmn]

>>Если мы говорим про провайдеры типов
Я говорю в общем случае. С net незнаком.

>>Ну и всегда есть 100% вариант -
100% вариант - следовать общепринятому формату принятому в данной области

[Дима_]

Сообщение от zamtmn следовать общепринятому формату принятому в данной области

Я бы сказал скорее их надо хорошенько просмотреть, чтоб понять на чем можно спотыкнуться - основные проблемы - это частенько дружат "профильные" форматы только с ASCII (то есть для нас - с русскими буквами там плохо), если форматы с ограниченным числом символов на поле - то "не лезет" бывает, количество записей ограниченно частенько и пр. Единицы свои любят еще вводить (в 1/360 мм например). А формат внутренний надо все-же использовать под свою объектную модель - особенно если имеем дело с "многосторонним" ПО (у меня например и для склада, и для КБ, и для бухгалтерии и для цеха (там как на бумагу, так и на ЧПУ) все в своих форматах из одной модели выводится).
з.ы. хотя нельзя не признать, иногда из-за изменений внешних обстоятельств в виде требований экспортной совместимости с каким-либо программным продуктом (или как следствие устройством под ним работающим), приходилось и частично "логику" программы менять; но тем не менее пока все равно обходилось без "революционных" перекроек.

[baksconstructor]

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

[Дима_]

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

[trir]

Ещё раз хочу сказать, что на C# писать приятнее из всех современных языков, а самое главное - он позволяет достигать результата с минимумом усилий

[Сергей812]

Сообщение от trir Ещё раз хочу сказать, что на C# писать приятнее из всех современных языков, а самое главное - он позволяет достигать результата с минимумом усилий

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

[trir]

C# наиболее прокаченный, в других языках могут отсутствовать некоторые фичи

[Дима_]

Сообщение от trir Ещё раз хочу сказать, что на C# писать приятнее из всех современных языков, а самое главное - он позволяет достигать результата с минимумом усилий

Да ладно... Результат в чем? Опишите мне web страничку на C# или покажите мне как там приятно и удобно DSL можно оформить.

Сообщение от trir C# наиболее прокаченный, в других языках могут отсутствовать некоторые фичи

Парадокс Блаба в чистом виде. С моего ракурса, он где-то чуть повыше серединки.

[trir]

Опишите мне web страничку на C#

https://ru.wikipedia.org/wiki/ASP.NET

удобно DSL можно оформить

чего?

[Дима_]

А при чем тут ASP и C# - это скорее наоборот доказательство того, что на столь популярном C# web страничку не описать - приходиться вводить новый инструмент.
DSL

[trir]

html это язык разметки, а SQL язык структурированных запросов.
Всё таки для каждого языка есть своя область применения, я говорил про преимущества C#/dotNET в его области

[ShaggyDoc]

Ну, опять про "языки" начали, "прокаченные". Да не в "языках" дело. Между конечным продуктом много прокладок есть - и среды разработки, и среды исполнения, а главное - руки и голова для "жать батоны".
А Дима_ на важное внимание обратил:

Сообщение от Дима_ Я в последнее время (в общем уже и не малое), для хранения данных использую СУБД (в зависимости от задачи и "корпоративной обстановки" MSSQL, MySql, SQLite). Да тот-же XML, XLS(x) и другие гораздо менее популярные форматы я тоже использую, но только для экспорта в сторонний софт.

Именно СУБД (какая именно - дело разработчика, но с учетом назначения приложения). Использование СУБД и компонентов для работы с ними позволяет в десятки раз сократить время разработки и повысить надежность. Я вот использую для локальных приложений (включая сетевую работу) Absolute Database - из-за наличия полного SQL и полной независимости от сторонних решений, таких как ADO. А вот от SQLite вынужден был отказаться по ряду причин.

И экспорт-импорт данных через XML. Вот делал программу, результат которой в виде энергопаспортов передается в Минэнерго. А там собираются десятки тысяч паспортов со всей страны. Выполненных в разных программах. Но есть единая схема XML, которая позволяет полностью унифицировать обмен данными. Из любой программы в любую другую. И все прекрасно работает. Все ошибки автоматически выявляются.

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

[trir]

C# можно выполнять на front-end, вместо javascript ;=)
а был ещё Silverlight

[Дима_]

Сообщение от trir html это язык разметки, а SQL язык структурированных запросов. Всё таки для каждого языка есть своя область применения, я говорил про преимущества C#/dotNET в его области

...

Сообщение от trir C# можно выполнять на front-end, вместо javascript ;=) а был ещё Silverlight

Вот тут мы и подошли к самому интересному - на C# все можно выполнить но совсем не все описать. И в этом - полном отсутствии декларативности - и есть на мой взгляд его основная проблема - хотя императивная часть там действительна хорошо "прокачена" + прекрасная поддержка IDE. С моей точки зрения понимание этого "тонкого", но очень важного различия очень сильно меняет представление на программирование в целом, на любом языке программирования - изменяет сам стиль программирования.

[trir]

Нельзя объять необъятное
Какая же декларативность вам нужна?

[Boxa]

Сообщение от Дима_ Вот тут мы и подошли к самому интересному - на C# все можно выполнить но совсем не все описать. И в этом - полном отсутствии декларативности - и есть на мой взгляд его основная проблема - хотя императивная часть там действительна хорошо "прокачена" + прекрасная поддержка IDE. С моей точки зрения понимание этого "тонкого", но очень важного различия очень сильно меняет представление на программирование в целом, на любом языке программирования - изменяет сам стиль программирования.

Вот бы несколько базовых видео уроков на F# применительно к автокаду, по типу таких, как у Димы Загорулькина.
Очень интересно, но как подступиться не понятно, примеров кода и примеров старта на F# в сети практически нет.

[Дима_]

Я пока про F# и слова не сказал. Если в плане декларативности - то например Racket - понаглядней будет - там пример описания web-страницы на "собственном" языке в демо-примерах из 5 строк состоит, тот-же упомянутый sql - выражается так-же практически один в один sql. Но тем не менее если перемещаемся в раздел .Net и автокад - то да F# он как-то "повелесей" гораздо. Видео уроки я как-то не воспринимаю как материал (по программированию вообще), если показывать то надо "чувствовать" публику - либо хорошо расписывать - чтоб читатель сам вдумывался - с тем - чтобы хорошо расписать - у меня таланта не очень.
Пару своих "статей" я могу привести - они не то что для начальной стадии - но зато в разрезе автокада - если где не совсем понятно - поясню - спрашивайте.
1, 2