Vladimir-omsk

Идея очень хорошая. Я хотел разработчикам предложить ввести в настройки такую же настраиваемую опцию (рядом с автосохранением), но по итогам форума энтузиазм пропал. Хотелки и предложения: 1. Делать "Сохранить как" сразу при открытии файла. (Пояснение - не раз сталкивались со следующей ситуацией: файл с сервера открывают на одном РС, начинают в нём работать, периодически сохраняясь. В какой-то момент этот же файл открывают с другого РС (только для чтения) и используют "чтобы посмотреть". Потом на первом РС файл сохраняют и закрывают. Через некоторое время на втором РС закрывают весь NC (со всеми вкладками) и "на автомате" на все вопросы "Файл существует. Переписать?" отвечают "Да". Получаем, ессно, файл по состоянию его открытия на втором РС). 2. Сохранять версии по умолчанию в той же папке. 3. К имени в конце добавлять "vNN", где NN - номер версии 01-99. Важное дополнение - предыдущий № брать из состояния в папке, т.к. при одновременном открытии файла (как я описал в п.1) возможно, что версии с разных РС будут "через одну". 4. Период "сохранения как" - настраиваемый (10мин...60 мин) с интервалом в 10мин. 5. Период стирания минорных версий - настраиваемый от "0"(не стирать-ручное стриание) до 10 суток с интервалом 1 сутки. Надо также понимать, что такой режим "сохранить как" сделает возможным одновременное открытие файла любым количеством пользователей, причём предупреждений о том, что файл уже открыт, - не будет. Т.е. потенциально можно также получить проблему.

Ну как же нечем? Есть несколько популярных пословиц и поговорок: - На Бога надейся, да сам не плошай. - Надейся на лучшее, готовься к худшему. - Кто надеется на соседа, тот останется без обеда. Ну и так далее Теперь-то Ctrl+S на уровне автоматизма? Грустные это шутки, если честно, - в разрезе обсуждаемой стабильности... :-( И - нет, Ctrl+S не сильно привилось, поскольку пока сидели на NC5.1, применение Ctrl+S нередко давало сбои... (я уже писал выше). Поэтому и сейчас, на NC8, на простых файлах большинство надеется на автосохранение (ну, и Ctrl+S нажимают, правда мышью...), а на сложных начинают делать "Сохранить как..." и по окончании работы стирают лишние копии. И я не спешу их переучивать... Кстати "проектировщица и 4 часа работы без сохранения"- это был временный человек, взятый на срочный договор. До этого она работала в Автокаде...

В данном конкретном случае (который действительно редкость) мне ответили, что в параметрах автосохранения программы стояло "каждые 15 минут". Только вот ничего не сохранилось... И крыть мне особо было нечем, кроме очередных объяснений, что ПО ещё не совсем стабильно... и с получением очевидного ответного вопроса...?#@!! :-(

Я думаю, Вы этой фразой убили все Ваши рассуждения, которые были до и после... То что для Вас пустые разговоры - для людей - часы и дни рабочего времени. Когда ко мне приходит проектировщица и говорит, что потеряла всё сделанное за последние 4 часа - попробуйте её заставить воспроизвести последовательность действий. Ей нужно было сдать то, что упало, именно сейчас. И она судорожно будет восстанавливать всё потерянное, через каждые 5 минут нажимая "Сохранить как..." и плодя десятки промежуточных файлов. Ваше любимое Сонтрол-S совсем не панацея. Я всем пользователям плешь проел с этим сочетанием. Так вот: NC5, например, после падения ухитрялся не сохранить почти ни одного изменения, сделанных после начала работы, причём во всех открытых вкладках, несмотря на нажатие волшебного сочетания. Судя по многочисленным лайкам разработчиков на Вашем и подобным постах, разработчики, похоже, считают, что идёт война "разработчики против пользователей". Уверяю, это не так. Люди, находящиеся на форуме, искренне хотят получить хорошую программу, иначе бы их (нас) здесь не было. Мы с самого появления NC являемся для разработчиков огромной армией тестировщиков и ожидаем адекватного отношения, а не только реакции на конкретный баг, который мы Вам обнаружили. Пользователи просят повысить стабильность и вправе ожидать конкретного ответа - что для этого делается в целом? Например - есть монитор, про который Вы пишете. Так встройте его в дистрибутив, отключив по умолчанию (чтоб не было проблем с секретностью). Тогда большинство его включит, и, при очередном падении, не будет заставлять юзеров пытаться повторить действия последних 4 часов, а просто отправит разработчикам баг-репот. И странно, что об этом пишу я, а не сами разработчики.

:-))) Ключевым было слово "падало", а не "своего" :-)))

По-моему, Вы обижаетесь на то, чего я не говорил... Суть того, что я хотел сказать, - я очень редко сталкиваюсь с тем, чтобы другое прикладное ПО (под Windows) падало при обработке своего файла и само сообщало об этом. Настолько редко, что с ходу даже не вспомнил, когда такое видел. Да, бывает сообщение Винды "Программа совершила недопустимую операцию и будет закрыта..." Но это другое... Здесь же я предложил рассмотреть недопущение падения Нанокада как системную задачу, а не применительно к конкретной ситуации. В микроконтроллере, например, зависание ПО ликвидируется аппаратным WatchDog'ом. Возможно, сравнение и неудачное, но поясняющее то, что я хотел сказать. И фраза "Вы хотите сказать, что ни разу не сталкивались с падением Нанокада?" была конечно риторической и касалась как раз того, что факт ЛЮБОГО падения можно рассмотреть как побудительный для коррекции самой платформы с целью недопуска подобного... Фууу. Наверное, ещё подробнее свою мысль разжевать уже не смогу... :-)

