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

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

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

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

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


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


Почти нет никакой разницы между работать с entmake и генерировать dxf - одни и те же dxf-пары
И работу с dxf всегда можно спрятать в удобную обёртку
dxf плох лишь когда нужно работать с solid3d и прочим brep
trir вне форума  
 
Непрочитано 10.01.2017, 23:06
#42
zamtmn

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


trir
Разница оч большая.
Сохрани в автокаде пустой dxf >=2000
Открой в блокноте, попробуй чтонить добавить-убавить
zamtmn вне форума  
 
Непрочитано 10.01.2017, 23:14
#43
trir


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


А в чём проблема?
Миниатюры
Нажмите на изображение для увеличения
Название: dxf_viewer.PNG
Просмотров: 66
Размер:	110.4 Кб
ID:	181861  
trir вне форума  
 
Непрочитано 10.01.2017, 23:27
#44
zamtmn

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


Проблем нет. Есть ошибки и вылеты при попытке открыть в автокаде не очень валидный dxf. Документация кое-как годящаяся для чтения и никак для "генерации"... да мало ли чего.
В случае entmake думаю максимум - примитив отрисуется не так как залумано.
zamtmn вне форума  
 
Непрочитано 11.01.2017, 07:19
#45
ShaggyDoc

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


Цитата:
Сообщение от trir Посмотреть сообщение
Почти нет никакой разницы между работать с entmake и генерировать dxf - одни и те же dxf-пары
И работу с dxf всегда можно спрятать в удобную обёртку
dxf плох лишь когда нужно работать с solid3d и прочим brep
"Почти нет разницы" - это потому, что и то и другое плохо. Зачем человек должен разбираться и держать в уме какие-то нечеловеческие коды и пары?
Конечно, "можно" ко всему приспособиться. И в начале, когда ничего лучше DXF-кодов не придумали, приходилось это изучать. И сейчас приходится. Но теперь хоть альтернативы есть.

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

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

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


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

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

По моему претензий к форматам не должно быть никаких, главный их фатальный недостаток - отсутствие нормальных свободных бтблиотек для манипуляций с данными в этих форматах
zamtmn вне форума  
 
Непрочитано 11.01.2017, 15:46
#47
ShaggyDoc

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


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Идея внутренней хранения графических данных в XML - неправильная, он абсолютно неподходит для этого, только наружнее хранение на диске.
Ну, разумеется, данные хранятся на диске в файле. Только во время чтения парсер (причем стандартный) создает объектную модель в памяти в виде дерева элементов. И прикладному программисту надо только с ней и разбираться.

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

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

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

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

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

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

Цитата:
Сообщение от zamtmn Посмотреть сообщение
главный их фатальный недостаток - отсутствие нормальных свободных бтблиотек для манипуляций с данными в этих форматах
*
А у XML этого недостатка нет. В каждой среде имеются разные варианты, в зависимости от потребностей. Даже с "запросами", наподобие SQL в СУБД.
ShaggyDoc вне форума  
 
Непрочитано 11.01.2017, 16:54
#48
zamtmn

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


>>Только во время чтения парсер (причем стандартный) создает объектную модель в памяти в виде дерева элементов. И прикладному программисту надо только с ней и разбираться.
Обычно внутреннее представление графических данных - дерево классов 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, что там еще - это лишь способ сериализации внутреннего формата.

Последний раз редактировалось zamtmn, 11.01.2017 в 20:40.
zamtmn вне форума  
 
Непрочитано 13.01.2017, 16:40
#49
Do$

AutoCAD/Civil3D LISP/C#
 
Регистрация: 15.08.2008
Санкт-Петербург
Сообщений: 1,702
Отправить сообщение для Do$ с помощью Skype™


Цитата:
Сообщение от Enik Посмотреть сообщение
Offtop: Не надо сейчас про сивил, его функционал недостаточен. Шаг влево, шаг вправо от проектирования - и приходится дочерчивать всё руками.
Offtop: Есть кое-какие наработки по Civil 3d, которые сильно помогают в проектировании трубопроводов. Если интересно - смотрите тут: http://iteris-soft.ru/videos/iterisnets_project_sample
Будут вопросы - обращайтесь в ЛС или через контакты на том сайте.
__________________
Толковый выбор приходит с опытом, а к нему приводит выбор бестолковый. (The Mechanic)
Do$ вне форума  
 
Непрочитано 13.01.2017, 22:19
1 | #50
Enik

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


Цитата:
Сообщение от Do$ Посмотреть сообщение
Есть кое-какие наработки по Civil 3d, которые сильно помогают в проектировании трубопроводов.
Спасибо! Посмотрел видео с интересом и нескрываемым удивлением. Очень правильные и нужные вещи делаете. В принципе, с таким подходом и при такой технике работы ваши приложения могут быть полезны для ПТО в плане разработки исполнительной документации, а также исполнительных чертежей для геотреста.

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

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

