Rolles217 написал: а а для списка БД подобное нельзя реализовать?)
Сделайте столбец текстового типа в БД с такой записью, а в переменной выбирайте из другого столбца, а отображайте этот.
я так пробовал делать, но в этом случае, получается не выпадающий список, а всплывающее окно, в котором выбираешь, в списках панели управления такое же поведение
Rolles217 написал: а для списка БД подобное нельзя реализовать?
с базой данный такой номер не прокатит. Но можно упростить привязку к базе данных используя функцию find в выражении, например:
Код
find(DB.p1, $def==DB.def)
в данном случае функция вернет значение (вещественного типа) из столбца p1 по условию, заданному переменной $def. То есть, фактически поиск будет выполняться по ключу из той же базы данных. Переменная $def -- это список значений, к которому привязан элемент управления, и через который осуществляется параметризация модели.
Rolles217 написал: а для списка БД подобное нельзя реализовать?
с базой данный такой номер не прокатит. Но можно упростить привязку к базе данных используя функцию find в выражении, например:
Код
find(DB.p1, $def==DB.def)
в данном случае функция вернет значение (вещественного типа) из столбца p1 по условию, заданному переменной $def . То есть, фактически поиск будет выполняться по ключу из той же базы данных. Переменная $def -- это список значений, к которому привязан элемент управления, и через который осуществляется параметризация модели.
vite написал: Rolles217, а в чем вы видите практическую пользу?
Нууу. как минимум не запоминать подобную комбинацию символов (функций) (rec($DB==DB.Исполнение), find(DB.p1, $def==DB.def), val(DB,DB.p1)), и сделать как можно больше управление галочками..
вообще я бы сделал вот так:
нужно сделать третий тип переменной - массив (или объект)
допустим у нас есть некая БД:
и когда в переменную мы из списка выбираем какой то пункт из колонки "Исп" с помощью списка, то в переменную "cfg" должна занестись не какое то одно значение, а вся строка из БД а дальше мы уже можем выбирать из этой переменной нужную колонку через точку "cfg.A", что выдаст нам значение из нужной нам колонки (и это будет соответствовать принципам ООП, что более понятно, по сравнению с процедурными методами):
ну красиво же выглядит, и все понятно, по сравнению с тем что сейчас есть:
мозг сломаешь, и наизусть все это выучить проблематично, приходится постоянно куда то подглядывать.. скажем так, если придет новичок который ни разу не сталкивался с языками программирования, ему будет очень тяжело объяснить почему там нужно писать именно так.. (я с некоторыми знаком, по этому я понимаю что здесь написано и почему именно так) и по сути вот эта рутина в написании функций больше отталкивает чем привлекает, этот самый новичок просто развернется и найдет программу попроще типа Solidworks, потому что там все пишется с помощью понятной таблицы Excel, а переменные автоматом создаются в имени размеров, казалось бы вроде пошли от обратного, но насколько упрощает задачу. Я не говорю что у вас все плохо, но нужно добавить побольше автоматизма, и если что то нарисовалось не так как хотелось - уже зайти в настройки и ткнуть нужную галочку, а у вас получается что программе нужно объяснять каждый сделанный шаг, и из-за этого процесс создания чертежей очень сильно затягивается, потому что сидишь и пытаешься сначала придумать логику создания того чего нужно, а только потом уже у тебя что то вырисовывается) вот это же касается сообщения выше про массив отверстий, кто ж знал что сначала нужно сделать массив точек, а только потом ты сделаешь массив отверстий - почему вот программе не объяснить что если пользователь хочет сделать массив отверстий, то соответственно и точки нужно автоматически прорисовать, а если уж он хочет сделать из них что то другое, то пусть жмет соответствующую галочку.
З.Ы.: я не говорю что нужно делать как у других и переделать весь движок полностью, пусть все что было остается, можно просто добавлять новые возможности по ускорению процесса конструирования)
Rolles217, ну если следовать парадигме объектно ориентированной модели, чтобы извлечь значение ячейки, нам потребуется также определить индекс строки. То есть, выражение должно иметь примерно следующий вид:
при условии, что переменная ссылается на объект таблицы базы данных. Теперь сравним с выражением текущей реализации:
Код
find(DB.A, $def==DB.def)
find(DB.B, $def==DB.def)
Чем различаются представленные варианты? Да по сути ни чем. Объект DB является глобальным по отношению к функции find. То есть, в качестве параметра передается ссылка на глобальный объект базы данных, и под капотом выполняется нечто похожее на первый вариант. По видимому, второй вариант записи обусловлен спецификой ограничений при выполнении анализа выражения, когда приходится выбирать между сложностью синтаксического разбора и оптимизацией вычислений. Будем надеяться что в будущем разработчики T-FLEX CAD расширят возможности встроенного языка выражений, и возможно, мы увидим нечто похожее на iLogic в Inventor. А пока будем довольствоваться тем, что имеем.
vite написал: Rolles217, ну если следовать парадигме объектно ориентированной модели, чтобы извлечь значение ячейки, нам потребуется также определить индекс строки. То есть, выражение должно иметь примерно следующий вид:
не совсем понял почему переменная должна иметь такой вид.. в твоем варианте получается что в объекте $def должна хранится вся БД целиком..
а я говорю про то что во время выбора в списке, в переменную должна записаться только строка из БД соответствующая выбранному пункту, а не вся БД целиком, и тогда все колонки могут записаться как отдельные объекты в одну переменную. чтобы получилось вот так:
в списке переменной "def" -> выбираем "Деталь-2", "def" записывает в себя объект с именами соответствующим колонкам:
т.е. переменные остаются, а меняется только значения этих переменных, это возможно даже ускорит работу программы, потому что не придется прибегать к доп. функциям
мысли в слух:
Скрытый текст
Вот что делает эта функция: find(DB.A, $def==DB.def) она берет переменную DB.def и начинает в цикле перебирать все ячейки БД в колонке "def" до тех пор пока то что находится в ячейке не совпадет с тем что находится в переменной $def. Хотя вот честно говоря никогда не встречал таких выражений.. нормальная функция должна выглядеть вот так find("A", $def , DB), где "A" - искомая ячейка, ну и $def - ключ поиска, DB или "DB" - объект или имя БД. Скорей всего эту строчку еще какая то функция обрабатывает (разбивает) по ключевым словам и символам (регулярным выражениям), уже после обрабатывает, наверное это для безопасности.. если это так, то тут вообще не должно составлять труда добавить дополнительный обработчик псевдо объекта.. Так вот, как только ячейка найдена, функция определяет индекс текущей строки, и уже по индексу находит то что лежит в ячейке A, т.е. эта самая БД уже скорее всего выгружена (либо постоянно при вызове выгружается) в какой-то массив в закромах программы, а функция find() или val() , уже дергают необходимые строчки из этого массива (объекта). Тут даже если посмотреть DB.A - это уже по сути объект, ему только индекс поиска нужен.
1. есть переходной тройник, у которого в БД есть значение магистрали, и значение ответвления (d и d1 соотв.), как сделать так что бы при выборе значения "d" (к примеру 32), раскрываемое меню "d1" содержало только значение из БД которые существуют с соответствующим значением "d" тоесть для d=32, в выпадающем списке должно быть только 20 и 25. Сейчас в выпадающем списке все значения столбца d1:((
2. есть тот же тройник, при вставке в сборку и выборе конектора на трубе, по умолчанию выбирается значение для магистрали (d), значение ответвления выбираю в ручную. Как сделать так что бы при выборе лск для вставки фрагмента ("ответвление") не учитывалось значение для магистрали и уже его нужно было выбрать вручную.?
1. есть переходной тройник, у которого в БД есть значение магистрали, и значение ответвления (d и d1 соотв.), как сделать так что бы при выборе значения "d" (к примеру 32), раскрываемое меню "d1" содержало только значение из БД которые существуют с соответствующим значением "d" тоесть для d=32, в выпадающем списке должно быть только 20 и 25. Сейчас в выпадающем списке все значения столбца d1:((
у меня так получилось: в поле фильтр нужно написать d==d
Lamer написал: 2. есть тот же тройник, при вставке в сборку и выборе конектора на трубе, по умолчанию выбирается значение для магистрали (d), значение ответвления выбираю в ручную. Как сделать так что бы при выборе лск для вставки фрагмента ("ответвление") не учитывалось значение для магистрали и уже его нужно было выбрать вручную.?
Нет фрагмента ответвления, нет тестовой сборки. Я вообще не очень понял, что требуется.
Lamer написал: 2. есть тот же тройник, при вставке в сборку и выборе конектора на трубе, по умолчанию выбирается значение для магистрали (d), значение ответвления выбираю в ручную. Как сделать так что бы при выборе лск для вставки фрагмента ("ответвление") не учитывалось значение для магистрали и уже его нужно было выбрать вручную.?
Нет фрагмента ответвления, нет тестовой сборки. Я вообще не очень понял, что требуется.
Да у меня проблема с описанием, задачи)). Сборки нет как таковой. Снял ролик, надеюсь будет понятней.
Lamer написал: Снял ролик, надеюсь будет понятней.
Да, всё понятно. Тут можно передавать всегда два значения, а во время вставки с одного снимать значок с коннектора и задавать значение из списка, либо делать через диалог, галочкой с коннектора/вручную на двух диаметрах.
Rolles217 написал: не совсем понял почему переменная должна иметь такой вид..
по большому счету не важно, скрыт индекс или нет. В любом случае определяющим фактором является архитектура приложения, которая публично недоступна. Мы можем только гадать что на самом деле происходит под капотом. То что представляется очевидным преимуществом, по факту, может оказаться не оптимальным решением. По этой причине, давать какие либо оценки, в отношении процедуры обработки выражений, не имеет смысла. Но это вовсе не означает, что пользователь лишается возможности получить обратную связь. Бывает, случается, некоторые предложения от пользователей реализуют.
На самом деле в T-FLEX CAD существуют более значимые проблемы, на которые стоит обратить внимание. Например, отсутствие механизма обработки переменных, в режиме ввода пользователя, с процедурой возврата значения по умолчанию.