Mитька

Есть ли в параметрических объектах возможность настроить отдельной переменной или ещё как-то содержание вот этого всплывающего примечания? Если нет - можно смело заносить в пожелания. Пригождалось бы практически постоянно.

Тут мы с вами в корне расходимся, полагаю. В моём представлении сервис должен предлагаться. А в вашем, видимо - выпрашиваться. Ваша правда, ок. Замените моё "отсутствие рынка" "узким рынком с отсутствием выбора на каждой конкретной ступени". Всё остальное от этого не поменяется.

Но судя по отсутствию подобной опции-за-дополнительную-плату при выставлении цены за лицензию - и не горят особым желанием добровольно (даже за деньги ) за неё браться добавлено через 2 минуты аналогия с машиной, как и аналогия с инструментами - подразумевает наличие широкого рынка, где ПРОИЗВОДИТЕЛЬ из кожи вон лезет, чтобы заинтересовать покупателя, а не покупатель должен выделываться, чтобы убедить производителя его послушать.

Надстроечки, чтобы щёлк-щёлк-контур-второй-щёлк-профит? Если и да, то я не слыхал. "Геоника" только если

Если совсем колхозно - изобразить бергштрихи двумя разными штриховками (делать долго и сложно, но есть плюс - позволяет делать переменную длину линий). Чуть менее колхозно, но тоже бюджетно - скачать тип линии "бергштрих" (было на DWG.ru.) и догрузить в программу. Проще делать, но штрихи будут только постоянной длины. добавлено через 0 минут Возможно, есть и более технологичные решения, но нам пока не требовалось.

Как возможный костыль: а нет ли возможности (вопрос скорее к разработчикам) управлять форматированием конкретных ячеек таблицы через VBS внутри программы (а в идеале и вообще посредством VBA из того же excel-файла)? Можно было бы написать простой макрос, повесить на команду и автоматизировать форматирование таблицы под нужный шаблон один раз и насовсем. добавлено через 1 минуту VBA по идее должно такое позволять, но оно сложнее в освоении. VBS было бы проще, хоть и чуть менее автоматически.

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

По этой логике получается, что если поднять ценник на %%анокад в 2 раза, туда включится ещё и сервис..? Да вряд ли. Будет та же красота только дороже. Есть (просто пример) приветливые медсёстры в государственных больничках, а есть те, кто ведут себя по-хамски. И те, и другие получают одинаково мизерную з/п. Только для одних это оправдывает хамское поведение, а для других - нет... Не в стоимости "инструмента" дело, а в людях. Да чего далеко ходить - тут ведь тоже есть люди, которые хотят тебе помочь, и это видно, а есть те, у кого, видимо, какие-то иные ценности. В приведенной вами аналогии с магазином есть 10 практически одинаковых инструментов, отличающихся лишь мелочами. На рынке ПО всё не столь разнообразно. По факту то, на чём мы все дружно сидим - платформа-монополист. Будь на рынке хотя бы один полный аналог по функционалу - подход к взаимодействию с пользователями, полагаю, был бы иным... Ну да ладно. Глядишь, когда-нибудь и появится альтернатива. Только тогда все и зачешутся. А пока особо не из-за чего переживать, никто особо и не парится.

Да о чём там задумываться... Всё и так видно. Никто особо не скрывает. Жаль ни у кого не хватает размера яичек, чтобы сказать "Да это МОЁ решение и да оно плохое"... О чём бы ни шла речь (мало ли поводов)... Плотный рабочий график и всё такое, видимо... Грустная тема...

Панель "СПДС Матер Объектов" - "Установить параметр" - далее выбираете ряд объектов геометрии и в открывшейся форме в числе прочего можете задать переменную, которая будет отвечать за видимость данных объектов. Значения переменной: 1 (видно) и 0 (не видно). А условия, когда 1, а когда 0, уже прописываете в скрипте. Что означает галочка рядом - не помню. Если при открытии этой формы нажать F1, то откроется нужный раздел справки. Нет, насколько мне известно.

Ну да. Т.к. как вы ставили фильтр по красным стенам и в выборку попадали только красные стены. А их в чертеже не было. Поэтому таблица была пустая.

Это оберег, чтоб он точно не пришёл?

