KosM

Проблемы bvg с тем, что не работало часть функций, которые работали у всех остальных, вроде бы, решились. Мы же с вами частично имеем отношение к IT в той или иной мере. Если что-то не работает (но утверждают что должно), первое что надо делать - снести и вновь поставить приложение, что и было сделано в данном случае.

Вообще, Электро создана тоже на .NET. Получается, что можно спокойно уже сейчас поставить Электро, поставить реферансами с проекта dll-ки нужные и что-то дописывать в Электро, используя все то же самое что есть у разработчиков. Проблема в документировании. Т.е. мы даже не стараемся что-то прятать или скрывать от других. Проблема только в том, что взять чужой код и там начать что-то делать можно, но очень сложно. API подразумевает, какое-то описание модели и того как система примерно работает и набор примеров, изучив которые можно что-то написать самому. API существуют в полном объеме, но вот какого-то описания или примеров нет. Можно конечно взять .NET dll-ки и прям с них получить C# код, который можно смотреть и делать по аналогии. Но формально, в классическом смысле, API нет. Вопрос зачем это надо, и можно подумать скольок времени понадобится, чтоб дать возможность регистрировать свои команды и что-то дописывать над моделью. Загрузить сеть, пробежаться по объектам, собрать какую-ту информацию (делать свои отчеты какие-то) - это достаточно быстро. Другой уровень это самостоятельно создавать объекты-электро и делать между ними связи. И самый последний уровень, это вообще давать возможность создавать свои типы оборудования, наделять их своим поведением. Вот это совсем не быстро.

Тестовая проверила. На наборе проектов, что у нас имеется "Сохранить как" работает на той версии, что выпустили. Возможно, вы поставили версию поверх бэты. Снесите все. Установите коммерческую версию. Если не поможет, то попрошу у вас проект - будем на нем смотреть.

Сейчас, чтоб выйти из ситуации можно добавить в таблицу, допустим, тех же кранов запись, что это комплект оборудования. Счетчик + кран + дроссель + ... (что еще надо). Можно сделать УГО для крана нужное, и считать что узел с приборами. Установить "кран" на плане и привязать к БД. В итоге, в спеку уйдет сколько к вас таких комплектов есть. После получения спецификации, если надо подправить руками и расписать N комплектов, на конкретное оборудование. В планах есть, сделать "узел", который можно установить на план и накидать в него любое оборудование из БД. Чтоб это все шло в спецификацию. Но это в следующих версиях.

Нашли. Исправили. Перевыпустить к 6.0, кажется, не успеем. Версия уже прошла через тестовую и готова к выпуску со дня на день. Сильно критично чтоб из-за этого останавливать выпуск? Есть вариант чуть позже собрать новую сборочку и заменить 6.0 в дистрибах для скачивания. Может еще что-то обнаружится и исправится.

Может еще что-то делаете, кроме фона? Проверили на нескольких машинах. Все ок. Большинство разработчиков используют при тестировании белый фон. Проблем таких не наблюдалось. Если есть желание можно изучить проблему поглубже. Связаться по скайп, и посмотреть в живую. Запустить нанокад отдельно самой Электро. Чтоб понять вообще от куда ноги растут.

Нашли исправили.

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

