Таблицами наверно заморочено будет, но
В стандартных, можно в объект добавить несколько таблиц и по “ключевым” полям связать их между собой
Т. Е. Выбираешь в одной таблице значение, оно подтягивает из другой таблицы значение или список
Сдается мне, что задача сведется к определению значения функции в произвольной точке. Т.е., сначала нужно определить, в какой диапазон попадает значение из “множества 1” (строка), а потом уже интерполяция среди значений из “множества 2” (в пределах строки). Если предположение верно то задача может сильно усложниться.
Я же выложил файл с примером https://cloud.mail.ru/public/ef5G/hZDS1PEdg
Т.е., сначала нужно определить, в какой диапазон попадает значение из “множества 1”
Этого я в задаче не увидел. Но в принципе тоже решаемо.
Вообще много вопросов именно такого характера. Типа “Слабо японской бензопиле…”
Сегодня только писал
и пример делал.
про пилу понравилось)
В задаче поиска строки, действительно, нет. Это чисто мое предположение. Т.к. только в такой постановке задача обычно имеет практический смысл - поиск значения затабуированной функции. Но не настаиваю.
Т.к. только в такой постановке задача обычно имеет практический смысл
Ну пока так. Появится автор задачи уточнит или сам доделает и поделится.
про пилу
Я с пониманием к таким вопросам. Для многих трагедия и потеря больших наработок.
Вот что я имел ввиду. Можно и так сделать как в экселе.
Интерполяция.rar (34,9 КБ)
Вот что я имел ввиду
Я тоже самое сделал.
Добавил второй “Варианта” для случая
Т.е., сначала нужно определить, в какой диапазон попадает значение из “множества 1” (строка), а потом уже интерполяция среди значений из “множества 2” (в пределах строки).
Вот что я имел ввиду. Можно и так сделать как в экселе.
У нас результат абсолютно одинаковый
Добавил второй “Варианта”
Предложил бы еще доработать этот пример до “промышленного” варианта (моя субъективная оценка, если что). Суть в доработки в том, что вся эта машинерия разбивается на две таблицы:
- Первая таблица - решалка. Фактически это функция, заданная не в виде алгебраических выражений, а в виде диапазонов аргументов и диапазонов значений
- Вторая таблица - это собственно таблица пользователя с интересующими его конкретными значениями аргумента и вычисленными соответствующими им значениями функции. Очевидно, что таблица значений - это запросы к первой таблице с аргументом, введенным пользователем.
Такое решение обладает рядом преимуществ:
- Таблицы разделены по своему функциональному назначению - таблица-решалка (инструмент) и таблица пользователя (нечто, относящееся непосредственно к разрабатываемому объекту)
- Таблица-решалка может быть помещена не невидимый слой (и т.п.) с целью не мозолить глаза. Вместе с тем она достаточно понятная для внесения изменений, которые будут носить редкий характер. Т.е., эта таблица фактически будет констатной.
- Таблица пользователя будет иметь достаточно компактный вид с внятным содержанием - аргумент и значение функции без ненужной дополнительной операции визуального поиска в какую бы строку вставить аргумент. Эта таблица будет иметь сильно переменное значение строк в зависимости от действий пользователя
- Решение может быть масштабируемо на любые аналогичные задачи, где производится выбор значений из таблицы. Такого хозяйства очень много в нормативке
Сам не владею функционалом таблиц, поэтому не могу предложить подходящее решение вместо его описания. Надеюсь, гуру реализуют это влет)
Предложил бы еще доработать этот пример до “промышленного” варианта (моя субъективная оценка, если что). Суть в доработки в том, что вся эта машинерия разбивается на две таблицы:
- Первая таблица - решалка. Фактически это функция, заданная не в виде алгебраических выражений, а в виде диапазонов аргументов и диапазонов значений
- Вторая таблица - это собственно таблица пользователя с интересующими его конкретными значениями аргумента и вычисленными соответствующими им значениями функции. Очевидно, что таблица значений - это запросы к первой таблице с аргументом, введенным пользователем.
Такое решение обладает рядом преимуществ:
- Таблицы разделены по своему функциональному назначению - таблица-решалка (инструмент) и таблица пользователя (нечто, относящееся непосредственно к разрабатываемому объекту)
- Таблица-решалка может быть помещена не невидимый слой (и т.п.) с целью не мозолить глаза. Вместе с тем она достаточно понятная для внесения изменений, которые будут носить редкий характер. Т.е., эта таблица фактически будет констатной.
- Таблица пользователя будет иметь достаточно компактный вид с внятным содержанием - аргумент и значение функции без ненужной дополнительной операции визуального поиска в какую бы строку вставить аргумент. Эта таблица будет иметь сильно переменное значение строк в зависимости от действий пользователя
- Решение может быть масштабируемо на любые аналогичные задачи, где производится выбор значений из таблицы. Такого хозяйства очень много в нормативке
Сам не владею функционалом таблиц, поэтому не могу предложить подходящее решение вместо его описания. Надеюсь, гуру реализуют это влет)
Чуть позже постараюсь вникнуть. НО, меня прямо пугает тенденция последнего времени, “чахленькие таблички” не будут служить полноценной заменой Excel.
Первая таблица - решалка.
Вторая таблица - это запросы к первой таблице с аргументом, введенным пользователем.
Совсем недавно решали похожую задачу..
Даже сделал плейлист на канале: ХОЧУ как в Excel
Предложил бы еще доработать этот пример до “промышленного” варианта (моя субъективная оценка, если что). Суть в доработки в том, что вся эта машинерия разбивается на две таблицы:
- Первая таблица - решалка. Фактически это функция, заданная не в виде алгебраических выражений, а в виде диапазонов аргументов и диапазонов значений
- Вторая таблица - это собственно таблица пользователя с интересующими его конкретными значениями аргумента и вычисленными соответствующими им значениями функции. Очевидно, что таблица значений - это запросы к первой таблице с аргументом, введенным пользователем.
Такое решение обладает рядом преимуществ:
- Таблицы разделены по своему функциональному назначению - таблица-решалка (инструмент) и таблица пользователя (нечто, относящееся непосредственно к разрабатываемому объекту)
- Таблица-решалка может быть помещена не невидимый слой (и т.п.) с целью не мозолить глаза. Вместе с тем она достаточно понятная для внесения изменений, которые будут носить редкий характер. Т.е., эта таблица фактически будет констатной.
- Таблица пользователя будет иметь достаточно компактный вид с внятным содержанием - аргумент и значение функции без ненужной дополнительной операции визуального поиска в какую бы строку вставить аргумент. Эта таблица будет иметь сильно переменное значение строк в зависимости от действий пользователя
- Решение может быть масштабируемо на любые аналогичные задачи, где производится выбор значений из таблицы. Такого хозяйства очень много в нормативке
Сам не владею функционалом таблиц, поэтому не могу предложить подходящее решение вместо его описания. Надеюсь, гуру реализуют это влет)
“Переспал” с этой мыслью 
Это же получается именно то, что доктор прописал !
выше писал
Предложил бы еще доработать этот пример до “промышленного” варианта (моя субъективная оценка, если что). Суть в доработки в том, что вся эта машинерия разбивается на две таблицы:
- Первая таблица - решалка. Фактически это функция, заданная не в виде алгебраических выражений, а в виде диапазонов аргументов и диапазонов значений
- Вторая таблица - это собственно таблица пользователя с интересующими его конкретными значениями аргумента и вычисленными соответствующими им значениями функции. Очевидно, что таблица значений - это запросы к первой таблице с аргументом, введенным пользователем.
Такое решение обладает рядом преимуществ:
- Таблицы разделены по своему функциональному назначению - таблица-решалка (инструмент) и таблица пользователя (нечто, относящееся непосредственно к разрабатываемому объекту)
- Таблица-решалка может быть помещена не невидимый слой (и т.п.) с целью не мозолить глаза. Вместе с тем она достаточно понятная для внесения изменений, которые будут носить редкий характер. Т.е., эта таблица фактически будет констатной.
- Таблица пользователя будет иметь достаточно компактный вид с внятным содержанием - аргумент и значение функции без ненужной дополнительной операции визуального поиска в какую бы строку вставить аргумент. Эта таблица будет иметь сильно переменное значение строк в зависимости от действий пользователя
- Решение может быть масштабируемо на любые аналогичные задачи, где производится выбор значений из таблицы. Такого хозяйства очень много в нормативке
Сам не владею функционалом таблиц, поэтому не могу предложить подходящее решение вместо его описания. Надеюсь, гуру реализуют это влет)
“Переспал” с этой мыслью
Это же получается именно то, что доктор прописал !
выше писал
У меня в клиновых задвижках именно так реализован подбор привода к арматуре
Предложил бы еще доработать этот пример до “промышленного” варианта (моя субъективная оценка, если что). Суть в доработки в том, что вся эта машинерия разбивается на две таблицы:
- Первая таблица - решалка. Фактически это функция, заданная не в виде алгебраических выражений, а в виде диапазонов аргументов и диапазонов значений
- Вторая таблица - это собственно таблица пользователя с интересующими его конкретными значениями аргумента и вычисленными соответствующими им значениями функции. Очевидно, что таблица значений - это запросы к первой таблице с аргументом, введенным пользователем.
Такое решение обладает рядом преимуществ:
- Таблицы разделены по своему функциональному назначению - таблица-решалка (инструмент) и таблица пользователя (нечто, относящееся непосредственно к разрабатываемому объекту)
- Таблица-решалка может быть помещена не невидимый слой (и т.п.) с целью не мозолить глаза. Вместе с тем она достаточно понятная для внесения изменений, которые будут носить редкий характер. Т.е., эта таблица фактически будет констатной.
- Таблица пользователя будет иметь достаточно компактный вид с внятным содержанием - аргумент и значение функции без ненужной дополнительной операции визуального поиска в какую бы строку вставить аргумент. Эта таблица будет иметь сильно переменное значение строк в зависимости от действий пользователя
- Решение может быть масштабируемо на любые аналогичные задачи, где производится выбор значений из таблицы. Такого хозяйства очень много в нормативке
Сам не владею функционалом таблиц, поэтому не могу предложить подходящее решение вместо его описания. Надеюсь, гуру реализуют это влет)
“Переспал” с этой мыслью
Это же получается именно то, что доктор прописал !
выше писал
У меня в клиновых задвижках именно так реализован подбор привода к арматуре
Так ты правильно используешь СПДС, именно как “Access”, а не Excel.
Собственно как он и задумывался, включая отчёты и пользовательские формы - оттуда передиралось.
Таблицы - случайно получились вспомогательный инструмент, для построения отчётов по БД чертежа. Писал уже много раз…
по примеру из excel, но принцип такой же.
Только заметил, что пример не приложил.
Это же получается именно то, что доктор прописал !
Доктор плохого не посоветует! Именно это и нужно.
Ввиду слабого знания, что там и как под капотом в таблицах, мне видится проблема в изменении выборки в таблице пользователя. Возможно, это делается одним кликом. Если так, то это будет универсальное решение. которое можно поместить в палитру инструментов: вставка двух таблиц, таблица-решалка сразу “отправляется” на слой Defpoints, а таблица пользователя содержит необходимые формулы. При этом в ней должна быть доступно изменение выборки, либо просто ручная набивка строк со значением аргумента.
Эко вы тут тему развили. На самом деле меня устроил вариант с формулой интерполяции, он полностью подходит для решения моей задачи. Спасибо!
Эко вы тут тему развили.
Вообще название темы “Работа с формулами” намекает на “Построитель выражений”, а не конкретную функцию.
https://m.youtube.com/watch?v=R5uy1lObJbg&t=1s
И тем более никто в платформе не будет искать решения по базе СПДС.
Добрый день! Прошу помощи для написания формулы в таблицу nanocad, аналогичной exel: СУММЕСЛИ.
Дано: кабельный журнал ЭОМ, нужно посчитать сумму всех упомянутых в таблице кабелей по отдельности.
В exele формула выглядела след. образом: для I161:=СУММЕСЛИ($H$6:$H$159;$H161;I$6:I$159).
Как написать это же выражение в таблице Nanocad?
Добрый день! Прошу помощи для написания формулы в таблицу nanocad, аналогичной exel: СУММЕСЛИ.
Дано: кабельный журнал ЭОМ, нужно посчитать сумму всех упомянутых в таблице кабелей по отдельности.
В exele формула выглядела след. образом: для I161:=СУММЕСЛИ($H$6:$H$159;$H161;I$6:I$159).
Как написать это же выражение в таблице Nanocad?
Имха менее затратно будет посчитать в эксель и скопипастить в таблицу нано.
Такто расчеты ткз и релейки, давно уже делаю в эксель и как ole вставляю в нану.
Если надо поправить дабкликом открыл оле поправил сохранил, закрыл, все автоматом обновилось
В exele формула выглядела след. образом: для I161:=СУММЕСЛИ($H$6:$H$159;$H161;I$6:I$159)
Нет такой функции.
А точно , что диапазон суммирования i6:i151, а не i6:o151?
Если да, то можно добавить скрытые колонки и в них отдельно подсчитать сумму по маркам.
Хлопотно, конечно.