[zamtmn]

Всем привет!
В свободное время делаю для себя небольшую CAD программу - всегда было интересно как это работает внутри.
На данный момент есть следующие наработки:

• Довольно быстрый OpenGL рендеринг чертежа
• Кроссплатформенность (Windows/Linux, x86/x64, win/gtk/qt)
• поддержка подмножества DXF версии 2000
• поддержка SHX, TTF шрифтов
• поддержка типов линий
• поддержка примитивов POINT, LINE, CIRCLE, POLYLINE, LWPOLYLINE, ARC, ELLIPSE, INSERT, TEXT, MTEXT, 3DFACE, SOLID, SPLINE
• некоторые потуги автоматизации слаботочных разделов проекта

Cтраничка программы на SourceForge
Cтраничка программы на GitHub
Cтраничка программы на Ohloh

Программа пишется на паскале, компилируется в Lazarus/FPC. Исходный код открыт и лежит в SVN репозитории Git репозитории
Текущую сборку программы можно взять тут, но лучше тут (более менее свежие сборки для Windows_x86 и для Linux_x86_64, другие - стареханькие). Для работы требуется аппаратная поддержка OpenGL на целевом компе
Также программу можно собрать самомтоятельно, для этого понадобятся:

• релизный Lazarus версии не менее 2.0.10 на базе FPC версии не менее 3.2

Программа не требует установки и не пишет\читает ничего в системные папки (за исключением TEMP) Под windows не допускаются кирилические (и другие) символы в пути к программе (в путях к dxf файлам допускаются), linux версия такой болезнью не страдает.

Для запуска доступны следующие ключи командной строки:

• NLL - отключение загрузки файла докинга окон, окна открываются непристыкованными, но докинг работает
• SI - полное отключение докинга, зкад работает в однооконном режиме (очень недоделанном)
• UPDATEPO - отключение закрузки локализации, будет запущена английская версия. Также в этом режиме доступна команда обновления файлов локализации
• NOSPLASH - отключение показа окна загрузки
• путь/к/файлу.dxf - открыть указанный файл

Любые замечания/предложения приветствуются!

[veb86]

Сообщение от АлексЮстасу Во-первых, чертить цельные объекты многими отрезками - все равно, как составлять тексты из отдельных букв.

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

Сообщение от АлексЮстасу Что лишнего и "нагружающего" может быть в информации о том, какой объект отображен, и какие у него характеристики? Я-то думаю, что это такая же основная информация, как и геометрия. Кроме того, при появлении у графики определений объектов появляются новые полезные возможности - поиска по названиям объектов, восстановления графических свойств, если что-то случайно или специально перекрашивали, меняли слои и пр. И ряд других.

Тут я ничего не понял вот круг, вы открыли характеристику и написали бочка, и что теперь для программы это бочка. Так делать я считаю не стоит. Круг - это круг. Пользователь должен осознавать что сейчас он чертит линию, или кабель, или трубу и самое главное что программа это тоже понимала. Мне стало интересно понять ход ваших мыслей, но я их не улавливаю. Не посылайте меня в блог OD/BD там много чего читать, плохой перевод. коротенько вы по любому раскладывали свои мысли по полкам в другом месте...

[АлексЮстасу]

Сообщение от veb86 от как вы сделаете разветвление полилинией?

В принципе, есть, минимум, два варианта:
1) участок до разветвления дать одной полилинией, к которой привязать столько соответствующих записей расширенных данных, сколько она отображает "кабелей",
2) участок до разветвления дублировать графически столькими полилиниями кабелей, сколько их есть.
Я сторонник первого варианта.
Ничто не мешает к одному графическому элементу привязывать несколько записей расширенных данных. В данном контексте - определять элементы как типы объектов. Т.е. как кабели, стены и пр.
В том числе одну линию можно таким способом определить не только как несколько однородных объектов, но и как разнородные объекты. Допустим, в каких-то случаях те же кабели и каналы для них можно отобразить одной линией, определив ее и как кабели, и как канал. И т.п.

Сообщение от veb86 Скажите хоть одну программу у которой базовая полилиния имеет дополнительные характеристики, сечения, толщина стенки трубы? я хочу на это посмотреть

Я тоже хочу на такой CAD посмотреть! А еще - иметь. Именно в этом суть моих предложений о построении CAD. Там оч. коротко.

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

