Jump to content

ЛиС

Пользователи
  • Posts

    221
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by ЛиС

  1. ОШИБКИ: 1. В настройках сетки параметр Основная линия через: не может принимать значение отличное от 5. 2. При вычерчивании с включённой сеткой в режиме указания точки (будь то центр рисуемой окружности или точка копирования и т.п.), курсор, попавший в точку пересечения Основных линий сетки, может стать невидимым. Причём либо целиком, либо частично в зависимости от положения на экране и масштабирования чертежа. Короче, если включить сетку и шаг, вызвать команду Построение окружности по центру и радиусу, и поместить курсор в точку пересечения этих самых основных линий, а потом покрутить колесо мыши, сразу станет всё понятно. У меня это выглядит так, что он то виден, то не виден, то видна лишь его горизонтальная часть. 3. При использовании в режиме редактирования полярного, объектного отслеживаний и режима ортогональности в совокупности с объектными привязками, рядом с курсором в сплывающем сообщении отображается расстояние и угол его смещения относительного узловой точки. При этом разрядность величины смещения всегда составляет 2 знака после запятой и не зависит от значения параметра Точность меню Формат-Единицы.... 4. ЗАМЕРЗАНИЕ ВЫДЕЛЕНИЯ ОБЪЕКТА: Имеются 2 блока, пересекающиеся друг с другом своими примитивами. Вызываем команду Обрезать, указываем в качестве опорного один из них, а в качестве обрезаемого - второй. В итоге: обрезаемый блок выделяется и, естественно, не обрезается. Но, при отмене команды по Esc, второй блок продолжает отображаться выделенным, хотя в окне Свойства в Объектах значится Нет набора. Дальнейшие нажатия Esc не сбрасывают отображение этого блока в нормальное, ситуацию можно исправить лишь непосредственным выделением этого блока, и сбросом выделения всё по тому же Esc. ПОЖЕЛАНИЯ: 1. Во время создания/редактирования объекта, проходящего по другому объекту того же цвета (отрезок по сплошной штриховке, например), его отображение должно как-то выделяться (например, пунктирной сеткой, как в AutoCAD). Это несколько дезориентирует, особенно когда штриховка очень широкая. Актуально при вычерчивании с шагом. 2. Кнопка включения/отключения отображения сетки должна действовать только на активное пространство. Так при работе в пространстве Листа она должна работать с сеткой самого Листа, но не трогать сетку видового экрана и наоборот - при редактировании видового экрана она должна работать лишь с его сеткой и не изменять состояние отображения сетки самого Листа. Сейчас же они включаются и отключаются одновременно и, накладываясь друг на друга, не позволяют на них ориентироваться. Плюс ко всему, настройки Сетки в Модели и в каждом из Листов должны быть независимыми, ровно как и состояние их отображения. 3. Регулятор масштаба экранного отображения весов линий как в AutoCAD Формат-Веса линий. А также возможность задания действительного значения для веса "По умолчанию", а вес "По блоку" для объектов, не входящих в блок, приравнять к "По умолчанию". 4. Помню поднимался вопрос о запоминании Зумов и Панорамирований. С одной стороны это чушь. Меня в AutoCAD это жутко напрягает (бывает в поиске мысли так прогуляешься по чертежу, что потом, когда она вдруг придёт, пока всё отменишь, она уже и забудется). С другой стороны, когда отменяемое действие не находится в поле зрения, можно просто что-нить лишнее (читай "нужное/ненужное") отменить. На эти грабли уже тоже 100 раз наступали. Бывает смотришь в документ, видишь место и думаешь: "ё-моё, я ж это правил!" и невольно начинаешь верить в потусторонние силы. Поэтому, чтобы раз и навсегда оставить программу не виноватой, я предлагаю действия Зума и Панорамирования следующие сразу за операциями редактирования всё-таки запоминать, а те, которые следуют за ними уже нет. Таким образом при отмене мы сначала переместимся в то место, где что-то отменяется, а потом уже осознанно отменим само действие. 5. Добавить в nanoCAD некоторые варианты построения отрезков, дуг, окружностей, эллипсов, которые штатными средствами (в том числе используя привязки) без лишних геометрических построений реализовать нельзя: Отрезок: 1) Касательный к 2-м кривым 2) Биссектриса угла 3) Касательный к кривой из её точки Окружность: 1) Заданного радиуса касательная к одной кривой, проходящая через заданную точку 2) Касательная к трём кривым Дуга окружности: 1) По двум точкам, как по диаметру 2) По двум точкам и численному углу раствора Эллипс: 1) По диагонали описанного прямоугольника (либо по центру и углу описанного прямоугольника) 2) По трём вершинам описанного параллелограмма 3) Касательный к двум кривым в указанных точках, проходящий через третью заданную точку Причём кривой может быть как окружность или её дуга, так и эллипс и его дуга или сплайн. 6. Хотелось бы, чтобы скопированные объекты (в частности штриховка и полилиния) наследовали от родительских объектов их положение по порядку следования. 7. Функция Быстрого выбора по ПКМ в Объектах выбора кроме конкретных типов объектов должна позволять выбрать все объекты разных типов, отвечающих общим для всех них критериям выбора. В AutoCAD для этого случая в типах объектов присутствует пункт Несколько. Плюс ко всему, на данный момент даже для тех типов объектов, какие уже можно выбрать, имеется слишком мало критериев выбора. По хорошему там должны быть перечислены вообще все пункты свойств, а перечень критериев выбора должен быть жёстко связан с перечнем общих свойств, обычно отображаемых в окне Свойства для данного набора объектов. Понятно, что при нынешней реализации интерфейса инструмента Быстрого выбора это приведёт к вырастанию списка в высоту до непозволительных размеров, поэтому я думаю лучше всего будет за столбцом Объект добавить столбец Критерий или Свойство, где так же, как и в Объектах нужное значение будет выбираться из выпадающего списка. 8. Добавить в меню Сервис-Настройка... возможность изменения на ряду с цветом ещё и толщины линий сетки, а то в яркий солнечный день "неосновных" линий сетки практически не видно. 9. Настоятельно прошу сделать возможность раздельного задания веса линий и веса текста у выносок также как у размеров (если в настройках жёстко задан конкретный вес линий, то он относится лишь к линиям, а вес текста задаётся обычным инструментом для выделенных объектов - из выпадающего списка панели инструментов Свойства, ну и из окна Свойства соответственно). 10. Объектная привязка к исходной точке штриховки, а также возможность ручного указания местоположения этой точки (в диалоге редактирования штриховки есть инструмент изменения исходной точки, но как он работает и что делает, непонятно)
  2. А вот и очередной более существенный недостаток, связанный с текстом. 1. В новом документе создём однострочный текст любого содержания с текстовым стилем GOST 2.304 с параметрами: Высота - 3,5; Степень сжатия/растяжения - 0; Угол наклона - 0. 2. Создаём копию этого текста любым из существующих способов - те же параметры копии текста принимают значения параметров исходного текста. 3. Изменяем параметры исходного текста на следующие: Высота - 3,5; Степень сжатия/растяжения - 0; Угол наклона - 15. 4. Создаём новую копию - параметры новой копии текста принимают следующие значения: Высота - 3,3807; Степень сжатия/растяжения - 1,0353; Угол наклона - 15. Дальнейшие эксперименты показывают, что высота и степень растяжения копии текста зависит от угла наклона исходного текста.
  3. Вот именно поэтому эта тема называется не Ошибки, а Недостатки функционала.
  4. Ничего нормального тут нет, это заставляет целиться в нужную часть отрезка, что не очень удобно, особенно когда их много и они мелкие, а выделить рамкой их нельзя. Приходится постоянно масштабировать. По моему это как раз более логично, что при единственно возможном направлении продления, отрезок будет продлён вне зависимости от того, в какую из его точек укажут.
  5. Ещё одно замечание по поводу продления отрезков. Опираясь на тот же рисунок, если в качестве опорного выбрать только отрезок d, то отрезок a продлится до него, если щёлкнуть на нём только в нижней его половине. Т.е. щелчёк в области верхней конечной точки отрезка a ни к чему не приведёт.
  6. Если долго вчитываться, можно и в букварь въехать . Некогда было визуализировать, теперь объясняю: Вызываем команду Удлинить, задаём параметр all, жмём Enter. Щёлкаем мышью сначала в отрезок a около его нижней конечной точки, он удлиняется до отрезка d. Затем щёлкаем последовательно на отрезки b и c вблизи их левых конечных точек - в результате ни один из них не удлинится. Очевидно, что отрезок b изначально "смотрит" в уже существующую до вызова команды Удлинить часть отрезка a, а отрезок c - в продлённую во время выполнения этой команды. Теперь отменяем процедуру, повторяем заново, но только теперь сначала щёлкаем на отрезок b вблизи его левой конечной точки, а потом в отрезок a вблизи его нижней конечной точки, и только лишь затем в отрезок c вблизи его левой конечной точки. В результате продлятся отрезки a и b, а c опять не продлится. Если теперь вызвать команду Отменить (Ctrl+Z), то отменится продление как отрезка b, так и отрезка a, т.е. отменится целая прошедшая сессия выполнения команды Удлинить, а не одно последнее продление.
  7. Очередной недостаток, связанный с уже озвученной командой Удлинить. То, что поддержка параметра all имеется, это - хорошо, и даже то, что командная строка после вызова команды выходит из фокуса и для набора этого параметра нужно щёлкнуть в неё мышью - тоже полбеды (о выходе командной строки из фокуса кто-то ранее уже писал тут на форуме). Тем не менее огромным недостатком является то, что в процессе использования команды не берутся в расчёт ею же только что достроенные линии. Т.е. продлять отрезок до только что продлённого другого отрезка она отказывается. Причём вне зависимости от того, до уже существовавшей перед вызовом команды его части или до только что продлённой. И на сколько я понимаю, по той же самой причине команда Отменить (Ctrl+Z), применнёная во время выполнения команды Удлинить, отменяет все построения, выполненные в текущем сеансе использования команды, а не только последнее продление.
  8. А вот и не да. Имею массу документов, текст в которых создан AutoCAD-шрифтом romans.shx. Коэффициент сжатия в свойствах текстого стиля задан 0.8, угол наклона 15. Смотрю в свойства текста - там всё так и есть. Редактирую по двойному щелчку - соответствующие поля пустые. Такими их и оставляю, жму ОК - текст становится шире. Смотрю в свойства - коэффициент 0, угол наклона 15. Снова редактирую по двойному щелчку, указываю коэффициент руками, жму ОК - текст сжался. Смотрю в свойства - коэффициент 0.8, угол наклона 15. Ну и да, при дальнейшем редактировании того же самого текста по двойному щелчку, коэффициент сжатия уже отображается, угол - по прежнему нет, но он и не менялся. Посему я делаю вывод, что как раз-таки окно свойств кажет истину, а окно редактирования с ним в этом не дружит, хотя возвращать значение они должны, по идее, из одного и того же места.
  9. Признаюсь, с углом наклона погорячился, он не изменяется вроде. По крайней мере в нескольких чертежах не изменился. За высоту текста речи не было. А вот коэффициент сжатия точно сбрасывается в 0. Причём в окне настроек он по прежнему не отображается, но в окне свойств также по прежнему видна действительность.
  10. Ну раз так, тогда вот вам очередной недостаток: при работе с документами, созданными в AutoCAD, свойства однострочного текста, написанного его же shx-шрифтом, в окне свойств в nanoCAD отображаются верно в полном объёме. Но при редактировании по двойному щелчку мыши, в окне Настройки текста остаются пустым поля Коэффициент сжатия и Наклон. Если туда ничего не вписать, по нажатию на ОК программа присвоит им значения равные 0.
  11. Вот теперь цитирую свою изначальную мысль: Именно БЕЗ НЕОБХОДИМОСТИ. Когда происходит простое пересохранение файла AutoCAD в nanoCAD, привязка к нему какой-то новый формы происходит именно БЕЗ НЕОБХОДИМОСТИ. Да, я могу согласиться, что автоматическое привнесение в активные типы линий и текстовые стили новых элементов, выполненных согласно ГОСТ, имеет смысл. Но в чём проблема автоматически проверять, используется ли эта форма в документе при закрытии? Всё равно же после следующего открытия она опять привяжется и опять можно будет выбрать и её текстовый стиль и её типы линий. И уж после того, как ими воспользуются, удалять её уже не надо будет, потому как тогда, действительно, без её использования "поплывут" соответствующие объекты.
  12. Ув. oVal, мы с Вами, по всей видимости, друг-друга недоперепонимаем. Я беру файл, созданный в AutoCAD, открываю его в nanoCAD, жму кнопку Сохранить, закрываю файл, открываю его в AutoCAD и - здравствуйте! Делается всё на одной и той же машине. Нет тут использования других шрифтов или типов линий, файл был просто пересохранён. Зачем в этой ситуации привязывать к нему что-либо? По поводу размеров. Самым обективным является пример выравнивания знака шероховатости относительно выносной размерной линии, расположенной не ортогонально командой align. Но выкрутиться можно и тут, только через другое место.
  13. Вот как раз для тех, кому затруднительно, и создаются Вами вышеперечисленные программы. При относительном нанесении размеров методом копирования. Я стараюсь между ними выдерживать определённые расстояния.
  14. Этот способ нами успешно применяется уже давно. Для нас он является необходимо-достаточным. Часто знаешь как выглядит документ изнутри, но не помнишь точно его имени. Поэтому вполне достаточно взглянуть на эскиз и понять то это или точно не то. Не особо-то это и правильнее. На этапе внедрения nanoCAD в производственный процесс, многие машины будут оставаться при AutoCAD, за которыми работают люди, понятия не имеющие о nanoCAD. Ходить везде добавлять эти файлы не особо интересное занятие. Причём ладно б действительно использовался в документе новый шрифт. Я как раз-таки и говорю о том, что неплохо было бы сделать так, что раз ни коим образом эта форма явно не используется в документе, то и не привязывать её к нему тогда вообще. И тогда тоже никаких выскакивающих сообщений не будет. Проблема в том, что при оформлении размерного стиля двойным кликом никуда не ткнёшь, там как раз из списка выбирается. А раз уж такая стрелка в системе есть, думаю в том списке ей тоже надо б появиться. В AutoCAD 2005 работает именно Пересечение. Я вообще к недостаткам отношу то, чем сам пользуюсь в AutoCAD, но его нет в nanoCAD, поэтому на вопрос "надо ли?" отвечу: "мне надо". И возможно не только мне. И не особо-то получается привязаться к отрезку в месте пересечения его выносной линией размера, когда там нет ни его начала, ни середины.
  15. Предновогодний рабочий процесс в совокупности с послепраздничным периодом реабилитации не давали следить за форумом. И видимо не мне одному, я смотрю тут особо ничего не изменилось. oVal, на поставленный мне вопрос по поводу привязок ничего конкретного ответить не могу. Лично я работаю не с особо густыми чертежами, поэтому включение всех имеющихся объектных привязок в AutoCAD мне особо не мешало. А в группировании их по функциональному признаку смысл может быть и есть, но лично для себя я его явно не вижу, так что как не поддержу, так и не опровергну. У меня начальник вообще рисует без включённых объектных привязок, а каждый раз из соответствующей панели инструментов выбирает нужную ему в даный момент привязку. Я так попробовал, мне не понравилось, я вообще не люблю лишние нажатия на кнопки панелей инструментов. А пока продолжу перечислять выявленные недостатки. nanoCAD 2.5.1700.857-1114 1. Программа не открывает файлы, в именах которых есть символы [ ] (квадратные скобки). Возможно с другими какими символами та же проблема. 2. Программа не вкладывает в файл эскиз его содержимого и не даёт делать его системе при отображении в проводнике в режиме представления файлов эскизами. Это не очень удобно, т.к. частенько приходится искать какой-нить файл, и без необходимости его открытия можно сориентироваться по его эскизу. 3. Следующий недостаток относится, на сколько я понимаю, ко всем программам-заменителям AutoCAD-а. nanoCAD прикрепляет к файлу форму GOST 2.303-68.shx, на которую потом ругается AutoCAD. Конечно, можно отменить выбор файла формы, но несколько поднадоедает делать это каждый раз. А для людей, которые вообще боятся всяческих выскакивающих сообщений в компьютере, это сродни приговору. Хотелось бы, чтобы без необходимости этого не происходило. 4. В свойствах размерного стиля, в списке форм стрелок размерной линии отсутствует Закрашенная замкнутая (Пустая замкнутая при этом имеется). Хотя это, по-моему, наиболее часто используемая форма стрелки у пользователей AutoCAD. Причём, если скопировать размер из документа, созданного в AutoCAD, то стрелка останется какой должна быть и в свойствах размера в списке появится её правильное название, но тем не менее выбрать его из списка будет нельзя. 5. Не работает привязка Пересечение в точке пересечения выносной линии размера с объектами чертежа. 6. В инструментах Обрезать и Удлинить меню Редактирование нет параметра Все, когда все имеющиеся объекты являются опорными. Это очень удобно, когда нужно просто обрезать объект до ближайшей точки пересечения его с другим объектом. В AutoCAD выбор этого параметра вообще удобно реализован по нажатию ПКМ после вызова команды.
  16. Не помню кто, но однажды один мудрый человек сказал: "Предупреждать надо". Это я к тому, что в NanoCAD команда zoom не имеет возможности задания масштаба отображения относительно листа, а не относительно экрана, как это делается в AutoCAD через {M}xp. Хотя, спасибо, что открыли мне глаза на соответствующий пункт в окне Свойств, там это удобнее задавать, чем в ком.строке набирать.
  17. Ну на самом деле работа привязок к объектам модели из листа всё-таки бывает нужна. Да, наносить в нём размеры, действительно, глупость. Тем не менее я иногда пользуюсь инструментом измерения расстояния в листе между объектами модели. Именно таким образом можно точно выяснить в каком масштабе отображается рисунок и именно таким образом удаётся выявить некорректность работы команды zoom (показать). В частности, задание параметра Масштаб равным 1 приводит к тому, что отрезок, имеющий длину 10 отображается совершенно неопределённой длины. Так в уже созданном ранее в AutoCAD документе, его длина составила 10,54, а в новом, созданном в NanoCAD - 5,18, при повторном применении команды - 7,54, при третьем - 3,35 и т.д. Именно этот недостаток позволяет мне использовать программу лишь в тех случаях, когда пространство листа не используется. Также очень непривычно работает эта команда с параметром Всё - от крайних объектов до границ видового экрана остаётся отступ. Хотя эта особенность могла бы быть полезна в тех случаях, когда рисунок выводится не в масштабе, а "как поместится". Тогда нет необходимости обеспечивать отступ от рамки до границ видового экрана. Единственный недостаток этой особенности в этом случае заключается в том, что этот самый отступ является неопределённой величиной.
  18. Ув. Alexey Sargsyan, а Вы теперь попробуйте произвести все те же самые построения с отключёнными "Объектным отслеживанием" и "Полярным отслеживанием" и ради интереса измерьте длину получившихся красных отрезков. На эту же тему обнаружился следуюий баг: при первоначальном выделении отрезка кликом, когда растягивание без полярных привязок осуществляется в его же направлении корректно, после отмены процедуры растягивания по Ctrl+Z, повторная попытка привела к сообщению об ошибке в командной строке: /Укажите точку растягивания: или [Базовая_точка/Копировать/Отменить/Выход/]: 10 /Неправильный ввод: 10 При этом никакое другое значение расстояния также не принималось до тех пор, пока курсор продолжал оставаться в той же точке. Причём если перевести курсор в следующую по прямой точку и указать то же самое расстояние равное 10, что соответствовало бы конечной длине отрезка по завершению команды равной 20, она станет равной 30.
  19. Указание приоритетов привязок от просто отключения не нужных в данный момент привязок как раз-таки позволит избежать лишних поисков глазами нужной кнопки и кликов по ним, что меньше заставляет мозг отвлекаться и позволяет ускорить процесс черчения. Задание приоритетов позволяет раз и навсегда подружить несколько постоянно одновременно используемых привязок. Под "одновременно" понимается то, что количество раз использования одной привязки примерно равно каличеству раз использования другой на протяжении всего процесса черчения. Нельзя также делать так, чтобы привязки были вообще взаимоисключаемыми, т.е. раз у одной из них приоритет больше, значит другая во время действия первой вообще не включится, как было в моём примере выше. А так, поставил бы я приоритет на "Ближайшая точка" чуть ниже, чем на "Средняя точка" и всё б работало. Лично для меня было бы интересно назначить всем привязкам равный приоритет и потом современем уже увидеть, какие привязки для меня лучше бы раньше каких срабатывали. И вот тогда, кстати, путём сбора статистики настроек как приоритетов привязок, так и любых других настроек программы с пользователей, можно было бы создавать "заводские" профили настроек наиболее удобных большинству людей. Идея, по-моему, не плохая - создать так кнопку "Отправить разработчикам файл конфигурации" и пусть анализируют. А вообще я согласен, что тема эта тоже спорная. Я лишь просто выссказываю свою точку зрения, как бы мне лично было удобно. И сообщение про переработку системы печати я видел, но ведь не факт, что в переработанной системе был бы учтён обозначенный мной момент.
  20. Да уж, удивительное свойство. Действительно, при точечном выделении растягивание отрезка по моему описанию сработало как надо. Дальнейшие попытки растягивть отрезок в различных направлениях приводили к различным результатам даже для одного и того же направления. Так, укорачивая отрезок с привязкой к средней точке, его конец сначала прыгнул выше, потом ниже и лишь на третий раз попал куда следует. Каждый раз курсор предварительно находился в зоне действия объектной привязки "средняя точка" и каждая новая попытка осуществлялась после отмены предыдужей по Ctrl+Z. Все процедуры осуществлялись при включённой сетке и шаге. Но вот с полилиниями всё равно проблема осталась. В новом документе создал я одноплечуу горизонтальную полилинию. Растягивание за правый её конец на расстояние шага удлинило её как надо. Дальнейшее растягивание без перевыделения за левый конец привело к тому, что при указании направления растягивания мышью влево, после ввода расстояния растягивания и нажатия Enter, полилиния наоборот укоротилась, т.е. левый растягиваемый её конец прыгнул вправо. Двуплечая же полилиния, даже будучи изначально горизонтальной, т.е. когда оба плеча лежат на одной прямой, ведёт себя неадекватно при растягивании за любой её узел при любом варианте выделения. Причём характерным является тот факт, что при нескольких подряд производимых попытках, отменяемых через Ctrl+Z, один и тот же узел при растягивании в одном и том же направлении занимает 2 строго определённых положения, с каждой попыткой чередующихся друг с другом. Так же на тему растягивания есть ещё один недостаток - программа не воспринимает привязку "Ближайшая" как точку направления. Эта возможность очень удобна, когда приходится укоротить отрезок на заданную величину без применения полярного отслеживания и полярных привязок. Ну и дальше про очередные недостатки. Объектные привязки работают неудобно, когда включено несколько их. Неудобство это заключается в том, что разные привязки имеют разные приоритеты. Возможно так и должно быть, но тем не менее работать с ними не удобно. Так, например, всё та же ситуация с растягиванием отрезка в режиме вычерчивания с шагом. При длине отрезка равном трём шагам, попытки укоротить его до середины с привязкой к средней точке будут безуспешны, если включены привязки "Ближайшая" и "Параллельно" даже если курсор будет расположен на средней точке и даже при максимальном приближении к ней - привязка "Средняя точно" просто не активизируется. Было бы не плохо ввести возможность указания приоритетов для привязок. Хоть по номерам, хоть по весам. Причём по весам было бы лучше всего - так можно явно задать равнозначные привязки и указать какие привязки будучи также равнозначными будут более приоритетными по отношению к ним. Ну и вообще это наиболее гибкая схема. Следующий недостаток - построение скруглений. При выборе объектов для скругления курсор находится в режиме выбора точки, а не объекта, в связи с чем нет выделения рамкой. Но и точечно без использования объектных привязок выбрать объект не представляется возможным. То же самое относится и к построению фаски. Ну и сюда же относится ранее обозначенный мною недостаток, что инструмент не применяется к заранее выбранным объектам и после вызова вновь требует их выделить. При выводе документа на печать в параметрах листа в области "Печатаемая область" из выпадающего списка можно выбрать "Всё целиком", но при этом не учитываются веса крайних линий. Из-за этого они будут напечатаны не заданной ширины, а в половину её. Это не есть хорошо, т.к. приходится пользоваться выделением печатаемой области рамкой, что в ряде случаев бывает очень неудобно, да и требует большего времени на подготовку документа к печати. А ещё и на нервы здорово действует, когда таких документов штук 30 подряд нужно распечатать. Я понимаю, что момент этот несколько спорный, потому как если учитывать вес крайних линии чертежа с рамкой, его размеры станут больше на толщину линии рамки и как бы не стануть влезать в заданный формат, что повлечёт за собой необходимость масштабирование чертежа с подгонкой под лист. Однако, если разобраться, этого делать никогда не требуется. Принтеры, печатающие на бумаге форматов А3 и А4 всё равно имеют непечатаемые поля и на них печать внешней рамки чертежа без масштабирования не возможна в принципе, в этом случае нужно её либо не рисовать совсем, либо просто не обращать внимание на то, что выводимая область чертежа не помещается на листе. А вообще по хорошему внешняя рамка нужна лишь при вычерчивании чертежа на бумаге, размеры которой больше размеров формата. Листы А3 и А4 обрезаны по формату, а стандартный ватман больше чем А1, поэтому при печати на ватмане тем более нужно не обращать внимания на сообщение о том, что чертёж не помещается. Мы вообще на рулоне печатаем, который по ширине ещё больше, чем ватман, так что проблем с помещением чертежей нет. Но всё это, конечно, дело принципа. Кому-то, возможно, предупреждающие сообщения и красные полосы спать спокойно не дают (таким людям я предлагаю в размерах бумаги указывать её действительный размер, а не выбирать из списка и тогда всё пройдёт). Поэтому я предлагаю рядом с выпадающим списком поместить чекбокс "Учитывать веса линий" или "Учитывать ширину линий", чтобы не путать его с одноимённым чекбоксом области "Опции печати". Он будет удобен не только при печати "всего целиком", но и при выделении печатаемой области рамкой - тогда можно будет выделять используя привязки, а не чуть дальше за объектами.
  21. С какого именно места не понятно? Процедурно делаем то, что я описал: cоздаём новый документ, в пространстве модели включаем шаг и сетку равными 10, строим горизонтальный отрезок между двумя узлами сетки, выделяем отрезок, хватаемся мышью за правый его конец и отводим курсор в правую сторону до того момента, как он прыгнет в третью точку, набираем на клавиатуре 10 и жмём Enter. Результат выполнения операции для разных программ выглядит следующим образом: AutoCAD 2005 Версия N.63.15 (Русская локализация) - nanoCAD 2.5.1700.857-1114 -
  22. Смею с Вами не согласиться. Во-первых, в общем смысле редактирование отрезка заключается именно в его перестроении относительно начального положения. При этом простое изменение его длины является лишь частным случаем, когда направление изменения лежит на той же прямой, на которой находится сам отрезок. Поэтому при растягивании отрезка за направление смещения конечной точки принимается луч, начинающийся в текущем её положении и проходящий через текущее положение курсора мыши. Использование полярных привязок и полярного отслеживания просто заставляет курсор примагничиваться к параметрически зависящему направлению, начинающемуся как раз-таки в текущем положении перемещаемой точки. При этом это самое направление задаётся именно текущим положением курсора, но просто он в области действия привязки занимает не то положение, в каком отображается. А вот стоит отвести курсор чуть дальше от этой области и ничего по сути не меняется: как проходило направление из текущего положения точки к текущему положению курсора, так и продолжает проходить, просто положение курсора ничто кроме пользователя не определяет. И AutoCAD работает именно так. А NanoCAD на привязки реагирует, а вне зоны их действия всё меняется. Во-вторых, всё это может быть спорно при вычерчивании отрезков. Но есть такая штука, как полилиния и с ней всё не так определённо. Средняя точка двуплечей полилинии это не начало и не конец, она - сама по себе, соответственно, её растягивание относится только к ней, как направление так и расстояние должны отсчитываться только лишь от неё. Ну и в-третьих, как я уже сказал, даже простое растягивание отрезка в его направлении с целью изменения его длины без использования привязок и отслеживания, но с использованием шага, когда текущее положение курсора явно ограничено, всё равно заставляет перемещаться его конец в неизвестном направлении. Так, например, включим шаг равным 10, соединим горизонтальным отрезком 2 точки. Растянем конец отрезка до тех пор, как курсор "прыгнет" в третью точку, введём в командной строке 10 и нажмём Enter. В результате конец отрезка не окажется в той точке. Логично ли это? И уж поверьте, AutoCAD так не работает.
  23. nanoCAD 2.5.1700.857-1114 По невыявленной закономерности программа теряет информацию из буфера обмена. По вставке из буфера может подряд вставиться не один десяток объектов, а может и десяток не вставиться: при очередной вставке просто ничего не вставляется, как-будто в буфере ничего нет. При этом, естественно, ничего другого туда не копируется, а просто могут выполняться сопутствующие операции по изменению чертежа, но без копирования. Также, вероятно, к такому эффекту приводит параллельное использование других программ, но опять же без копирования чего-либо в буфер обмена. Так, например, прямо сейчас я тестирую данный баг и параллельно пишу это сообщение. После очередного переключения обратно в nanoCAD, вставился только один объект, второй сразу же за ним уже не вставился.
  24. Вот в очередной раз наткнулся на общий на мой взгляд недостаток функционала как NanoCAD, так и AutoCAD. До сих пор никто мне не смог ответить на вопрос, зачем может быть нужна возможность перемещения выделенных объектов простым перетаскиванием за контур одного из них без вызова каких-либо команд? Мне это только лишь мешает, особенно, когда не заметишь. При точечном выделении, когда проще не рамкой выделять, а кликом, может показаться, что просто мимо объекта ткнул, а на самом деле он немного сдвинулся. Потом при дальнейщем относительном построении с привязками к этому объекту начинают не срастаться размеры. Хотелось бы, чтобы описанная возможность была исключена из NanoCAD, ну или хотя бы могла отключаться.
  25. Обнаружился ещё один серьёзный недостаток в сборке 1114. Обычно при создании отрезка или полилинии после указания первой точки, вторую можно задать численно - длиной отрезка, причём его направление будет определяться лучём, проведённым из первой точки к текущему положению курсора мыши до нажатия Enter. То же самое относится и к растягиванию уже созданного отрезка за узловые точки - в какую сторону потянул, в том же направлении он изменится на заданную длину. Однако в NanoCAD этот принцип соблюдается лишь при создании отрезка. При его растягивании без использования режимов ортогональности, объектного и полярного отслеживаний, точка смещается в неявном направлении. Это очень существенный косяк при вычерчивании рисунка по сетке, когда не столь важны привязки, сколь нахождение узлов объектов в узлах сетки.
×
×
  • Create New...