Mитька

И ни та, ни другая не являются правильными при этом... Я уж не говорю про разные стили оформления, стоящие у них по умолчанию...

Для именно этой задачи есть красивейшее решение (огромное спасибо @MCAD) - во вложении. В этом случае необходимый список загружается в столбцы 4,5 одним движением "копировать-вставить", эти координаты присваиваюся переменным в столбцах 2,3 - и вуаля, все точки расставлены. Затем таблица удаляется и дальше точки можно двигать, как захочется, если надо. Но изначального вопроса это не отменяет. Координаты из таблички 1.dwg

Исходные: есть маркер координат и табличка, что берёт с маркера переменные Object."Origin point X:" и Object."Origin point Y:" (читай - координаты). В Нано СПДС 6 и 20.0 эти координаты можно было отредактировать из таблицы - точка перемещалась в соответствующее место. В Нане СПДС 20.1 (и в 20.0) эта возможность почему-то убрана (возможно, была убрана и в версиях 7,8,9 - не проверяли). Координаты легко редактируются из Инспектора Свойств, а вот при редактировании их же из таблички - ничего не происходит. Так и задумано? Если да, то зачем? Если нет - то верните, пожалуйста, как было. Это ппц как неудобно в отдельных ситуациях. Или это только у нас оно не работает? На всякий случай файл во вложении... Координаты из таблички.dwg

Полагаю, вас попросят рассказать чууууууть поподробней.

Ну как не при чём...? Вот зачем разработчикам к вам прислушиваться в данном случае? Почему ваше видение должно ВДРУГ стать для них приоритетнее, чем (к примеру) моё? Т.е. есть изменения, которых хочу Я, а есть изменения, которых хотите вы. А руки у разработчика одни. Что выбрать (в первую очередь, разумеется)? Тут, я полагаю, один критерий: потенциальная выгода от меня и вас, как от пользователя. Это я и подразумеваю под влиянием. Вот к примеру: вы а своё проекте переноса ПО Юнис-Юг на одну из платформ общаетесь с кем? С гендиректором компании..? Сомневаюсь. Скорее всего с дилером или продукт-менеждером, назовём его условно "Давид". Вы посидели на Нанокаде годик, пообщались на форуме и пришли к выводу, что то, что происходит в Нанософт вас не устраивает. Вы говорите, "Давид, мне не нравится то-то и то-то конкретное, ваша система работы с пользователями в целом и вы лично в частности. И поэтому, Давид, мы не будет делать ПО под вас и вы потеряете потенциально 100млн. рублей в год". Давид грустит, плачет, но что поделать... Т.е. компания в вашем лице потеряла 100млн прибыли. Как вы полагаете, Давид тут же побежит к своему финансовому директору и похвастается, что из-за его манеры работы с пользователями они только что потеряли 100 млн..? Да как-то сомнительно... Скорее всего об этом никто и не узнает даже. Упущенная выгода будет неочевидна для того, кто реально принимает решения. Вот и что в этой ситуации репутационно изменится для компании? Да ничего. А если и изменится, никто об этом прямо не узнает. Второй вариант, Давид грустит, плачет и идёт дальше спокойно работать с клиентов по фамилии Греф, взаимодействие с которым принесёт компании 100500 млн. и ему лично ещё пару. А на вас с вашими 100млн. всем участникам процесса легко может быть поплевать с высокой колокольни в масштабах компании. Хочется верить, что всё не так. Но рук у разработчиков больше не становится от этого. Что возвращает нас к первому вопросу....

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

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

Полагаю, что это мало кого беспокоит... Да и вообще, вы пишете верные вещи, но как показывает практика, тем, кого вы хотите пристыдить - ни капли не стыдно. Сколько поднималось тем (только лично я автор как минимум 2х, а помню штук 5 как минимум) о подходе к общению с пользователями, о глюках в новых продуктах, о взаимодействии разработчиков с нуждами потребителя, об ориентации на новую клиентуру о блаблабла и т.д. И ни разу ни от кого из официальных представителей Нанософт я не слышал и не читал ничего похожего на "ИЗВИНИТЕ" и "ДА, МЫ НЕ ПРАВЫ". Даже когда вышел СПДС 7.0 с НЕРАБОТАЮЩИМ (вообще) интерфейсом, никто тут и ухом, помнится не повёл... Хотя куда уж веселее казалось бы. Если я ошибаюсь, и такое было, то буду признателен за ссылку, с огромным удовольствием почитаю. Даже если кому-то вдруг и станет стыдно от ваших слов, то уж признания вины и обещание исправиться вы тут точно не дождётесь.... А было бы не лишним иногда...

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

В БАЗЕ, а не встроенную в программу!.. Чтобы каждый мог подогнать её визуально под себя и не было как с Ведомостью отделки. добавлено через 0 минут Т.е. что, за 7 лет существования Наны СПДС НИКТО НИ РАЗУ ОБ ЭТОМ ВАС НЕ ПРОСИЛ?! Вот вам и обратная связь...

Опять же прекрасный пример того, что потребности у всех проектных организаций в плане функционала программы примерно одинаковые. Мы тоже такую красоту по функционалу себе сделали, чтоб на всех чертежах можно было вытащить координаты любого объекта. И жаль, что такой функционал не реализован в платформе... Хотя мож в Геонике где-то и есть... добавлено через 3 минут Ну Справка и всяческие Руководства и пояснения всегда были и остаются слабым местом Нанокада... Никто не любит писать поясняки, полагаю. Как и читать, к сожалению. Как ни крути, а прочитанное "Руководство пользователя" оооочень расширяет понимание работы программы...

