Делюсь опытом по скриптам исполнений или почему ручной способ формирования кода несет больше "плюшек"

[LogicID]

Данная тема выродилась из моей темы, опубликованной ранее темы на форуме:

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

[LogicID]

Теперь исполняю свое обещание! Имеем "интересный" объект с двумя исполнениями (придумал таки для примера), созданный мною именно для выкладки на данный форум.

Исполнение 1 (много сопряжений):

Исполнение 2 (динамически создаваемые точки):

Вложение:

Объект для форума.zip

 

ЗАДАЧА: попытаться создать такие же исполнения стандартными средствами СПДС. В коде добавлены нужные комментарии. Смотрите для знаний!

Но пробовать создавать надо только стандартными средствами!!!

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

И раз от разработчиков не поступает информации, то просто скажем им спасибо за возможности СПДС....и будем самостоятельно учиться разбираться в программном коде!

 

P.S. второе исполнение - это часть моего более сложного элемента (кодом заодно считается периметр и площадь), решил его показать для ознакомления. Количество точек полигона не ограничено (при инициализации - 6, но можно поменять на панели свойств).

Edited November 18, 2021 by LogicID

[LogicID]

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

В первую очередь, для себя... но для продвинутых пользователей она тоже пригодится.

 

[MCAD]

Я поражён ...

 

добавлено через 6 минут

Ну, первое исполнение можно попробовать через "рабочие" Объекты. Второе никак. 

[LogicID]

4 минуты назад, MCAD сказал:

Я поражён ...

 

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

[LogicID]

21 минуту назад, MCAD сказал:

Ну, первое исполнение можно попробовать через "рабочие" Объекты. Второе никак. 

Если получиться, мне будет интересно ознакомиться. Про лаконичность и чистоту ручного кода исполнения пока забудем..... мне просто интересно, сколько и каких надо будет нанести параметров на объект в исполнении № 1, чтобы СПДС его смог параметризировать (без всяких сообщений о том, что не хватает данных).

 

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

[LogicID]

А если вообще откровенно: именно после ручной корректировки стали появляться реально классные объекты (со всякими подрезками и расчетами всех внутренних элементов, заносимых потом в спецификацию..... вставил такой объект, точками (гриппоинтами) геометри нужную выставил и получил сразу в спецификации кучу встроенных элементов). Банальный пример (элементов моих на самом деле много): это мой элемент "деревянная лестница у слухового окна" - легко настраивается ручками, хотя геометрия насыщенная, и содержит в себе ВСЕ элементы/узлы из бруса (5 позиций сразу формируются)...... Как-то так......

[doctorraz]

1 час назад, LogicID сказал:

именно после ручной корректировки стали появляться реально классные объекты

На эту тему , но про мастер скриптов с @MCAD  мы обсуждали еще лет пять назад..

Руками конечно получается более эффективный код, но мастером более быстрый..

Можно писать годами код на асемблере, а можно за пять минут накидать то же самое на шарпе.. это будет почти аналог по функционалу.. но за пять минут))

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

Мне эта тема интересна..

Первый пример это почти зона защиты двух стержневых молниеотводов..

Распознал мастером, но скрипт веселый получился..

Посмотрю твои примеры.. если сопряжения решаются на уровне исполнения, то ВАУ, снимаю шляпу и привет ленивцам техническим писателям консистентсофтваре

Edited November 18, 2021 by doctorraz

[LogicID]

 

38 минут назад, doctorraz сказал:

Можно писать годами код на асемблере, а можно за пять минут накидать то же самое на шарпе.. это будет почти аналог по функционалу.. но за пять минут))

Да, ты прав! Полностью согласен с тобой!

38 минут назад, doctorraz сказал:

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

Все верно. Просто у меня уровень "зашквара" по созданию объектов перешел, видать, в иную "плоскость." Объекты теперь более сложные и мне стало удобней писать руками код исполнения.

38 минут назад, doctorraz сказал:

Мне эта тема интересна..

Первый пример это почти зона защиты двух стержневых молниеотводов..

Распознал мастером, но скрипт веселый получился..

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

