XDLabel - создание надписей, связь надписей с объектами

Воть.

Вот тут даж хз, что бы пересобрать на 2007 нужен собственно 2007 и старые версии сред программирования, в целом dll библиотеке гораздо универсальнее чем arx, которые вообще под конкретную версию автокада делаются, с добавлением библиотеки кортежей мои программы с 2014 версии работали, но под 2007 сейчас я навряд ли соберу

 

Я не программист. Я технолог. Некоторые вещи мне просто не понятны.
Вы о кодах полей XData в целом или о структуре полей в нашем XDLabel или о другом?

Практическая задача в физической привязке надписей к объектами, чтобы надписи сразу следовали за объектами, ON-надписи перемещались только вдоль объектов.
И в возможности встроить это в XDLabel. (Или в создании полного и лучшего аналога на C).
Правда, нужно учесть, что пользователям может быть нужно и произвольно смещать надписи.

Полгода назад я специально создал тему об этом на dwg.ru. Как не-программист сделал вывод, что лучше не трогать.

 

alz, в моей работе уже есть практическое применение для вашей программы.
Можно довольно быстро подогнать площадь замкнутой полилинии до нужного значения.
Хорошо бы добавить возможность временного включения/выключеня функции автовывода площади и добавить выбор полилинии

 

Предлагаю перенести обсуждение самой DataLink не в контексте XDLabel и задачи в другую тему или в личную переписку, чтобы в этой теме не обсуждать иное.

 

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

--- Сообщения объединены, Jun 18, 2023, Оригинальное время сообщения: Jun 18, 2023 ---

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

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

 

Лан, подведем итоги, больше тут примеры выкладывать не буду а то ругают за оффтоп.
В общем имхо тут немного не такой подход к проблеме, потому и такое непонятное отношение к проекту. Любой проект должен быть для каких-то практических задач, По факту автор сейчас пытается продвигать инструмент для разработчиков как инструмент для пользователей, вот людям и не понятно нафига делать столько телодвижений.
Какая-никакая основа у автора уже есть, инструмент позволяющий связать объекты, внести какие-то данные и регенерировать модель что бы эти данные обновить. Для того, что бы инструмент стал рабочим его нужно обнести надстройками. Людям нафиг не нужна возможность сделать надпись на горизонтали через пачку действий: связать объекты, прописать в полях какие-то данные, что бы это работало и тд, имхо тут нужен именно подход: появилась задача - создался на основе инструмента плагин который по одному клику ставит на всех выбранных горизонталях отметки и связывает их.
Когда появится панель с пачкой плагинов под конкретные задачи, вот тогда это и будет инструмент для пользователей.
Что бы такие плагины появились на основе базового инструмента и была универсальность вам нужно сделать полноценную справку о вашем инструменте.
Например список типов объектов которые можно связать:
1) объекты с данными (тексты/мтексты/выноски/мультивыноски)
1.1) список типов данных, которые может отобразить этот объект с привязкой к возможности сохранить эти типы в xdata:
1.1.1) пользовательский текст
1.1.2) параметры связанного объекта (маркер связанного объекта/длины/площади/тип связанного объекта/углы какие-нибудь и тп)
1.1.3) параметры взаимодействия объекта с данными и связанного объекта (точка привязки, угол привязки и тп)
2) объекты параметры которых можно отобразить с помощью связанных объектов с данными (точка, кривая хз что там еще может быть)
2.1.1) структура связи (маркеры связанных объектов)
В целом на ум больше не приходит ничего, что было бы нужно хранить в базовом объекте.

Если такая документация будет то будет возможность делать плагины под частные случаи, например берем пример с подписыванием горизонталей:
1) запрашиваем у пользователя список полилиний
2) на каждую линию создаем мтекст в xdata которого вносится
а. хендл связанного объекта (полилинии)
б. параметр уровня высоты связанного объекта (отметка полилинии)
в. параметр точки привязки (ну например центр полилинии)
г. параметр угла поворота (например вдоль полилинии)
3) в полилинии создаем xdata с хендлом созданного мтекста что бы знать что обновлять при изменении полилинии (если планируется динамическое обновление или для того, что бы была метка что на этой полилинии мтекст уже есть и повторный создавать не нужно и была возможность через этот сохраненный хендл проверить что мтекс не удален например)
4) запускаем готовый инструмент обновления меток, который считывает данные xdata с меток и в соответствии с параметрами перестраивает метки (вот здесь и нужна стандартизация структуры данных, с которыми будут работать плагины на основе вашей разработки)

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

 

