|
||
| Правила | Регистрация | Пользователи | Сообщения за день | | Поиск | | Справка по форуму | Файлообменник | |
|
Поиск в этой теме |
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Проблем нет. Есть ошибки и вылеты при попытке открыть в автокаде не очень валидный dxf. Документация кое-как годящаяся для чтения и никак для "генерации"... да мало ли чего.
В случае entmake думаю максимум - примитив отрисуется не так как залумано. |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
Конечно, "можно" ко всему приспособиться. И в начале, когда ничего лучше DXF-кодов не придумали, приходилось это изучать. И сейчас приходится. Но теперь хоть альтернативы есть. Но насколько удобнее использовать функции или методы с "человеческими" именами! И внешние данные гораздо удобнее хранить в "человеческом" виде, например в XML. Это все понимают, в том числе в Autodesk. Но шевелиться не спешат, потому что "пипл хавает". Вот про XAML сколько лет назад орали - "бу сделано". Идея-то замечательная - хранить в единой форме и внешний вид форм, и свойства контролов, и их действия. Могло бы быть единым для всех приложений. Но это же мозгой шевелить надо, а "пипл хавает". |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Имхо. Идея внутренней хранения графических данных в XML - неправильная, он абсолютно неподходит для этого, только наружнее хранение на диске.
>>Зачем человек должен разбираться и держать в уме какие-то нечеловеческие коды и пары? если я правильно понимаю "обертки" переводящие "нечеловеческие" коды в чтото человеческое делаются в 5 минут. Если это не сделано - значит особо никого не напрягает. DXF хороший формат - главное качество расширяемый, как минус его текстовость - возможность менять местами и пропускать некоторые пары, плохая документированость DWG - если отбросить то что туда добавлено для затруднения чтения сторонними средствами и отсутствие документации - очень хорошо продуманый бинарный формат, но не универсальный - много автокадспецифик сущностей. По моему претензий к форматам не должно быть никаких, главный их фатальный недостаток - отсутствие нормальных свободных бтблиотек для манипуляций с данными в этих форматах |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
Кроме того XML вообще имеет ряд преимуществ. Надо только чтобы он был "валидным", т.е. соответствовал простым правилам (вложенность элементов, явное открытие и закрытие тегов): 1. Можно вводить любые собственные элементы и атрибуты. Другие программы, которые их не знают, просто пропустят эти места. А своя будет знать, что с ними делать. 2. Можно редактировать как обычным текстовым редактором, так и специальными, отображающими структуру в виде дерева. 3. Вместе с графическими данными может храниться и семантическая информация. И даже можно в атрибуте держать текст функции (или ссылку на нее) для рисования таких объектов. И прочее, описанное в книгах по XML. Недостатком, конечно, является избыточные байты для тегов и имен элементов и атрибутов, но это превращается в достоинство - понятная читаемая информация. Но сейчас с большими размерами файлов нет проблем, а когда-то файлы стремились довести до двоичного формата именно ради размеров. Да из-за "секретности", чтобы добраться можно было по адресам, которые знал только разработчик. А не используют только из шкурных интересов производителей софта. Шоп "нигде кроме, как в Моссельпроме". А у XML этого недостатка нет. В каждой среде имеются разные варианты, в зависимости от потребностей. Даже с "запросами", наподобие SQL в СУБД. |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
>>Только во время чтения парсер (причем стандартный) создает объектную модель в памяти в виде дерева элементов. И прикладному программисту надо только с ней и разбираться.
Обычно внутреннее представление графических данных - дерево классов 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. |
|||
|
||||
Цитата:
Будут вопросы - обращайтесь в ЛС или через контакты на том сайте.
__________________
Толковый выбор приходит с опытом, а к нему приводит выбор бестолковый. (The Mechanic) |
||||
|
||||
ГИП Регистрация: 07.06.2015
Сообщений: 1,254
|
Цитата:
Да, подтверждаю, я увидел задел для решения комплексной задачи по строительству сетей, от проектирования и до сдачи в эксплуатацию. Примерно то же самое хочу сделать для себя, связав информационную модель с чертилкой в автокаде. Offtop: Без пафоса: как бывший проектировщик, чуть слюной не захлебнулся. |
|||
|
||||
Продуман Регистрация: 22.02.2007
Питер
Сообщений: 2,840
|
В добавление к оффтопу о хранении данных.
Я в последнее время (в общем уже и не малое), для хранения данных использую СУБД (в зависимости от задачи и "корпоративной обстановки" MSSQL, MySql, SQLite). Да тот-же XML, XLS(x) и другие гораздо менее популярные форматы я тоже использую, но только для экспорта в сторонний софт. Вся сериализацию/десериализацию в свои объекты происходит автоматом с помощью провайдеров типов, ими-же если данные достаточно сложные делаю и тот самый экспорт. Метод настолько удобен практически, что в сторону "классических" преобразований даже смотреть не хочется - реально забываешь про все ошибки данных любой сложности - и "крутить" их можно как хочешь. А хранение в стандарной СУБД снимает с себя необходимость разработки большей части API для сторонних разработчиков - просто даешь им "поясниловку" по полям таблиц и все - главное чтоб данные не загубили - но это уже их проблемы (я на практике в этом разрезе сталкивался в основном с 1С'никами - у них как правило вопрос только в чтении данных), плюс сразу решаешь все вопросы о "многопользовательстве", доступу, резервному копированию и пр. - все это уже есть "из коробки" на высшем уровне + не надо обучать (нормальные админы это и так знают) - в общем никаких велосипедов.
__________________
Когда в руках молоток все вокруг кажется гвоздями. |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Дима_
У меня с "автосериализацией" както несложилось. Одна из основных причин - большая версиозависимость - чтото добавил\убрал в формат - ранее наработаное перестало нормально грузиться - приходится костылять maratovich непофлеймишь-неподелаешь |
|||
|
||||
Продуман Регистрация: 22.02.2007
Питер
Сообщений: 2,840
|
Если мы говорим про провайдеры типов - то все новое добавится при первой-же компиляции + плюс новое надо добавлять всего с учетом двух правил (не использовать select * ...), хотя в случае, например, linq такого и не будет (если посмотреть sql код запроса в который преобразуется linq выражение, там, даже если запрашиваются объект из всех полей, все равно они запрашиваются "поштучно"), тогда любое расширение можно добавить как null'абле поле, и в отличии например от xml есть уверенность, что никакой "левый" софт при обновлении данных не затрет неизвестные ему поля (если их нет в update - он их и не тронет, а вот если загрузил выгрузил - из xml то с большой вероятностью все что ему "не понадобилось" умрет при трансформации туда обратно - только малая часть софта оставит полную "родную" структуру - большинство просто запишет "свой" вариант). Ну и всегда есть 100% вариант - создавать новую таблицу с ссылкой на id поля в изначальной, куда и добавлять все что угодно, тогда и select * от чужого софта (или своего, предыдущей версии) не страшен.
__________________
Когда в руках молоток все вокруг кажется гвоздями. |
|||
|
||||
Продуман Регистрация: 22.02.2007
Питер
Сообщений: 2,840
|
Я бы сказал скорее их надо хорошенько просмотреть, чтоб понять на чем можно спотыкнуться - основные проблемы - это частенько дружат "профильные" форматы только с ASCII (то есть для нас - с русскими буквами там плохо), если форматы с ограниченным числом символов на поле - то "не лезет" бывает, количество записей ограниченно частенько и пр. Единицы свои любят еще вводить (в 1/360 мм например). А формат внутренний надо все-же использовать под свою объектную модель - особенно если имеем дело с "многосторонним" ПО (у меня например и для склада, и для КБ, и для бухгалтерии и для цеха (там как на бумагу, так и на ЧПУ) все в своих форматах из одной модели выводится).
з.ы. хотя нельзя не признать, иногда из-за изменений внешних обстоятельств в виде требований экспортной совместимости с каким-либо программным продуктом (или как следствие устройством под ним работающим), приходилось и частично "логику" программы менять; но тем не менее пока все равно обходилось без "революционных" перекроек.
__________________
Когда в руках молоток все вокруг кажется гвоздями. |
|||
|
||||
Продуман Регистрация: 22.02.2007
Питер
Сообщений: 2,840
|
Это у Вас не продвигалось, я например, вынес для себя немало полезных направлений из подобного рода тем и вполне их продвинул. Допускаю, что и сам не зря тут иногда пишу.
__________________
Когда в руках молоток все вокруг кажется гвоздями. |
|||
|
||||
Регистрация: 10.08.2013
Сообщений: 11,053
|
На Net языках, точнее. Это не достижение отдельно взятого языка, а логичный результат переноса частых задач программирования из разрозненных библиотек в один общий фреймворк на уровне операционной системы.
|
|||
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Изменить порядок создания объектов в 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 |