[Supermax]

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

Я понимаю, что в блок можно вставить и значек с таким номером, и текст с формулой, но пока я о другом, это просто пример. Мне надо, чтобы значение свойства определенного элемента поменялось на определенное, другое значение. К примеру текст в элементе mtext в значке.

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

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

Можно и текст менять в таблицах, при этом он не будет с формулой, а чистый пречистый.
Более доходчиво идея описана в посте #70

[Дима_]

А не проще вообще никаких блоков не делать, а просто макрос который свойства меняет в соответсвии с текстом таблицы? Или я опять невьезжаю?

[Supermax]

Вот к примеру две линии и Mtext, который их связывает.

В первой формуле есть указатель на объект №1, а во второй - указатель на объект №2. Если договориться, что первая формула - ведущая, а вторая - ведомая, то прочтя макросом первую формулу, мы и объект найдем и свойство прочтем, затем прочтя вторую формулу - мы ведомый объект найдем, его свойство и приведем в соответствие длинну второй линии с первой.

[Supermax]

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

[Дима_]

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

[Supermax]

Таким макаром весь чертеж можно сделать динамическим и никакие дин. блоки просто не сравнятся по мощи инструментария.

[Supermax]

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

Добавлю:

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

[Кулик Алексей aka kpblc]

А чего меня звать, я и так гляжу за темой
У меня сразу вопрос: вот, допустим, связали отрезки. Надо увеличить их длину. Какая вершина (или точка отрезка) остается "на месте"? Кто и как это определяет?
ИМХО - бесполезная затея. Это же фактически просто дин.блок получится. Ну да, большой. Ну да, с неочевидными моментами. Но смысл?

[Дима_]

Но опять-же в 3d ничерта так не сделать, да и не только в 3д - области полилинии только если их целиком передвинуть остальные поля типа площадь - read only!
p.s. Пока писал предыдущий пост появился - удобно в тех. случаях когда надо параметрически чего- нибудь большое задать, а в дин. блоках для этого 51 ручку потянуть надо, а здесь вбил и готово.

[Supermax]

Я думал, что это я размахнулся, а это оказывается вы размахнулись, что я со своим размахом совсем потерялся.

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

В формуле можно написать столько всякой фигни, что и полилинию можно перестраивать и длины отрезкам менять с заданной точки и все, что угодно. Надо только условиться, что есть что и все. Кто макрос пишет, тот и диктует правила.

В обществе людей с вывихнутыми на программировании мозгами это называется формат записи.

Вот его давайте и обсудим. Бо перспектива дюже заманчивая.

[Supermax]

Возьмем за основу простой Mtext.
Как макросу отличить этот объект от простых mtext-ов?
Предлагаю в Hyperlink писать "Объект_связи"

Выбираем все Mtext-ы с Хуперлинком "Объект_связи"

Другой вариант - в начале строки текста писать ник создателя макроса. а перед ним знак доллара, на счастье.

Далее, как в лиспе следует имя функции, то есть некий термин, предполагающий совершение конкретных действий. Можно имя функции написанной на лиспе. Точно! Именно так и надо.

Далее аргументы для этой функции в виде чего угодно включая формулы с указанием на свойства конкретных объектов. Какая функция, такие ей и аргументы.

Например: $Kpblc text->distance_line (формула с указанием на объект Text или Mtext и его свойство Contents) ( формула с указанием на объект и свойство Start или End)

Cвойства Start и End содержат X, Y и Z координаты начала и конца линии. Если указан старт, то его функция пересчитывает на новое значение, взятое как производное от значения длинны из Contents текста и меняет старт, а если энд, то энд меняет.

Вот так, метка, имя функции из библиотеки и аргументы этой функции в виде данных и/или указателей на объекты.

Надо еще помнить, что в формулах можно считать, однако.

[Дима_]

Ты прав - в формате и есть вся проблема - я считаю вначале надо задачу поставить и цель - для чего этот код (формат) предназначен, а то, так до DFX дойдем - штука конечно хорошая, но все же хочется на более земном уровне автоматизацию получить. Главное по моему предусмотреть зависимость одного параметра от другого (то есть x=5, y=2*x-14), а потом результаты примитивам присваивать, скорее даже не примитивам присваивать, а действиям которые их создают (с предварительным удалением старых) - дабы можно было и в 3d залезть.

[Supermax]

В данном контексте (тот формат, что я предложил, по аналогии с форматом лиспа) все зависит от функции, которая и определяет состав дальнейшей записи. Надо ей три аргумента - пожалуйста, надо четыре - пожалуйста, надо просто коэффициент умноженный на данные свойства и т.п. - пожалуйста. 3D говоришь - да нет проблем. Кстати совершенно не обязательно указывать формулой именно доступные свойства, достаточно просто указатель на объект. А дальше написать название свойства к примеру.
Можно в скобках после метки писать функции и ее аргументы, так можно и несколько функций применять в одном указателе. Такой супер лисп забацать.

[Supermax]

Можно и действия совершать. Создавать требуемые объекты в требуемом месте опираясь на значения свойств других объектов.

Ой, че-то я такое придумал, аж самому страшно стало

[Profan]

Действия надо совершать с оглядкой.

[Supermax]

Последний аккорд на сегодня.

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

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

[Дима_]

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

[VVA]

Где-то близко к этой теме
http://www.sapracad.h.com.ua/

[Кулик Алексей aka kpblc]

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

[Supermax]

Kpblc, формула всегда зацеплена за объект не зависимо поменялся ObjectID или нет. Если он изменился у примитива, то автоматом меняется и в формуле.

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

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

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

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

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

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

Про возможность не корректного ввода - надо защищаться до определенного здравого смысла. Если пользователь ткнул не в тот элемент и указал не те свойства, то и гори его компьютер ярким пламенем!
Если от случайного или не корректного ввода может вылететь фатал егор, то надо думать, а если просто модель покорежит, так откатом исправят.

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

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

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