Игорь, то что Вы проекты доделывайте на той версии что есть - это умное решение. Да, переход на новые версии может ждать сюрпризы. Если бы разработчики жили по принципу "не трогай, то что работает", то продукт умер, точнее бы даже не родился, давным давно. 1. Стояки просили много пользователей, потому что париться с "дальними связями" на 12-этажном доме, где надо протянуть 5-10 стояков, было занятием для людей с очень крепкими нервами. К сожалению, ни пользователи ни разработчики не знают "идеального решения" как сделать "эту фишку". Разработчики предлагают решение, пользователи смотрят, выражают свое мнение, критикуют, говорят что надо доделать, находят где что не правильно. Дальше мы правим. Ровно так сейчас и со стояками. Поменялся сам принцип. И на старых проектах часть стояков могла отвалиться при конвертировании, т.к. для правильного конвертирования необходима наличие и правильная нумерация этажей. В некоторых случаях не было этажей, в некоторых были несколько этажей с одним номером и пр. Создавая новые проекты, пользователи будут использовать "новый принцип". Разработчики допилят, полученные замечания и это эволюция программного продукта. Ждать, что появится "идеальный продукт", где в версии 1.0 сразу все будет "как надо" с "крутым мастером стояков" - это утопично. Никто не знает как надо сразу. Такие отзывы как ваш, были до Электро ДКС 1.0, и при Электро 1.0 и при 2.0. 2. Да при переходе на новые версии надо смотреть, что изменилось. Если есть вопросы - задавать. Потому что софт "тяжелый", и это не казуальные игры c двумя кнопками. Часто люди не разбираются в чем-то до конца. Надо просто задавать вопросы, для чего этот форум и предназначен. Например, слои и повороты комплексного щита. Вот вам скрин, где все повернуто и цвет можно задать каждому шкафчику внутри комплекса шкафов индивидуально каждому. Если вы поставили синий, красный, зеленый шкаф на план, то при объединении их в группу/комплекс/единый шкаф - должен измениться их цвет? Кто-то думает, что да, кто-то что нет... вот в итоге какой цвет был тот и оставили, а если надо то индивидуально каждому можно назначить свой слой. (см. скрин.) 3. Если не ошибаюсь, то установленную мощность от резервных и аварийных потребителей правили. Сейчас, не помню войдет или нет в ближайший фикс для 6.1 или нет. 4. "Кривые привязки" - это общее утверждение. Не совсем ясно к nanoCAD-у это относится, или к вертикальному продукту, или всегда они были "кривые" и раньше с этим жили, а сейчас просто "накипело" и до кучи все собрали. Если есть критичная проблема, которая приводит к сильным неудобствам, привыкнуть сложно, теряется много времени, делается много ошибок - то конечно надо править и срочно и молчать об этом не надо. Для x64 отрепортили нам косяки с привязками (критичные), мы их отфиксили. Версия к выпуску готова. 5. То же самое с "параметрами фидера". Если начать копать по конкретной проблеме "что не получается", то или признаем что наша бага, а может и станет ясно "как это делать". 6. 2D-3D режим. Многие без него уже "никак", т.к. в 3D сразу всплывает пачка косяков, которые просто на плане не узреть. То что, нет индикации режима и где-то возникают сложности - это я писал выше. Никто не знает "идеального решения фишки". Появилось 2D/3D, появились какие-то новые траблы и неудобства. Может не надо вообще ничего нового вводить? Гарантировано с чем-то новым всегда идут гарантированные "сюрпризы". 7. Да для _x86 приложений 6Гб памяти не нужно. Использоваться будет максимум 3.5 и даже не 4-ре. Любой сис.админ это должен знать. Поэтому сейчас с техническим обновлением, мы выпускаем _x64 версию (в том числе 3.1 Дкс). Тут уже 6Гб должны использоваться. Потому что, чем удобней делаем тулзы, чем сильнее ускоряется проектирование, тем больше пользователи хотят всякой разной информации по модели (в каждом участке хотят знать каике кабели, на каких полках, с какой раскладкой жил и т.п проходят, до какого оборудования, от кого и т.д.). Это головная боль в проектировании при росте размеров и сложности проектируемых объектов. Разработчики таких продуктов просто ведут борьбу, чтоб отодвигать этот барьер каждый раз чуть дальше. На больших проектах, приходится ждать открытия окошка ЭТМ до неприличия долго, но когда я открывал "не демонстрационные" проекты в Revit, то что происходило с моим "крутым компом" и как все "шевелилось", рассказывать не буду, т.к. не мой продукт. Покупать, не покупать, использовать, не использовать - это, конечно, Вы сами решайте. То что в продукте всегда будут какие-то "раздражители" и "баги" - это без сомнения (если разработчики говорят вам обратное - они обманывают). Да. это плохо. Мы их стараемся лечить. Какие-то быстро, как только узнали. А какие-то просто так не выправить. Прикипают к "дальним связям", где сама концепция была убогой, и при попытке выкосить её получаем какие-то новые "раздражители", но их природа или временная или уже менее концептуальная и они решаются в одну-две итерации.Надо понимать, что разработка тяжелого софта с низкой ценой, тоже дело не из легких. У нас свои проблемы с огромным числом "хотелок" и своих и пользователей, но ресурсы не позволяют делать все это сразу. Что-то вообще висит годами в очереди.

Привязки к объектам НЭ зафиксили. И еще набор ошибок и косяков собранных за период с выпуска зафиксили. Обновление у нас уже лежит и нашу тестовую прошло, готовлюсь передать в тестовую нанософта. Очень надеюсь, что до НГ будет выпущено.

Да. Но для этого надо: 1. оборудование, которое идет в спеку и отчеты тоже забить на другом языке (контент базы данных) 2. Отчеты - имена колонок проставляются в шаблонах, можно задать на другом языке. 3. Выноски настраиваются тоже в настроечном файле. Но с большой вероятностью, по ходу возникнут нюансы, что где-то в коде (в бинарке) формируются поля с русским текстом. Так что, ответ, можно. В глобальном смысле получится перевести и подменить все, в каких-то нюансах могут возникнуть проблемы, что надо будет подправить код, чтоб на 100% все было переведено в итоге.

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

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