Всё это прекрасно, только потом всё равно придется пробежаться по всем вставленным подписям, чтобы устранить их накладки на другие объекты чертежа. Так что, проще расставлять подписи "вручную", щелкая по конкретной горизонтали в конкретном месте, тем более что не так уж много этих подписей и надо. Мною, например, написан лисп - щелкнул по горизонтали, в этом месте вставляется подпись с нужной её ориентацией и соответствующей отметкой. И этот пример показывает - " А оно нам надо!?"
TC опять на dwg.ru создал очередную тему ( https://forum.dwg.ru/showthread.php?t=168807 ), и опять его спрашивают - Зачем?

 

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

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

 

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

 

Это девиз девизов!

В проекте же это есть!
Вы либо не смотрели XDLabel, либо не обратили внимание, что там зарезервирована (пока не реализована) в кнопках возможность сохранять-загружать определения надписей. И уже сделано - нужно дать названия каждому определению. Либо использовать сформированное программой.
Задумано (по аналогии с тем, что есть в Map 3D, в другом ПО), что эти параметры можно сохранять в текстовых файлах, и подгружать при необходимости.
Запланирована команда типа "Менеджер надписей" (как менеджер слоев или т.п.) для удобства создания-удаления-скрытия-отображения и т.п. уже определенных надписей.

 

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

Разберем ваш пример
С помощью команд XDTOOLS и XDLabel:
Может показаться необычным () , но делается за 5 минут.
Начнем с конца, там самое простое
5. Обновить надписи XDLABEL_UPDATEL. команда обновления, тут вопросов нет, если что-то изменилось обновляет метку, интуитивно понятно.

Покумекав немного попытался понять что тут вообще происходит. В условиях задачи у нас требование сделать поворот текста вдоль полилинии.
Дано - 2 темы, в них по идее должна быть вся информация для того, что бы собственно сделать все нужные манипуляции "за 5 минут"
https://geodesist.ru/threads/otkryt...anie-svobodnyx-instrumentov-dlja-xdata.88990/
https://geodesist.ru/threads/xdlabel-sozdanie-nadpisej-svjaz-nadpisej-s-obektami.93537/
Начнем с того, что нам нужно связать 2 объекта, текст и линию, что бы программа при обновлении (XDLABEL_UPDATEL) поняла что текст зависит от линии и должен быть ей параллелен. Для этого требуется минимум точка на линии, в которой и будет искаться параллельность, так как горизонталь все же кривой объект и параллельность в может отличаться в разных точках, связь между объектами, что бы программа обновления знала параллельность к какой линии мы устанавливаем и маркер того, что именно угол и надо устанавливать. Собственно больше ничего и не требуется.
Теперь мы должны как-то присоединить эти данные к соответствующим объектам используя доступные инструменты.
Посмотрим какое решение тут выбрано:

1. Создать XData с полем для содержания этих надписей XDTOOLS_MDEFINE или командой XDATA из Express. Тип поля можно взять STr - символьное.
2. Присоединить эти XData к горизонталям XDTOOLS_ADD.

в пункте 1 и 2 мы создаем строку в хдату и присоединяем ее к горизонтали. Пока абсолютно не понятно зачем пустая дата в горзонтали, справки я не нашел.

3. Связать надписи и горизонтали XDLABEL_LINK.

запустил программу, выбрал полилинию и текст, вылезло окошко, все что доступно это ввести название связи, ввел и нажал ок

4. Редактировать XData связи надписей "XDT_LABEL" командой XDTOOLS_VEDIT:
- заменить значения в поле 7 на "ON",
- заменить значения в поле 20 на "10" - выравнивание Середина Центр (если было иное),
- заменить значения в поле 22 на "-360" - абсолютный поворот не определен,
- заменить значения в поле 23 на "0" - поворот относительно линий,
- заменить значения в поле 35 на (0.0 0.0 0.0), указав точку 0,0.

вот тут как раз и похоже что то на "присоединить эти данные к соответствующим объектам ", но к чему конкретно должны быть присоеденены эти данные что бы XDLABEL_UPDATEL понял? К линии или к тексту? Видимо к связи, вот тут стало вообще не понятно, что за такой объект, связь?
запустил команду предложило выбрать видимо объекты, текст выбрать не смог, в нем нет хдаты, хз что там сделал XDLABEL_LINK. при выборе линии открылось окошко с одинокой пустой строкой, сделанной в пункте 1 и подвязанной в пункте 2, никаких полей и значений там не было, собственно на этом попытка работы этим инструментом подошла к концу, ушло на это кстати минут 40, минимум, это при том что я хотя бы понимаю что такое хдата и как хотя бы теоретически должны связываться объекты.

Остались вопросы.:
1) Зачем пустая хдата на объекте
2) Что такое связь? Где она хранится?
3) Где полный список кодов из пункта 4?