Бочку достаточно описать только графическим элементом круг в том случае, если мы рассчитываем только на визуальное восприятие и интерпретацию непосредственно человеком. Т.е. создаем графическую модель - модель, рассчитанную на идентификацию, интерпретацию человеком. Если же мы хотим создать модель "информационную", т.е. полностью пригодную и компьютерной обработке, то нужно этот круг определить. Моделью чего он является. Бочки, допустим.
Если же встроить в сам CAD процесс определения элементов, сделать неразрывным графику и семантику, то не нужно отдельного процесса определения - выбрал черчение круга с обычной кнопки/команды CIRCLE, в меню появится объект "окружность_N", изменил это название на "бочка", и черти круги==бочки пока мышь не сдохнет. В другом файле подгрузил этот файл описания объектов, раздал сотрудникам, субподрядчикам и пр. этот файл описания - и бочки чертятся у всех одним примитивом, в одном слое, цвете и т.п.

[Boxa]

Сообщение от veb86 Скажите хоть одну программу у которой базовая полилиния имеет дополнительные характеристики, сечения, толщина стенки трубы? я хочу на это посмотреть. Конечно если это не спец софт.

Это ADT 2014:

А вообще на работе последние лет 5 так и работаем, базовая линия стен имеет некоторое описание (армирование, выпуска, диаметр труб) и по этим линиям и описаниям создается спецификации. Все в базовом автокаде.

Я внимательно слежу за дискуссией, но последнее время перестал понимать суть...

[АлексЮстасу]

Сообщение от Boxa А вообще на работе последние лет 5 так и работаем, базовая линия стен имеет некоторое описание (армирование, выпуска, диаметр труб) и по этим линиям и описаниям создается спецификации. Все в базовом автокаде. Я внимательно слежу за дискуссией, но последнее время перестал понимать суть...

Пардон за предположение - возможно, что мы с Вами под расширенными данными понимаем разное. Я имею в виду не эти "расширенные данные" из закладки Свойства, а аналоги автокадовских XData, XRecord. С их помощью можно привязать к элементам практически любого объема и содержания описательную информацию прямо в dwg. И в них описать все необходимые характеристики объектов в виде полей данных нужного формата, в которые можно записывать значения этих характеристик. Т.е. не в одном поле "Notes" все сразу. А, например, свое поле для диаметра, свое - для толщин стенок. А также поля для назначения, материала, производителя и пр., и пр. Соответственно, можно производить ввод, редактирование значений характеристик прямо в Автокаде при черчении объектов. И можно организовать поиск в dwg по значениям в этих полях, пр. анализ и подсчеты.
Одно из полей во всех таких записях можно специально отвести под идентификаторы типов объектов. Где будет записано название типов объектов - "кабель", "стена", "бочка" или т.п.
Т.е., если в CAD сразу соединить графические элементы с их описательными данными, то чертеж из модели графической превращается в модель "информационную". Причем, без особых дополнительных усилий пользователя.

[veb86]

Сообщение от Boxa А вообще на работе последние лет 5 так и работаем, базовая линия стен имеет некоторое описание (армирование, выпуска, диаметр труб) и по этим линиям и описаниям создается спецификации. Все в базовом автокаде.