даже в мыслях не было ерничать. Пользователь жалуется, но ни файла ни алгоритма действий не предоставляет. вносятся те баги, которые подтверждены фактами (файл проблемный, описание действий). Вы хотите сказать, что ни разу не сталкивались с падением Нанокада? Я писал о том, что ЛЮБОЙ факт падения ПО от попытки открыть в нём прикладной файл не есть правильно... Тем более, что о падении сообщает не Винда, а сам Нанокад. Значит, можно попытаться не допускать до падения.

очень жаль, ведь создать такие файлы искусственно весьма затруднительно. т.е. пациент скорее жив, чем мертв ) вот подробное описание "нажатия чего-то" было бы очень уместно. Так она и не падает совсем - нет файла нет падения. сохраняйте чаще Ctrl+S Я думаю, зря Вы так ёрничаете. То, что описано: "...Вопрос. А нельзя как то сделать так, что бы программа не падала на совсем. Ну то есть я могу понять если команда привела к ошибке, я могу понять, даже если она вообще в файле не выполнится до перезапуска файла, но когда вылетает программа с 5 не сохранёнными файлами, пусть и после одной операции (т.е. страшного то ничего не случилось), это сильно раздражает и приводит к потере времени..." действительно самое раздражающее в НаноКаде. Меня пользователи уже достали с претензией: "Программа упала, ничего не сохранилось". Сейчас, на 8 версии, это конечно, происходит реже, но тоже бывает. Мне кажется, сам факт падения ПО от попытки обработать прикладной файл нужно внести в число багов. Не смогла программа корректно обработать файл - пусть сообщит об этом. Но не падает. И не теряет данные других открытых окон.

Ну, если уж у Вас всё крутится в основном вокруг печати в pdf - поставьте бесплатный "Pdf-Creator". При соответствующей настройке работает c NanoCad безотказно. Мы в основном им и пользуемся.

Спасибо. Будем ждать выхода.

А что подразумевается под новой версией? Если говорить про free, то у нас установлена последняя сборка 2017. А если про исправления к коммерческой верси - то это всё же разные ветки... Способ черчения - вопрос вкуса...(и быстроты получения результата) :-) Если конструктору быстрее сделать так, а не скруглять прямоугольник, то я не буду его переучивать... В данном случае - была заготовка, из которой делался файл.

НаноКад 5.1. Ошибка при обрезке. Суть: Часть объекта, которая должна обрезаться, вместо исчезновения превращается в почти замкнутую окружность неимоверно большого диаметра. Описание: 1. Строим (полилинией толщиной 0,3) прямоугольник с закруглёнными углами (полилиния / дуга,центр / линейный / дуга,центр / линейный...). Последний сегмент строим командой "замкнуть" Получаем замкнутую полилинию формы прямоугольника с закруглёнными углами. (см. файл) 2. Стоим точно такую же полилинию, но замыкаем её не командой "замкнуть", а просто приводим конец последнего сегмента в начальную точку (с привязкой, ессно). 3. Пересекаем обе полилинии прямым сегментом другой полилинии (тоже ненулевой толщины) 4. Делаем операцию обрезки "прямоугольных" полилиний по сегменту пересекающих их полилинии. При указании места обрезки слева от секущей, незамкнутый "прямоугольник" обрезается корректно, а вот замкнутый превращается в окружность неимоверно большого диаметра (15 разрядов). Сторона обрезки критична - именно слева! При обрезке справа такой эффект получился только 1 раз (при многократных пробах) и то скоррелировать с какой-то последовательностью нажатий не получилось. Глюк обрезки.dwg

Проверил. Получилось. СПАСИБО! К своему стыду - я не знал такого способа выделения объектов. Похоже, описанная мной команда ZWCad'a "Экспресс/Блоки/Расчленить с преобразованием атрибутов в текст" работает именно так. Всем спасибо. Тему можно бы закрывать. Решение найдено. Хотя сомнения в правомочности разбиения полилинии остались... :-)

Да, Вы правы, я неточно выразился - имелась в виду именно ширина линий. А вот тут не знаю - зависит от точки зрения: полилиния - это примитив или нет? Если примитив, то она имеет параметр ширины и он должен сохраняться и не должен разэксплодироваться до другого примитива - обычной линии. А здесь совсем не так: попробуйте сделать обрезку полилинии - она сохранит ширину (как раз несохранение ширины полилиний при обрезке было одним из серьёзных глюков версии 3.0). Правда, обрезка - это не эксплодирование. Да, есть такое, но, например, в ZWCadе меню "Экспресс/Блоки/Расчленить с преобразованием атрибутов в текст" позволяет сделать разэксплодирование именно так, как мне нужно - с сохранением толщины полилиний. В этом плане мне понравилась идея oVal'a. Я пробовал немного по другому - с замораживанием "ненужных" объектов. Частично получалось, но не всё. Так что попробую - отпишусь.

В настоящий момент в версии 3,7 НаноКада команда explode, применённая к полилинии, превращает её в линию. Т.е. теряется толщина. Моё мнение - так быть не должно, ведь полилиния - такой же примитив, как и линия... Хотелось бы знать мнение сообщества на эту тему...? В частности у нас данное поведение команды "разбить" вызывает следующие проблемы: Нам передают dxf-файл из PCADа для разработки сборочных чертежей. Файл содержит большое количество блоков различных степеней вложенности (до 4-х). Так вот, корректно разбить блоки с сохранением толщин проводников невозможно.