Причину на машине у другого клиента нашли, почему все не запускалось. На машине установлены шрифты с "invalid" именами. Компонент Microsoft Framework .NET 4.5 при инициализации WPF выдает ошибку и не работает. Данная проблема и как ее исправить на своем ПК описана вот по это ссылке. mxforum.mendix.com/questions/3166/Business%20Modeler%20throws%20exception:%20type%20initializer%20for%20'System.Windows.Media.FontFamily' stackoverflow.com/questions/9066930/wpf-window-crashes-on-startup-or-it-starts-but-hangs-and-does-not-render-conten Если вы со мной все таки свяжетесь по скайпу, то можно убедится что у вас ровно эта же проблема, а не какая-то другая. Я написал небольшой тест exe файлик, который надо будет у меня взять и запустить у себя.

DimaS. На машинах в тестовой, разработчиков, менеджеров - все замечательно. Видимо искать проблему придется ровно на вашей машине. Если у Вас есть скайп, то сообщите мне в личку. Там можно демонстрировать экран, я посмотрю в живую как это происходит в динамике. Программа успевает загрузиться, но дальше летит эта ошибка. На сейчас есть два клиента с этой ошибкой и очень хочется понять в чем дело. Отпишите в личку мне как с Вами можно связать по почте или скайпу.

А можно еще попросить скачать nanoCAD Электро 4.5 - и посмотреть работает ли Электрика? Запускается и создает проекты - будет достаточно. Потому что во втором случае у клиента вообще ни одно наше приложение никакой версии не идет. С такими же симптомами как у Вас. И еще видеокарту скажите какая.

Есть еще один клиент у которого так же ни один продукт ни одной версии на Win7 64 бита не идет. Пытаемся выяснить в чем дело, т.к. на всех машинах разработчиков, тестирования, менеджеров, и у подавляющего большинства клиентов все OK. Можно узнать Вашу операционку и ее разрядность + права пользователя + антивирус

Поддержка XP была убрана в силу целого ряда причин. 1. С выпуском каждой версии на XP стали появляться проблемы технологического характера в возрастающем количестве, которые приводили к очень "экзотическим" ошибкам на рабочих местах пользователей. Были случаи когда вообще приложение не устанавливалось, были случаи когда стабильно летит непонятные фатальные ошибки, которые на других XP и конфигурациях железа просто отсутствуют. При этом очень сложно определять в чем причина т.к. ошибка идет только на рабочей станции пользователя. При этом тут же у самого пользователя на "таком-же" соседнем ПК все работает. 2. Вертикальное приложения BIM класса (а у нас это именно BIM модели в рамках электрических инженерных сетей) всегда требуют большие вычислительные ресурсы. XP в подавляющем большинстве случаев 32-разрядные системы. Многие пользователи не разбираются, что надо включать флаг расширения памяти до 3Гб, получают на объектах среднего размера предел по вычислительным ресурсам и сразу для себя "вычеркивают" продукт. Для наших вертикальных продуктов мы рекомендуем хорошее железо и 64-разрядные операционные системы. Использование приложения на слабом железе и 32-разрядной XP в первую очередь приносит "мучение" самим пользователям по скорости/качеству работы приложения. 3. В ближайшее время готовится выход 64 разрядной версии nanoCAD, и вертикальные продукты на базе nanoCAD станen полноценными 64 разрядными приложениями. XP-64 разряда это очень редкий экземпляр. Это должно увеличить и быстродействие и существенно расширить пределы выполняемых объектов. Да. Мы понимаем, что часто смена XP на новое железо и операционную систему зависит не от проектировщиков, а от начальства. Если приложение "формально работает" на XP 32 разряда, то руководители вообще теряют стимул к обновлению железа своим проектировщикам (ну ведь работает), а проектировщики вынуждены работать на слабых машинах очень сильно теряя в комфорте/качестве/скорости выполнения работы. (бывает они этого даже не понимают). В некотором смысле прекращение поддержки XP это попытка разрубить этот узел. Начальство не хочет обновлять РМ своим пользователям, но теперь стимул к принятию этого решения станет куда сильней. Кто-то временно останется на старой версии, кому-то купят новые машины. Так или иначе этот вопрос рано или поздно решится. Может даже кто-то и откажется от использования приложения. Если руководители не понимают, что теряют время работников (которое оплачивается ими же), теряют в скорости/качестве выполнения проектов, в некоторым смысле теряют в лояльности своих подчиненных и займут радикальную позицию отказаться от использования софта по причине нежелания понести траты на два-три новых системных блока - это печально.