В общем пока что инструмент выглядит абсолютно неюзабельным.

 

В стартовом сообщении после перечисления команд XDLabel написано:

Это да. И скриншоты не помешают... Просто не успел - ведь только-только выложил. Сил не было сразу сделать...

Чтобы туда записывать содержание надписей - для существующих надписей. Если там не пусто, то можно из этого создать надпись XDLABEL_CREATE.

Связь - это XData с названием "XDT_LABEL". Хранится в надписях.

Там же пока, где и видео... В принципе, пользователям про это лучше не знать - легко испортить. Вы взяли действительно сложный случай. Он может запутать.

Еще там очень важен допуск - если расстояние между надписью и объектом больше, то связь не создастся. Если допуск остался 0, то, скорее, у Вас связь не создалась. В комокне есть отчет о количестве.

XData связи создается XDLABEL_LINK при надписях. Или после XDLABEL_CREATE у созданных надписей. Содержание текстов записывается или берется из указанной XData объекта, его указанного поля.

 

Вот тут у вас противоречие, вы позиционируете все это как универсальный инструмент, следовательно как раз эта основа и должна использоваться для решения любых задач, но как это делать если половина инструмента не должна быть пользователям известна?

Например, опишу структуру моей метки длины/площади:
при выборе пользователем линии создается надпись, базовая точка прикрепления - центр бокса линии.
в линию записывается xdata

ExtendedDataRegAppName - название приложения "CurveLinkData" что бы определять что с этой линией что-то связано и метод обработки
подпункты приложения:
ExtendedDataHandle - хендл созданной надписи что бы определять что именно связано (служебная информация, доступа у пользователя нет и не нужна)

в xdata текста записывается:
ExtendedDataRegAppName - название приложения "MTextLinkData" что бы определять что с этим текстом что-то связано и метод обработки
подпункты приложения:
1) ExtendedDataHandle - хендл линии, с которой связан текст (служебная информация, доступа у пользователя нет и не нужна)
2) ExtendedDataAsciiString "dx0.000000"
3) ExtendedDataAsciiString "dy0.000000"
4) ExtendedDataAsciiString "dz0.000000"
относительные смещения текста от базовой точки вставки (служебная информация, доступа у пользователя нет и не нужна)
служебная она, потому что обновляется автоматически при переносе текста стандартными инструментами автокада, пользователю она нафиг не нужна, он текст подвинул, куда ему надо, и это сохранилось что бы использоваться при изменении линии.
5) ExtendedDataAsciiString "Length3d" - строка с маркером того, что в тексте должна быть длина
6) ExtendedDataAsciiString "Area" - строка с маркером того, что в тексте должна быть площадь
вот эти 2 пункта уже должны быть полностью на совести пользователя, в полноценной версии программы естественно, по умолчанию программа не должна их добавлять, а оставлять на откуп пользователю, захотел пользователь что бы метка длину указывала, добавил "Length3d" строковым параметром к xdata приложения, соответственно все эти коды, которые не относятся к служебным должны быть в открытом доступе.

соответственно
- заменить значения в поле 7 на "ON",
- заменить значения в поле 20 на "10" - выравнивание Середина Центр (если было иное),
- заменить значения в поле 22 на "-360" - абсолютный поворот не определен,
- заменить значения в поле 23 на "0" - поворот относительно линий,
- заменить значения в поле 35 на (0.0 0.0 0.0), указав точку 0,0.

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

--- Сообщения объединены, Jun 20, 2023, Оригинальное время сообщения: Jun 20, 2023 ---

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

 

Естественно, опишу-выложу и структуру связи и пр.

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

Да, я сразу посмотрел как Вы описываете связи.

Вам собственный вариант и привычные подходы не дают понять задачу в общем виде. Надписывать геометрические свойства - лишь частный случай и совсем не основная необходимость.
Вы еще не вчитались в Начнем с начала (о надписях) и пр.