Offtop: Без пафоса: как бывший проектировщик, чуть слюной не захлебнулся.
Enik вне форума  
 
Непрочитано 15.01.2017, 14:40
#51
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,840


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


 
Регистрация: 12.07.2009
г. Самара
Сообщений: 2,481
Отправить сообщение для maratovich с помощью Skype™


Пишите чаще и больше друзья.
Offtop: Пока другие делают...
__________________
Вопрос : Где находится Тургай ? Ответ : Между Парагваем и Уругваем.....
maratovich вне форума  
 
Непрочитано 15.01.2017, 21:47
#53
zamtmn

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


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

maratovich
непофлеймишь-неподелаешь
zamtmn вне форума  
 
Непрочитано 15.01.2017, 23:44
#54
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,840


Цитата:
Сообщение от zamtmn Посмотреть сообщение
Одна из основных причин - большая версиозависимость - чтото добавил\убрал в формат - ранее наработаное перестало нормально грузиться - приходится костылять
Если мы говорим про провайдеры типов - то все новое добавится при первой-же компиляции + плюс новое надо добавлять всего с учетом двух правил (не использовать select * ...), хотя в случае, например, linq такого и не будет (если посмотреть sql код запроса в который преобразуется linq выражение, там, даже если запрашиваются объект из всех полей, все равно они запрашиваются "поштучно"), тогда любое расширение можно добавить как null'абле поле, и в отличии например от xml есть уверенность, что никакой "левый" софт при обновлении данных не затрет неизвестные ему поля (если их нет в update - он их и не тронет, а вот если загрузил выгрузил - из xml то с большой вероятностью все что ему "не понадобилось" умрет при трансформации туда обратно - только малая часть софта оставит полную "родную" структуру - большинство просто запишет "свой" вариант). Ну и всегда есть 100% вариант - создавать новую таблицу с ссылкой на id поля в изначальной, куда и добавлять все что угодно, тогда и select * от чужого софта (или своего, предыдущей версии) не страшен.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 16.01.2017, 00:02
#55
zamtmn

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


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

>>Ну и всегда есть 100% вариант -
100% вариант - следовать общепринятому формату принятому в данной области
zamtmn вне форума  
 
Непрочитано 16.01.2017, 00:58
#56
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,840


Цитата:
Сообщение от zamtmn Посмотреть сообщение
следовать общепринятому формату принятому в данной области
Я бы сказал скорее их надо хорошенько просмотреть, чтоб понять на чем можно спотыкнуться - основные проблемы - это частенько дружат "профильные" форматы только с ASCII (то есть для нас - с русскими буквами там плохо), если форматы с ограниченным числом символов на поле - то "не лезет" бывает, количество записей ограниченно частенько и пр. Единицы свои любят еще вводить (в 1/360 мм например). А формат внутренний надо все-же использовать под свою объектную модель - особенно если имеем дело с "многосторонним" ПО (у меня например и для склада, и для КБ, и для бухгалтерии и для цеха (там как на бумагу, так и на ЧПУ) все в своих форматах из одной модели выводится).
з.ы. хотя нельзя не признать, иногда из-за изменений внешних обстоятельств в виде требований экспортной совместимости с каким-либо программным продуктом (или как следствие устройством под ним работающим), приходилось и частично "логику" программы менять; но тем не менее пока все равно обходилось без "революционных" перекроек.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 16.01.2017, 09:22
#57
baksconstructor


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


100500 тем про разработку и столько же обсуждений как лучше делать, но почему то дальше этого не продвигается.
Автор предложи maratovich нормальную цену и получи результат, пока идея окончательно не загнулась.
baksconstructor вне форума  
 
Непрочитано 16.01.2017, 09:32
#58
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,840


Это у Вас не продвигалось, я например, вынес для себя немало полезных направлений из подобного рода тем и вполне их продвинул. Допускаю, что и сам не зря тут иногда пишу.
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 16.01.2017, 10:08
#59
trir


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


Ещё раз хочу сказать, что на C# писать приятнее из всех современных языков, а самое главное - он позволяет достигать результата с минимумом усилий
trir вне форума  
 
Непрочитано 16.01.2017, 10:24
#60
Сергей812


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


Цитата:
Сообщение от trir Посмотреть сообщение
Ещё раз хочу сказать, что на C# писать приятнее из всех современных языков, а самое главное - он позволяет достигать результата с минимумом усилий
На Net языках, точнее. Это не достижение отдельно взятого языка, а логичный результат переноса частых задач программирования из разрозненных библиотек в один общий фреймворк на уровне операционной системы.
Сергей812 вне форума  
Ответ
Вернуться   Форум 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