Про это не знал, потому что последние 4 года работал на лицензионном bricscad 2009 (тихий ужас) и последние 2 года на 2014 (по лучше, но до 2008 автокада еще работать и работать) Нас таких двое привилегированных (продвинутых в плане ПО) в конторе, остальные на 2009 сидят. Это глубинка! Поэтому новые фишки автокада не знакомы((( Совершено с Вами согласен, такая фишка реально ускорила бы жизнь, если бы у нас такое было

Сообщение от Boxa Я внимательно слежу за дискуссией, но последнее время перестал понимать суть...

я тоже плохо понимаю, статью которую мне предложили вчера я прочитать не успел.
Но мне кажется что АлексЮстасу хочет, что бы в свойствах любого объекта можно было добавлять свойства, типа кнопку нажал добавилось поля, присвоил имя полю, дал значение и потом этот объект копируешь вместе со свойствами. Потом фильтр запустил поиск по свойствам и нашел что нужно. Это конечно было бы удобно, только для поиска, создания спецификаций, но все что так добавить не будет взаимодействовать с другими объектами, взаимодействие надо описывать от источника до потребителя - серьезный расчет не возможно поместить в таблицу (пример Эксел 2007 циклов нет, в новых не знаю), потому что много циклов, промежуточных величин, анализа.
Обязательно попозже прочитаю статью.

[zamtmn]

АлексЮстасу

Пардон за предположение - возможно, что мы с Вами под расширенными данными понимаем разное. Я имею в виду не эти "расширенные данные" из закладки Свойства, а аналоги автокадовских XData, XRecord. С их помощью можно привязать к элементам практически любого объема и содержания описательную информацию прямо в dwg. И в них описать все необходимые характеристики объектов в виде полей данных нужного формата, в которые можно записывать значения этих характеристик. Т.е. не в одном поле "Notes" все сразу. А, например, свое поле для диаметра, свое - для толщин стенок. А также поля для назначения, материала, производителя и пр., и пр. Соответственно, можно производить ввод, редактирование значений характеристик прямо в Автокаде при черчении объектов. И можно организовать поиск в dwg по значениям в этих полях, пр. анализ и подсчеты.

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

дно из полей во всех таких записях можно специально отвести под идентификаторы типов объектов. Где будет записано название типов объектов - "кабель", "стена", "бочка" или т.п.

Это спорно. Полилиния какбы кабель и полилиния какбы стена? Если всеравно для нас это кабель и стена зачем какбы?

Boxa

А вообще на работе последние лет 5 так и работаем, базовая линия стен имеет некоторое описание (армирование, выпуска, диаметр труб) и по этим линиям и описаниям создается спецификации. Все в базовом автокаде.

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

Я внимательно слежу за дискуссией, но последнее время перестал понимать суть...

Я уже тоже не очень в сути. Народ тянет потеоретезировать

[АлексЮстасу]

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

Что за этап компиляции?
И не оч. понимаю, а каким элементам чертежа не нужно определять, что они отображают?

Сообщение от zamtmn Причем привязывать не просто текстовые значения а типизированые данные: целые, вещественные, ссылки, и главное перечислимые типы

Да, конечно! Это позволит вводить только допустимые значения.

Сообщение от zamtmn Это спорно. Полилиния какбы кабель и полилиния какбы стена? Если всеравно для нас это кабель и стена зачем какбы?

Как это - спорно?..
Или Вы как-то иначе определяете, что вот эта полилиния - стена, а эта - кабель? Как вообще без этого? Как это - все равно? В каких случаях это может быть все равно - кабель начерчен или стена?

Сообщение от veb86 Это конечно было бы удобно, только для поиска, создания спецификаций, но все что так добавить не будет взаимодействовать с другими объектами, взаимодействие надо описывать от источника до потребителя - серьезный расчет не возможно поместить в таблицу

Я не предлагаю решить одним способом все задачи. Описанный в блоге подход в первую очередь предназначен для облегчения, улучшения черчения, создания моделей, сбора, описания базовой информации об объектах. При этом все данные представляются в виде уже пригодном для полного программного анализа или манипуляций.

Сообщение от Boxa последнее время перестал понимать суть...

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

[zamtmn]

АлексЮстасу

Что за этап компиляции? И не оч. понимаю, а каким элементам чертежа не нужно определять, что они отображают?

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

Как это - спорно?.. Или Вы как-то иначе определяете, что вот эта полилиния - стена, а эта - кабель?

При моем подходе полилиния\стена\кабель - это разные примитивы. Пусть по сути это простая полилиния с чуть разным поведением и своим набором "расширенных" данных, но всё завернуто в разные примитивы.

ИМХО то что Вы описываете в статьях имеет смысл в виде "меню стилей" или чертежных стандартов. "Расширенные" данные в него тянуть не надо, т.к. сами по себе эти данные смысла никакого не имеют - нужна программа их обрабатывающая. Логично в эту программу запихнуть и функционал манипуляции данными. Судя по картинкам в статьях - функционал отображения "данных" в окне свойств у вас есть, не "глобализируйте\универсализируйте", решайте свои конкретные задачи

[Сергей812]

Сообщение от zamtmn т.к. сами по себе эти данные смысла никакого не имеют - нужна программа их обрабатывающая

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

[АлексЮстасу]

Сообщение от zamtmn При моем подходе полилиния\стена\кабель - это разные примитивы. Пусть по сути это простая полилиния с чуть разным поведением и своим набором "расширенных" данных, но всё завернуто в разные примитивы.

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

Сообщение от zamtmn ИМХО то что Вы описываете в статьях имеет смысл в виде "меню стилей" или чертежных стандартов. "Расширенные" данные в него тянуть не надо, т.к. сами по себе эти данные смысла никакого не имеют - нужна программа их обрабатывающая. Логично в эту программу запихнуть и функционал манипуляции данными.

Сообщение от Сергей812 Давно пытаюсь подвести Александра к этой мысли - что без обработки данных это все полузаготовка.

Вы совершенно правы - я не предлагаю решение всех задач CAD. Я предлагаю начать с первой их задачи. Но с прицелом на остальные.
Предлагаю расширить возможности в первую очередь именно черчения, сбора данных за счет идентификации графических элементов как объекты и описания их характеристик. И тем самым превратить чертежи из чисто графических моделей в "информационные", сразу при черчении, задать в унифицированной форме основную нужную информацию об объектах. Благодаря чему будет удобнее, проще решать остальные задачи - то, что вы подразумеваете под манипулированием, обработкой.
Исхожу из того, что черчение==создание моделей - это первая задача CAD. Просто технически, хронологически. Очень часто - и главная, и единственная. Последнее - про тех самых примерно 70-80% пользователей, предпочитающих базовый Автокад. Для многих из них (неизвестно для скольких) использование CAD ограничивается процессом вычерчивания и визуального анализа. Да, многие из них (пусть даже большинство) используют самые разнообразные вспомогательные программы для анализа этих моделей, расчетов, подсчетов и отчетов. И разнообразные способы идентификации графических элементов как объекты и описания их характеристик. Так почему бы сразу не обеспечить всех пользователей достаточным способом описания этих данных? Что заметно ускорит, упростит подготовку данных. И в унифицированной форме, что облегчит создание программ обработки и подсчетов. Тем более, что сделать это технически несложно, и ускоряет, улучшает уже само черчение.
Да, это меньше, чем все, но это же немало.
Вот о том, как решить эту задачу оптимальнее, удобнее для анализа, манипулирования данными и т.п. - это, конечно, вопрос.
Например, ваши мнения уже противоречат друг другу - Вы, zamtmn, считаете расширенные данные подходящим средством, а Вы, Сергей812, считаете их неудобными.

[Сергей812]

Сообщение от АлексЮстасу Например, ваши мнения уже противоречат друг другу - Вы, zamtmn, считаете расширенные данные подходящим средством, а Вы, Сергей812, считаете их неудобными.

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

[АлексЮстасу]

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

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

[Сергей812]

Сообщение от АлексЮстасу А, заодно, есть удобная альтернатива расширенным данным для описания характеристик?

если корпоративная система - то БД однозначно (заодно вынести туда все настройки по слоям и т.д. Это также защитит частично программу - без БД даже рисовать не получиться нормально). Если локально - то тоже можно БД, xml, бинарник - вариантов много. Но от расширенных данных все равно не уйдете - идентификатор БД придется писать куда то.

Сообщение от АлексЮстасу Для обработки выгружать в удобный вид. В какой бы, кстати? Что порекомендуете?

ну если хотите опять универсальности - то посмотрите реализацию LINQ, например. Хотя это не панацея. Для начала надо сформировать правила обработки, иначе получиться очередной промежуточный костыль. А правила обработки для каждого раздела отличаются.

p.s. может все таки не будем в чужой ветке писать опять про вашу программу?)

[АлексЮстасу]

Сообщение от Сергей812 p.s. может все таки не будем в чужой ветке писать опять про вашу программу?)

Зря так пишете - я в эту тему зашел с не реализованной никак еще идеей о возможном подходе к построению CAD.
Если zamtmn не захочет обсуждать перспективность использования расширенных данных, альтернативы им - испарюсь немедленно. Но может же быть и наоборот - вдруг zamtmn идея понравится? Да и обсуждается же то, что в ZCAD сделано, как сделано или может быть сделано.

Сообщение от Сергей812 если корпоративная система - то БД однозначно (заодно вынести туда все настройки по слоям и т.д. Это также защитит частично программу - без БД даже рисовать не получиться нормально). Если локально - то тоже можно БД, xml, бинарник - вариантов много. Но от расширенных данных все равно не уйдете - идентификатор БД придется писать куда то.

Идею внешней БД на стадии создания чертежей, моделей я (пока что) полностью не поддержу. Массовому пользователю, по-моему, не подходит - слишком сложно.
А, вот, что "от расширенных данных все равно не уйдете" вдохновляет
По-моему, пока что они - самое удобное. Начертил что-то - оно уже идентифицировано, уже есть поля для характеристик, уже описаны ограничения для значений в полях. Сразу доступны для выбора по идентификаторам, по значениям характеристик, сразу можно как-то манипулировать. И все предельно компактно, просто - практически не сложнее, чем обычный графический чертеж.

[veb86]

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

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

задача десятилетия: "описание программы АлексЮстасу" . Буду говорить о себе, мое не понимание упирается изначально в то что я электрик и рассматриваю задачу со своей колокольни, у меня не так много УГО(их много но ходовых не так что бы уж прям) и они все как правило блоки. А АлексЮстасу топограф, у них обозначений море, полный полет фантазии, линию начертил вот вам деревянный забор, другая линия бордюрный камень и т.д. поэтому его и смущает подход когда все оборачивать примитивами, при топографии примитивов реально много надо создавать и никогда не знаешь что еще появится или придумаешь нового. Вот какое решение я вижу, если что подправте:
1. вам надо создать меню которое хорошо будет общаться с БД, возможно даже показывать картинки(на памяти у меня только tangentools https://yandex.ru/images/search?text...oreask=1&lr=49, но она работала с блоками, а вам лучше БД xml было бы здорово)
2. внутри этого меню сделать кнопки (линия, полилиния, вставить, копировать, создать), выделил элемент из меню (бетонный забор) нажал кнопку "полилиния" определенную, и ей чертишь, со свойствами которые заранее заложены в меню. Выбрал элемент лиственное дерево, вставил или копировал что бы вставка зацикленная была.
3. после всего этого можно уже анализировать весь полученный массив лини с расширениями и ими манипулировать.
4. думаю основные линии трогать не надо(пускай полилиния останется полилинией), а Ваша полилиния будет называться как то по особенному. (Это вопрос для обсуждения вообще не ясно, как лучше нужно по работать что бы понять в любом случаи объединить потом полилинии будет не сложно)

Что нужно что бы это сделать, Вам нужны адепты которые будут программировать, не знаю уж на базе чего вы захотите это видеть, но ZCAD не плохая платформа, тем более открытая. Ищите программистов, договоритесь zamtmn что бы разграничить узкие места или как то их решить сообща и проблема решена... Сразу скажу я падаван в программировании, мне такое не под силу и возможности такие не очень нужны, я в первую очередь все равно решаю свои задачи, свои проблемы...

[АлексЮстасу]

Сообщение от veb86 задача десятилетия

Да, здесь тема zamtmn, и обсуждать здесь не его идеи стоит только в той мере, в какой он заинтересован.

[zamtmn]

Всем здравия.
Давно не появлялся, но проект живет потихоньку.
Обдумываю одно небольшое, но очень перспективное нововведение. На данный момент различные дополнительные свойства устройств хранятся отдельно в этих самых устройствах. Например "представление" устройства на схеме автоматизации и "представление" устройства на плане - при изменении например свойства эл.мощности в одном, в другом она останется неизменной, а при изменении например имени одного устройства, они вообще "разъедутся" - станут разными. Надо эти параметры централизовано хранить гдето в одном месте.
Варианты:
1 - Централизовано хранить гдето вне чертежа все устройства имеют ссылки на место хранения
2 - Централизовано хранить в одном из устройств на чертежа все остальные устройства имеют ссылки на "главное" устройство, при удалении "главного" устройства "главным" станет другое представление
3 - Ввести новую сущность - определение устройства - невидимый блок, не удаляемый обычными средствами, остальные устройства имеют на него ссылку.

1 - вроде как самый правильный, но затратный, т.к. эту внешнюю сущность надо реализовать.
2 - попроще, на данном этапе не приведет к тотальной переделке существующего кода, в дальнейшем позволит менее болезненно свалить на первый вариант при необходимости.
3 - самый простой в реализации, но кроме "централизации" плюсов не несет никаких.

С удовольствием выслушаю, если кому есть что сказать по теме. Да и без темы тоже))

[Сергей812]

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

[zamtmn]

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

[Сергей812]

Сообщение от zamtmn Изза этого путаница одно и тоже может быть там и тут.

так для этого и писал

Сообщение от Сергей812 и ссылки на устройства тоже

поменяли в чертеже - обновили информацию в центральном хранилище. Поменяли информацию в центральном хранилище - сразу по ссылках обновили информацию в чертежах (открывая в фоновом режиме при необходимости).