Edited November 18, 2021 by LogicID

[MCAD]

13 часов назад, LogicID сказал:

Если получиться, мне будет интересно ознакомиться.

К сожалению ничего  интересного  не получилось. Думал получится что-то новое.

 

В детали не вдавался и параметры не подставлял. 

Но должно получиться и с параметрами.

Разные радиусы правой левой галтелей нужно и в эскизе изначально нарисовать разными. Иначе, при распознавании , они получат один параметр. Даже если размеры будут разными.

По второму исполнению пока нет никаких мыслей.

LogicID.zip

[MCAD]

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

[LogicID]

29 минут назад, MCAD сказал:

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

Браво, MCAD! Это полезный пример для применения рабочих объектов при сложных построениях.

55 минут назад, MCAD сказал:

Разные радиусы правой левой галтелей нужно и в эскизе изначально нарисовать разными. Иначе, при распознавании , они получат один параметр. Даже если размеры будут разными.

А вот с такими нюансами я точно не знаком. Удивлен! Для меня это снова выход за пределы логики....

[oleg25]

Всем добрый день!

С вашего позволения, вставлю свои 5 не сильно грамотных копеек, т.к. не силен в программировании. Из полилога этой ветки форума, как я понял, одна из проблем при распознании вида, это не вполне очевидным образом накладываемые зависимости. И в самом деле, если сравнивать с зависимостями на одноименной вкладке nanoCAD, кроме размерных зависимостей мы еще можем задавать и геометрические зависимости (равенства, симметрии, сопряжения и т.д.). Мне как пользователю, когда я накладываю такие зависимости, в целом, очевидно дальнейшее поведение объекта. Если бы в формировании параметрического объекта в мастере объектов было бы также, было бы здорово. А если бы еще при этом программа подсказывала, где какие зависимости конфликтуют, и какие примитивы остались не запараметризованными, так и вовсе было бы замечательно. Текущая реализация функционала, на мой взгляд, менее юзерфрендли, чем могла бы быть. 

[LogicID]

Ай да MCAD,  ну просто удивил меня и порадовал своим сообщением в личке. МОЛОДЦЫ! Хорошее начинание!!!!!

[doctorraz]

Личка на то и личка, чтобы не афишировать лишний раз..

Это так, на будущее

[LogicID]

15 минут назад, oleg25 сказал:

Текущая реализация функционала, на мой взгляд, менее юзерфрендли, чем могла бы быть. 

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

 