Спасибо за бальзам на душу. В защиту PSE - сейчас уже есть версия PSE 8. Готовим к выпуску. Ее оттестировали на 64 разрядах (были там проблемы, где плохо дружил с AutoCAD), так что новая линейка PSE, PS ОПС, PS СКС - будет работать не хуже (а знаю места, где и лучше) под AutoCAD (в том числе и под 13 и под 14). Постараемся сделать продукт одинаково стабильный и хороший и для любителей AutoCAD-а и для любителей nanoCAD-а. Если с CSoft Dev политические моменты уладим - выложим и бэту PSE.

В 4.4 уже исправлено. Совсем скоро будет бэта-версия.

Разработчики тоже думают что возможность групповой работы необходима :)/> Голова по этим вопросам в последнее время болит все чаще. В этом вопросе пересекается целый букет нюансов - филосовский, экономический и технический. Мог бы сказать много интересного, но не буду растекаться мыслью. Сейчас стратегия такая, что продукт эволюционирует развивается (просто так "идеальные сложные продукты" не появляются) и решать эту задачу придется. Кроме групповой работы появляются и другие нюансы с ростом размерности проектируемых объектов. Перейдем к конкретике: Сейчас несколько проектировщиков работают в своем проекте и делают свой кусочек планов. Потом Вы хотите эти dwg собрать вместе в один проект. Если соблюдать правила (одинаковые настройки), раздавать всем файл с одинаковым технологическим оборудованием и базами данных - то "сплясав некоторые ритуальные танцы по ручному перекладыванию файликов в проекте" можно таки свети несколько проектов в один. Возникают проблемы с общими настройками, возникают проблемы с общим ТЗ, возникают проблемы с БД. Возникают проблемы с тем, что если еще что-то в проекте проектировщик допилил, то опять все это надо "упаковывать" по новой. Вопрос к пользователям кому требуется такая фича: Достаточно ли на первом этапе будет возможность объединить несколько проектов в одно Решение (главный проект), чтобы поведение получалось ровно таким, что есть возможность подключить к Решению, готовый проект и чтобы планировки автоматом попали в Решение, (не важно как для пользователей) решился вопрос с Базами Данных, ТЗ, ГХ? В решении можно было делать общие спеки, КЖ и т.д.? (Чтоб в Решение можно было добавлять проекты, как сейчас в проект можно добавить готовый dwg).

В T.3 у вас лоток 60x200 поделен на 2 объема 82% и 18% 82% - однослойная прокладка без расстояний. 2 кабеля 31,8 18% - многослойная. 2 x 13 + 2 x 15,9 Объем 1: 2 * 31,8 * 60 = 3816 мм^2 (Полный объем = 60 * 200 * 0.82 = 9840) Заполнение Объема 1 = 39%. Объем 2: 2 * 13 * 13 + 2 * 15,9 * 15,9 = 843 мм^2 (Полный объем = 60 * 200 * 0.18 = 2160) Заполнение Объема 2 = 39%. В сумме = 3816 + 843 = 4659 мм^2 (Заполнение всего лотка 39%). Ровно это и показывает программа. Ровно те формулы что отписаны выше. У вас программа выдает такой же результат? Что у Вас вызывает сомнение в том, что это корректный результат?

Да. Проект посмотрю. Только files.mail.ru лежит, проект пока не достал.

Я точно знаю как считает программа: Многослойно: V = Cумма (Di^2) Однослойно плотно: V = H * Сумма (Di) Однослойно с расстоянием: V = 2 * H * Сумма (Di) С первой и второй формулой, я так понимаю, вообще вопросов нет. С третьим вариантом: Вполне можно считать что это достаточно верно, особенно если учитывать, что было бы неплохо оставлять запас (в настройках он там прописан для лотков отличный от 0-ля). В случае если надо уложить кабели максимально плотно на 100%, то в этом случае, да, было бы не плохо отнять один диаметр последнего кабеля, но сейчас это не делается. Если напишите, что это прям очень критично, и надо в лоток шириной 90 уложить два кабеля по 30-ть (лоток 120-ть это уже никак), то успеем в ближайшем выпуске это сделать. Вопрос только в этом? Или там и по однослойной укладке без расстояния тоже кажется, что что-то не так?

Да. Я очень хорошо понимаю что это очень нужно. С Электриком-ом поговорили, я свое видение того как это надо сделать, чтоб было максимально просто и быстро расставлять светильники в помещениях, высказал. Если у Вас есть возможность связаться с Электриком (почта/скайп/или прям тут) - пусть он расскажет что придумано по этому поводу, и Вы подтвердите, что это именно то что нужно. Реализуем мы это очень быстро, каких-то проблем я там не вижу.