Ну это утрирование. Любая автоматика это просто один из способов подсчёта. Которых в идеале должно быть два - то, что считано автоматически, проверяется ручками, или автоматически же, но по другому алгоритму. Даже если автоматика разработана лично тобой и 100 раз проверена. Так что закончить работу можно всегда - руками, как минимум. То, что не разработан идеальный функционал для каждого из видов работ - плохо, конечно, но не смертельно. Не обязан же никто в общем-тоделать, как МНЕ надо, как ни печально. Это опять же в идеале. По факту оно и для тех, и для других. Тут не соглашусь, есть смысл. Хотя бы для чёткого представления ВОЗМОЖНОСТЕЙ программы. И показа альтернативы, что можно не только палками рисовать. бОльшая проблема в том, что большинству проектировщиков "и палочками удобно" и никто добровольно в эти вебинары не лезет.

Не, это Кладочные планы. Или КЖ.

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

А если колхозить, то я бы сделал так (если бы пользовался встроенными в программу дверьми (или проёмами - для них тоже актуально): Любая дверь, содержит свойство Примечание, в которое вы можете написать НОМЕР ТИПА перегородки, в которой она находится (эти условные обозначения вы задаёте и принимаете сами). Ровно ту же нумерацию перегородок я повторил бы в стенах. Примечаний в них нет, зато есть 2-3 переменные, которые в реальной жизни чаще всего никому особо не нужны: Если Этаж вы в теории можете использовать для дополнительной фильтрации, то вот Смещение от отметки не представляю, где может пригодиться... Кстати, Смещение от отметки - в данном случае лучший выбор, т.к. это переменная, которую содержат ОБА объекта (и Стена, и Дверь). Когда вы вставляете в стену дверь, то к этой переменной у стены прибавляется некое значение и сумма даёт Смещение от отметки уже в Двери. За это некое значение в скрипте двери отвечает переменная rHfloor (в дверях по умолчанию - 30, в проёмах - 900): Я бы выставил это значение на 0 в скриптах всех имеющихся в базе дверей/проёмов. Таким образом получил бы следующую механику работы: - я "называю" все "кирпичные перегородки с утепление 100мм" типом 1 (1 прописываю в переменную "Смещение от отметки") - вставляю в такую перегородку дверь, которая автоматом подцепляет эту переменную и прибавляет к ней rHfloor, т.е. 0. - итог: дверь и перегородка "названы" одинаково, "1" (И ЭТА СВЯЗЬ НЕ ТЕРЯЕТСЯ при дальнейшем редактировании перегородки, дверь так же редактируется). Затем я сформировал бы 3 таблицы (делаются один раз и насовсем): 1) Суммирует отчётом площадь всех перегородок, отсортирована и сгруппирована по типу перегородок. 2) Суммирует отчётом площадь дверей/проёмов, отсортирована и сгруппирована по тому же принципу. Кол-во строк в таблицах 1 и 2 одинаково, т.к. сортировка/группировка идентична. 3) Пустая с плавающим количеством строк (по умолчанию, штук 20 вам хватит с головой). Затем с помощью функции Присоединить объект в построителе выражений я приконнектил бы к третьей таблице первые 2 выдернул бы значения площадей и вычел бы из одного другое. Привёл бы всё это к удобоваримому виду (поскрывал бы всё, что не нужно), сохранил бы всё как Группу и пользовал бы в таком виде. Пример того что написано в таблице 3: Столбцы 1,2: собирают данные с таблиц (можно и в общем виде написать формулу сборки, но для ваших нужд подойдёт) Столбцы 3,4: превращают их в числа (не помню, зачем, но без этого вроде не работает) Столбец 5: сравнение (или любые иные операции, что вы хотите проделать с этим числами) Столбец 6: механизм скрытия пустых строк Итоговый вид группы из 3 таблиц: Это если вам нужны именно площади. С объемами механика аналогичная, просто домножьте на толщину. Метод фонарно накидан в реальном времени, по идее должно работать, мы в организации не пользуем, т.к. по необходимости чертим развертки всех стен, а в качестве бонуса берём с них и площади, нам так проще...

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

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

а чем они идейно отличаются от кирпича..? Таблицами можно посчитать практически всё, что душе угодно.

Видимо, получилось?

Да. Этого параметра.

У вас стоит фильтр на цвет стены в Выборе Ну жная вам перегородка Красного цвета. А фильтр стоит на цвет По слою.

Файл приложите

А убирание ВОТ ЭТОЙ галочки, часом, не спасёт?

На мой взгляд это самая поганая недоработка из всех... =( В очередной раз натыкаюсь и в очередной раз матерюсь... Вы хоть представляете себе, чего сейчас стоит сделать проходку в существующем 5ти слойном захтрихованном кровельном пироге...?! В 20 местах. Без обрезки. Это просто жесть... =( И да, можно всё удалить и перешриховать. В теории. Но попробуй ещё перештрихуй... "Поиск контуров" - и нах иди... =( Вот интересу ради как-нибудь сядьте разработчиками и устройте себе марафон, кто быстрее справится... То, что раньше занимало секунды на любой объём, сейчас - гемор на часы... Есть конечно альтернатива - восстановить контур и сделать штриховку ассоциативной, но этим мы навсегда потеряем возможность добавлять ей точки.... "Шо то нехорошо, шо это нехорошо" (с) =(