1. В XDLabel связь хранится в связанном объекте, т.е. у надписи. Этот вариант подглядел у ГИС-овцев, где этими делами занимаются еще с 60-х. Но сейчас же эксперимент. Возможно, Ваш вариант окажется лучше. Или что-то среднее и т.д.
Т.е. сейчас с XDLabel определение связи хранится только в специальной XData надписи, в "XDLABEL_LINK".
2. "уже созданная заранее какая-то xdata" - это место, откуда берется содержание надписей. Оно должно быть в объекте, т.к. надписи создаются для объектов, из информации об объектах.
В общем случае на планах/чертежах надписи отражают не графические свойства, только о которых Вы думаете. Они тоже, но в наименьшем количестве случаев или их вообще не надписывают. В общем случае содержание надписей - неграфические описательные данные об объектах. Названия объектов, номера, назначение, материал, вольтаж и пр., и пр.
См. самый наглядный случай - кадастровые данные, где большая часть сведений об объектах текстовая, из документации.
Для хранения этих данных и нужны XData при объектах. Заодно туда можно поместить и данные о геометрических свойствах - чтобы не плодить инструменты.

 

Да, видимо я просто немного с другой стороны смотрю на ситуацию, вы смотрите на ситуацию только со стороны надписи, собственно да, вам пофиг как называется хdata у примитива, к которому она прицеплена, обрабатывается только надпись, в случае нужды в данных связанного объекта просто смотрится в ее свойствах и на этом все, что там записано в в объекте по большему счету пофигу, так как обращение вашей программы обновления идет на надпись.
У меня же надпись и связанный объект равны по статусу, если происходит какое-то изменение программа обработки может обратиться и к надписи, если что-то произошло с ней и к примитиву, если изменения были у него, соответственно стандартизированные записи в xdata требуются и у примитива и у надписи, и они ссылаются друг на друга, поэтому при связывании они одновременно и стандартно записываются в оба объекта и ничего заранее готовить не требуется. В целом никто не мешал вам убрать этот костыль предварительного добавления пустой xdata автоматическим добавлением xdata типа dataXXX где XXX это любое, не присутствующее в текущем объекте число, во время срабатывания компонента LINK, что прилично упростит вашу систему.
В целом, если будет полная справка по структере данных в вашей метке, то я могу включить ее в свою программу динамической обработки, вроде как в этой системе ничего особо сложного нет, но для полноценной работы потребуется стандартизация в xdata и объекта, к которому ваша метка будет прицеплена.

 

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

 

Их статусы равны в привычной всем CAD системе "графическая модель" (vs "модель объектная"). Да, мы к этому подходу привыкли, он для нас, CAD-овцев, "естественен", "очевиден", но это только стереотип, ограниченное восприятие. Графические модели изначально неполноценны, некорректны, недостаточны.
Надписи совсем не равны основным объектам моделей своей сутью - это иллюстративные, оформительские, т.е. необязательные, дополнительные и всегда зависимые объекты. Надписи являются избыточными для содержания чертежей/моделей объектами, они создаются только для восприятия непосредственно людьми.

Да, я тоже давно подумываю сделать подобную возможность.
Но! Вы сейчас по-привычке смотрите на наличие описательных данных в объектах как на нечто избыточно-ненужное или необязательное. Невесть зачем и откуда берущееся вдруг. По моей прихоти-недоразумению.
А описательные данные уже должны быть в объектах - обозначая типы объектов реальности, и определяя их характеристики. Их лучше сразу добавлять при создании объектов или добавлять после вычерчивания. Т.е. не должно быть никакой "пустой xdata" или искусственных "xdata типа dataXXX" - описательные данные (в XData, словарях или в пр.) должны быть уже определенными, говорящими о сущности-типах объектов.

--- Сообщения объединены, Jun 20, 2023, Оригинальное время сообщения: Jun 20, 2023 ---

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

 

Вы немного не поняли о чем я написал, вы приоритезируете текст тем, что ваша связь находится именно в нем, ваша программа не может взять в обработку связанный с ней объект кроме как через нее, это и накладывает ограничение на команду обновления, она может только обновить все объекты на чертеже, внутри которых находится связь.
Мой же подход это связь грубо говоря во всех объектах и избирательный подход, команда обновления срабатывает каждый раз, когда происходит изменение или в тексте, или в связанном с ним примитиве, имеющих собственно в себе связь, причем через что работать не важно, изменился текст -> поменялся примитив или наоборот, поэтому связт и должна быть типизирована во всех объектах, а не только в тексте.