Приведу пример, связанный с параметризацией в других программах. Revit не позволяют нормально управлять семействами (мое личное мнение! такая реализация сделана больше как раз под проектировщика и через некоторые "костыли", а также написание модулей на С# можно выравнивать ситуацию). Смотрим на ArchiCAD и там мне реализация пользовательских объектов больше импонирует. Да, встроенный язык кажется неудобным, но он не сложный. Плюс возможность сделать графический интерфейс, плюс возможность управления объектов из кода! В Ревите стандартными средствами это не работает. К чему я это все? Реализация СПДС мне подходит как неофициальному проектировщику (да... и такое бывает, так как на крупных должностях обычно работаю) с уклоном в сторону разработчика.

[MCAD]

Всё же mechWizard (изначально) заточен на универсальные объекты для более менее продвинутых пользователей. 

Вот небольшой пример быстрого  решения похожей задачи.

 

[LogicID]

6 минут назад, doctorraz сказал:

Личка на то и личка, чтобы не афишировать лишний раз..

Это так, на будущее

Так он может мне свои фотографии на презентации Армия 2021 выложил. Вот и порадовался за коллектив 

[MCAD]

2 минуты назад, LogicID сказал:

презентации Армия 2021

ВПК - это из прошлой жизни  ;-( 

Спойлер

https://www.cadmaster.ru/magazin/articles/cm_09_look_before_you_leap.html

 

[LogicID]

9 минут назад, MCAD сказал:

Всё же mechWizard (изначально) заточен на универсальные объекты для более менее продвинутых пользователей. 

Вот небольшой пример быстрого  решения похожей задачи.

Группы - это хорошее направление. Но что лично мне стало мешать в работе: на загруженных чертежах начинаешь что-то двигать для компоновки и тут надо следить, чтобы маркер группы тоже был захвачен (я про перемещение множества объектов, а не одной группы за ее маркер). Надо постоянно следить!!! Иначе маркеры в одном месте, объекты в другом.... а еще любой объект в группе может самостоятельно перемещаться стандартными средствами и снова уползать в сторону. Да, можно через диспетчер объектов искать маркеры и подсвечиваются все объекты в группе но при больших чертежах даже на моем 32" мониторе не всегда удобно отловить эту "тему". Одним словом: вещь полезная, но требует аккуратный подход в применении.

добавлено через 2 минуты

6 минут назад, MCAD сказал:

ВПК - это из прошлой жизни  ;-( 

Удивлен! Про Армия 2021 я просто с ходу писал..... А тут оказывается такое дело........

[MCAD]

1 час назад, oleg25 сказал:

Текущая реализация функционала, на мой взгляд, менее юзерфрендли, чем могла бы быть. 

Нет предела совершенству

 

1 час назад, oleg25 сказал:

(равенства, симметрии, сопряжения и т.д.)

Как раз от этого и уходили. Все прошито внутри алгоритма.

 

1 час назад, oleg25 сказал:

если сравнивать с зависимостями на одноименной вкладке nanoCAD

Они денег стоят и появились примерно лет на 15 позже mechWizard'a

1 час назад, oleg25 сказал:

Мне как пользователю, когда я накладываю такие зависимости, в целом, очевидно дальнейшее поведение объекта

Вот нет у СПДС'а такой функции :-(  

Немного другое назначение у мастера объектов. Более широкое что ли.

У 90 %  объектов нет вообще касательных, а дуги и окружности, зато есть необходимость взаимодействия между объектами.

 

Если нужно сделать со "сложной" графикой, то проще сделать НЕ заниматься параметризацией, а сделать несколько простых исполнений?!?

 

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

  

В 17.11.2021 в 12:08, LogicID сказал:

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

 

И да (большими красными буквами) mechWizard не совершенен и много чего хотелось бы добавить модифицировать

 

 

[LogicID]

2 часа назад, MCAD сказал:

И да (большими красными буквами) mechWizard не совершенен и много чего хотелось бы добавить модифицировать

Это да. Аппетит всегда приходит во время еды, но зато от СПДС есть ощущение и "ложки", и "тарелки", и даже "еда положена". Жаловаться - грех.... так нет, спустя какое-то время... хочу есть "китайскими палочками", мне нужна "глубокая миска".....ой, а зачем мне "мясо", я же истинный "вегетарианец". Думаю, что со стороны мое поведение может местами походить на вот такого "товарища".

 

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

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

 

Логика присутствует или я "плохой мясоед"? 

Edited November 19, 2021 by LogicID

[MCAD]

24 минуты назад, LogicID сказал:

расстановка ручек в основном скрипте вызывает временами "гемморой" (нет функций сопряжения с дугами, так что вводи доп. переменные и мудри с векторами)

Я поковыряюсь. Но не помню такого 

[LogicID]

12 минут назад, MCAD сказал:

Я поковыряюсь. Но не помню такого 

Реально посыл для разработчиков: просто хотя бы функции, используемые в скрипте исполнений для расчета геометрии, сделали доступными в основном скрипте. И было бы ОГРОМНОЕ СЧАСТЬЕ!

Получается, что все функции и операторы основного скрипта (выделяются синим) доступны/публичны для скрипта исполнений. А наоборот - нет! Нет смысла все дублировать и там и там, т.е. в одном скрипте "as...", а в другом по аналогии тоже самое, но "get...".

Сделать их едиными и уже будет маленькое счастье у маленького человечка на маленькой планете Земля (шутка про человечка, но не шутка про "сделать их едиными). А то как-то с перекосом: для графической части вот вам "полный кухонный набор", а в основном скрипте....ммм....ребята, короче, берешь этот вектор, складываешь с тем, потом плоскость, здесь угол до точки.....

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

[LogicID]

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

 

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

 

Имеем в объекте:

1. Публичные (Public) и приватные (Protected) переменные в функции ActHeader().

2. Различные исполнения, в скриптах которых применяются различные комбинации этих переменных/

3. Ну и алгоритмы в функции OnMoveGripPoint(), которые меняют некоторые переменные в зависимости от перемещения ручек.

          И в какой-то момент, в зависимости от уровня ваших творческих хотелок, можно получить результат, когда при изменении определенных ручек не будет перерисовываться объект! Не правильно сделан алгоритм работы ручек? Не торопитесь!!! Есть один "подводный" камень, который явно не виден на поверхности:

скрипты исполнений гарантированно перерисовываются только тогда, когда публичные (!!!) переменные, используемые в этих скриптах, меняют свое значение. МЕНЯЮТ НА ДРУГОЕ ЗНАЧЕНИЕ! ЭТО ВАЖНО! Просидев несколько часов в дебагере у меня четко сложилось мнение о том, что где-то на верхнем уровне СПДС происходит анализ изменения переменных в коде скриптов исполнений и после этого принимается решение о перерисовке объекта (выполнения скрипта исполнения).

Теперь более подробно: 

1). если в OnMoveGripPoint() в алгоритме обработки ручки меняются только приватные переменные и они в дальнейшем где-то (например, в OnMakeParameters) не участвуют в расчете публичных переменных, используемых с соответствующем скрипте исполнения (а у нас же много может быть исполнений), то исполнение не перерисуется! 

2). Если изменяемые в OnMoveGripPoint() приватные переменные участвуют в расчете (только основной скрипт!!) публичных переменных, используемых с соответствующем скрипте исполнения, но из-за определенной логики (например, ветвление if-else) значение присваивается то же, то исполнение не перерисуется!

3). Изменяемые в OnMoveGripPoint()  публичные переменные, используемые с соответствующем скрипте исполнения перерисуют исполнение! Походу еще все проще (боюсь, правда, сглазить) - итог в конце данного сообщения.

 

Самый вырожденный случай этой темы, это ручка в точке вставки. Алгоритм там простой, типа pntOrigin=pntGrip[0]. При движении этой ручки скрипт исполнения не запускается (динамически из кода не перерисовывается), можете через дебагер проверить....... Но можно и запустить скрипт исполнения даже при перемещении точки вставки (об этом - ниже)

 

          Можете провести простой эксперимент сами: сделайте объект из двух точек (линию), параметр линии (например, длина) - приватный; в исполнении, соответственно, также используется этот параметр, далее повесьте ручку на один конец и сделайте соответствующий расчет OnMoveGripPoint() .... При движении будет менять приватный параметр (смотрим в дебагер), а вот сам объект не будет перерисовываться динамически (тянем ручку, а линия на месте). "Глюк" может и не наблюдаться, но рано или поздно его можно поймать!

 

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

       Самая простая реализация: объявляю публичную переменную, например "бла_бла", с описание "hidden", далее инициализируем ее в OnInitialization() единицей . Вставляем ее в нужные скрипты исполнений вида zzz=бла_бла (переменную zzz мы не будем использовать, но она нам поможет в отрисовке скрипта исполнения), далее вставляем в нужное место основного скрипта запись вида бла_бла=-бла_бла (простое отрицание, чтобы значение менялось, но не наращивалось). И ВУАЛЯ!

         А где это нужное место в коде? Можно в определенную обработку ручки в OnMoveGripPoint() вставить. Много ручек в исполнении? Ставим запись повыше в OnMoveGripPoint() в часть ветвления по имени исполнения. А можно в самое начало OnMoveGripPoint() поставить. А если у меня много исполнений и в различных местах нужны обновление скрипта исполнения, куда пихать? Правильно! В OnMakeParameters(). Одним словом, даже при движении только pntOrigin будет срабатывать скрипт исполнения.

Вот такая вот "сказка", которая лично мне облегчила кастомизацию пользовательских объектов.

 

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

 

Edited November 22, 2021 by LogicID