С удивлением узнал, что в Нане вообще был кальтулятор Таблицы - сила!..

Ок.

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

И как-то уж очень избирательно...

А если не секрет, то почему? Чисто технически имею в виду, почему? В формате кода. На примере коннекта Стена-Дверь хотя бы. Я не понимаю... Есть 2 объекта из Базы: Металлопрокат (к примеру) и Двупольная дверь. Выше кусок кода из объекта "Огнезащита", он коннектится к трубе, берёт с неё плоскости и принимает её форму. Очень сомневаюсь, что Труба как-то заранее знала, где у моей огнезащиты располагаются плоскости. Это дочернему объекту надо знать плоскости родительского (что уже проблема автора Перемычки, а не ваша), а не наоборот. Или я ошибаюсь и во вшитых в код объектах как-то иначе всё устроено? А если оно устроено иначе, то... а ЗАЧЕМ? В моём представлении такие ограничения в коде прописаны условиями типа: (для стены, к примеру) ЕСЛИ объект=Дверь, то мы позволяем ему к себе приконнектиться. А нафига такие ограничения? Разве не достаточно просто "открыть" объект для доступа извне? К примеру (хоть и не проверял, но полагаю, что будет именно так) если из вышеупомянутого кода убрать подчёркнуто условие ЕСЛИ, то объект будет коннектиться просто ко всему, у чего есть обозначенные переменные. Почему с дверьми не сделать также? Там открыта часть переменных. Что мешает открыть плоскости? А где они находятся - мы и сами разберёмся... Неужели язык, на котором писано приложение не позволяет свободный коннект, тогда как простенький язык базы объектов - позволяет?

Не должны. Хотя это смотря какие расчёты. А что мешает проверить-то?

Во, значит не проглючило меня и действительно ни то, ни то не билось с реальной площадью. И хоть дело не в Ведомостях, лучше ситуацию оно не делает...

Если вы хотите сделать так (а это не совсем очевидно, соглашусь с @Volkov), то да, всё работает. Но ведомостей на чертеже я не наблюдаю. Нужен полный файл со всеми имеющимися там связями (связями между элементами, имею в виду). Или у вас и на этом уровне всё виснет? Если вы работаете в листах - то непонятно, что вы хотите сделать. Напишите внятную последовательность действий (вида: 1. Жму сюда (картинка). 2. Выбираю: копировать 3. и т.д.). Если сложно формулировать - скриншотов накидайте, как выше.

Кстати, Экспликация полов у вас одного масштаба, а блок пирога, который в ней вставлен - масштаба примерно в 20 раз меньше. Если выделить и то, и другое и поменять масштаб через "Масштаб оформления" (а это вполне нормальная механика работы) - пирог станет в 20 раз больше Ведомости.

и 5 сообщений вниз добавлено через 8 минут И ещё: Создаём на экране таблицу. Любую, хоть из одной ячейки. Видим вот это: Причём этот артефакт ВСЕГДА появляется где-то сверху-справа экрана, независимо от зума.

Да погодите, мож кто сейчас чего подскажет из разработчиков... Хотя я бы не особо надеялся...

Правда повторить этот опыт у меня не вышло. Допускаю, что я перед картинкой №1 я всё-таки чуть подвинул границы помещения. А почему это привело к ошибке..? Потому что они...... НЕ АВТООБНОВЛЯЮТСЯ!.. И правда, зачем..? Базовая функция всех таблиц СПДС (а в ведомостях, кстати, стоит галочка "автоотчёты" без возможности её отключить!) - это автообновление при условии, что отчёт строится на базе НЕпримитива. Тут - нифига... Корректируешь габариты помещения - спецификации неизменны. Добавляешь новое помещение - спецификации неизменны. И раз уж я всё-таки до них добрался, вдогонку к уже написанному кем-то в соседней теме... Давайте представим, что @forgeprojects проектирует жилой дом... В жилом доме 15 этажей, по 10 квартир на этаже, в каждой по 3-5 комнат. Итого мы получаем 150 квартир. У каждой - свой покупатель, которому нужно предоставить все ведомости (хотя бы на примере этих двух). Вот автор значит делает эти 300 ведомостей (и вот наплевать, что "ведомость отделки делалась разработчиками для клиента, который всё в одной ведомости считает" или как там было в соседней теме сказано - бывают разные ситуации, у нас вот всё считают порознь, заказчики-то все разные) и собирается выдавать чертежи (прикиньте на минуточку, о каких деньгах идёт речь). И возникает у него разумный вопрос: "А я нигде не облажался случайно?" И само собой, он как ответственный проектировщик, захочет сам себя проверить. А теперь вопрос разработчикам: "КАК ОН ЭТО СДЕЛАЕТ?" Помимо банально перепутанных слоёв отделки (тут только ручками проверять, никак иначе) у такой самопроверки есть 2 пункта: 1. Все ли комнаты внесены в Ведомости? (как я понимаю, Ведомости настроены не на область, а на НАБОР объектов (но это тоже не проверишь никак), т.е. на добавление/убавление помещений не реагируют). 2. Все ли данные актуальны? (т.к. Ведомости не реагируют и на изменение габаритов (как минимум, остальные свойства не пробовал) помещений). Поскольку я более или менее знаком с таблицами, то (помимо вариантов "пересчитать ручками" и выполнить альтернативную проверку другими таблицами) я вижу 2 способа самоконтроля: 1. В СПДС-табличках есть очень полезная функция: они подсвечивают объекты, с которыми установлена связь, вот так: Открываем Ведомость - нет такого... Отследить не получится... Ок. 2. Команда SPREFSHOW (предположим, что @forgeprojects прочитал от корки до корки "Руководство пользователя" и знает о ней, наверняка это так). Выделяем 2 ведомости и обычную табличку, жмём SPREFSHOW, видим: Печаль... Связи ведомсти тоже не транслируют... Что остаётся делать автору? - выделять каждую из 300 Ведомостей и заново переназначать им Помещения, видимо...? Т.к. даже обновить их все одной кнопкой нельзя: Реген - нет, Обновить - нет, spregenobj - нет, spregenstd - нет... Возможно, эти Ведомости и реагируют на какое-то общее автообновление (была где-то вроде такая команда хитрая, нигде не обозначенная, на форуме вычитывал) - но откуда автору её знать..? Справка-то по этим элементам писана по диагонали... Заметьте, мы сейчас говорим про человека, который эти чертежи ДЕЛАЛ и всё в них знает. И он может зная, как оно всё у вас устроено, сэкономить себе кучу времени и вставить в чертёж Ведомости в саааамый последний момент (которого в проектировании, к слову, в принципе не бывает). А вот теперь прикиньте, что я как ГИП должен его проверить. И вот тут лично у меня наступает ступор. Т.к. я НЕ ЗНАЮ способов проверить, а правильно ли работает Ваша автоматика. А пост выше про "разные площади" намекает на то что она легко может работать и неправильно (или правильно, но по какой-то неочевидной логике, про которую в Справке "не успели написать"). И вот мне как проверяющему уже придётся либо обновлять все Ведомости вышеописанным порнушным способом, либо изголяться ещё как-нибудь... А значит они (Ведомости) категорически не будут использоваться. Т.к. механика их работы: - непонятна. - неизменяема. - неконтролируема никоим образом. Такое ощущение, что эти элементы делали даже не программисты, а практиканты. Какие-нибудь студенты-медики... А проверял ОБЩИЙ итог их работы - видимо, кто-то очень далёкий от строительных чертежей... Короче... Я не знаю, как уважаемые разработчики видели работу этих Ведомостей, но вот вам взгляд пользователя... У кого-то возможно иной. Но лично я этим пользоваться не смог бы, мне просто страшно было бы... И это только 2 ведомости из 7... И это только Архитектура... Сделайте уже открытый код у всех этих таблиц и сделайте их ОБЪЕКТАМИ базы, а не вот этим... И всем будет счастье. Пользователи сами слепят из всех них конфету за неделю. И вам же сюда пришлют на блюдечке...

Ох ты как интересно.... То, что выше на картинке получено следующим методом: проставлено помещение, привязаны к нему 2 ведомости, помещение РАСТЯНУТО, ведомости изменились. А теперь удаляем ведомости и вставляем их из таблицы опять: