[ShaggyDoc]

Сначала присказка.

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

Значительная часть блоков используется для рисования масштабируемых символов - условных обозначений, таблиц и т.п.

Такие исходные блоки созданы, как правило, с единицей рисунка миллиметр, а размеры их такие, какие должны быть в миллиметрах на бумаге. Например, если блок, изображающий колодец, должен изображаться на бумаге в виде кружка (с какой-то внутренней начинкой) диаметром 2 мм, то он имеет размер 2 единицы.

Вставка блоков производится специальными программами с выбором из иллюстрированного дерева меню. Пользователь, собственно, и не знает о том, что вставляется блок. Ко вставке часто добавляется и дополнительное рисование. Блоки автоматически масштабируются и, при необходимости, поворачиваются.

Особенность ruCAD также в том, что возможен выбор между единицами рисунка (метры или миллиметры) и выбор масштаба печати модели. Как правило, здания рисуются с единицами миллиметр, а топография, генпланы, сети - с единицами метр.

Выбор масштаба и единиц осуществляется в специальном диалоговом окне и эти параметры сохраняются в собственном словаре рисунка. При выборе масштаба и единиц автоматически производится установка всех системных переменных в требуемые значения.

При работе с блоками (или другими масштабируемыми символами) происходит автоматическое масштабирование по следующему алгоритму:

1. Если блок вставляется в модель на вкладке Model, он масштабируется в соответствии с установленным масштабом печати модели
2. Если блок вставляется в модель на любом Layout через Vport, он масштабируется в соответствии с масштабом Vport
3. Если блок вставляется в пространство листа, он масштабируется с учетом собственного размера и единиц рисунка. Здесь учитывается, что в модели единицы могут быть миллиметры или метры, а в листе единицы всегда миллиметры.
4. Одни и те же блоки могут использоваться и в чертежах, сделанных в миллиметрах, и в чертежах, сделанных в метрах. Дюймы и прочие "попугаи" мы не используем из прынцыпа ("а че они негров линчуют"), хотя сделать это несложно.

Вот так работа выполнялась много лет, в версиях AutoCAD от 10 до 2007, созданы десятки тысяч чертежей как зданий, так и топографии, и все было нормально.

Теперь "сказка".

Вдруг, при работе с наружными сетями (единица рисунка "метр") обнаруживается, что блоки вставляются в неправильном масштабе - в 1000 раз меньше, чем нужно. Ни одна программа не менялась, но значительная часть стала работать неправильно. Вставка блоков, как правило, производится объектными методами, и лишь изредка, при интерактивной работе, используется (vl-cmdf "_.INSERT" ...)

Не столь давно пришлось возвращаться к "командной" технологии по двум причинам:
1. Необходимость работы в 3D, где, в хитрых ПСК, с объектами практически невозможно правильно работать.
2. Перспективное портирование в BricsCAD.

Расследование показало, что ошибка происходит при работе команды INSERT. Значение масштаба блока в нее передается правильное, а вот сама команда масштабирует блок по своему усмотрению. Но ранее этого никогда не было, или я этого не замечал.

Допрос 3-й степени выявил, что теперь команда INSERT работает с учетом системной переменной INSUNITS. AutoCAD сам пытается масштабировать блок, но делает это не всегда правильно. Такое поведение понятно и логично, когда блок перетаскивается вручную из DesignCenter или из палитры. Это действительно значительно облегчает ручную работу, но при автоматическом масштабировании происходят ошибки. Этот нюанс не документирован, или документирован намеком. Для режима "командной строки" правильнее было бы, чтобы переданные масштабы принимались безо всякой корректировки, а "вычисленные", в лучшем случае предлагались бы в качестве значения по умолчанию. Но это мое мнение, на которое Аутодеск наплевать.

Системную переменную INSUNITS ruCAD устанавливает при выборе единиц. Сделано это для того, чтобы чертеж, попавший в чужие руки (или в другую программу) был сделан "как надо". Если единицы рисунка - метр, то INSUNITS=6, а если единицы миллиметр, то INSUNITS=4. Это пригодится и на тот случай, если этот чертеж будет вставляться вручную.

В результате пришлось откорректировать несколько библиотечных функций вставки блоков - перед вызовом (vl-cmdf "_.INSERT" ...) устанавливать INSUNITS=4 (метр), а после завершения команды - восстанавливать прежнее значение. Так сделано потому, что все блоки созданы с единицами - миллиметр. Разумеется, после этого все программы заработали правильно.

"Вот такой гутен-морген, значить, получился с этим нюансом", как говаривал бессмертный капитан Фома Фомич Фомичев.

Надеюсь, эта заметка позволит программистам избежать таких "нюансов" в своих программах.

[ShaggyDoc]

Сообщение от Кулик Алексей aka kpblc > ShaggyDoc: вроде я ничего не упустил. Если чего лишнего понасовал в архив, прошу простить. [ATTACH]1181284788.rar[/ATTACH]

Спасибо. Пока проверять не на чем, отвечу позже.

[Кулик Алексей aka kpblc]

> ShaggyDoc : Там некоторые лиспы лезут в реестр, значения там прописываются в загрузчике и при установке комплекса. Иногда СОМ-серверы вылезают. Ни установку (скрипт), ни dll-ку я не включал. Первое - глупо, второе - стыдно, там код иногда так криво написан, что диву даешься, как только работает
P.S. Еще раз подчеркиваю, что огромное количество функций взято напрямую с ruCAD'a книжной версии. Максимум - переименование.

[ShaggyDoc]

Сообщение от Кулик Алексей aka kpblc > ShaggyDoc : Еще раз подчеркиваю, что огромное количество функций взято напрямую с ruCAD'a книжной версии. Максимум - переименование.

Проверил.

1. Библиотека понравилась. Она вполне самостоятельная. Много твоих интересных функций, прослеживается общая идея. Обнаружил и твои исправления наших прототипов - да, были ошибки.

2. Универсальная вставка блока в целом хорошо проработана. Интересная и правильная идея. Хорошие усовершенствования "нашей" части мультивставки.

Одна беда - для случая многократной визуальной вставки в 3D она не подходит принципиально.

Причина - использование CHANGE. Попробуй нарисовать в 3D "кубик" отрезками, вставить в каждую вершину какой-нибудь блочишко, и поймешь. Не даст CHANGE изменить координаты в другую плоскость. Именно из-за этого и пришлось использовать vl-cmdf "_.INSERT" - она позволяет вставить блок в любую точку трехмерного пространства, а поворачивать - в плоскости текущей ПСК.

В результате весь код сокращается до нескольких строк. vl-cmdf "_.INSERT просто обертывается в ru-error-catch. Теперь самым сложным является выяснение, нужна ли повторная вставка.

Пока у меня есть 2 варианта.
1. Запрос в цикле после вставки типа "Повторить?".
2. Включение в запрос точки вставки возможности прерывания по ESC.
"Точка вставки (ESC-прервать):". Реализуется легко, так как заход на повторную вставку вызвается просто через (vl-cmdf "") после (vl-cmdf "_.INSERT" ...)
Этот вариант мне не нравится, так как рушит концепцию избавления от привычки выходить из помещения не через дверь, а через окно с криком "Спасите". Кроме того, (vl-cmdf "") вызывает и побочные эффекты, связанные с попыткой повтора команды.

То есть теперь вопрос сводится к хитрой организации цикла.

[Sleekka]

Например, OpenOffice внедряется очень агрессивно. Вроде бы почти все в нем хорошо (ну, пусть удовлетворительно). Однако более внимательное исследование показало, что там есть такие ужасные ошибки, которые делают отдельные программы просто опасными.

:shock: , а где можно более подробно познакомиться с багами опена, подскажите плиз, тема очень актуальна.

[ShaggyDoc]

Сообщение от Sleekka Например, OpenOffice внедряется очень агрессивно. Вроде бы почти все в нем хорошо (ну, пусть удовлетворительно). Однако более внимательное исследование показало, что там есть такие ужасные ошибки, которые делают отдельные программы просто опасными. :shock: , а где можно более подробно познакомиться с багами опена, подскажите плиз, тема очень актуальна.

А нигде не найдете. OpenOffice критиковать не положено. Пришлось самому разбираться, когда Пособие писал.

Самое опасное на что наткнулся:

1. В OO Calc численные данные принимаются только с разделителем - запятой. Региональные настройки не влияют. Если между цифрами запятая вместо точки, то считается, что в ячейке строка. Изменить можно только, если применить для ячейки свойство языка и поставить, что в этой ячейке язык английский или японский.

2. Число, признанное строкой, в вычислениях считается нулем. То есть если в одной ячейке стоит 2,5 а в другой 2.5 то сумма будет 2.5

Excel в таких случаях дает ошибку и указывает ячейку с ошибкой. А Calc ошибок не выдает.

Представим, что в таблице считаются деньги, и кое-где оператор поставил десятичные точки, а не запятые. Имеет он право на опечатку. В результате в Calc будут неверные результаты и их можно обнаружить только путем пересчета "на счетах". "Тетки", которые с этим столкнулись, перестают доверять компьютеру вообще, тем более, что миллионы суммируют.

Но вот как интерпретирует эту «особенность» уважаемый журнал PC Magazie:

Злые языки утверждают, что Calc не позволяет идентифицировать некорректные формулы (эта возможность — одна из самых ценных в Excel). Это так. Зато во всех остальных случаях приложение OpenOffice.org оказывается вполне достойным как по удобству и возможностям, так и по корректному отображению файлов форматов Microsoft Office (в частности, XLS).

Приехали! Оказывается, если калькулятор неправильно проводит вычисления, то это не страшно. Это «злые языки» утверждают. Но «зато во всех остальных случаях» он вполне достойный. Какие такие «остальные случаи» для плохо считающего калькулятора?

Использование в качестве пресса для бумаг?

Ну, и еще всякие мелочи, когда в справке одно написано, а на самом деле - наоборот.

[Sleekka]

Спасибо за разъяснения, есть что сказать, но не буду отвлекать от темы.

[Кулик Алексей aka kpblc]

> ShaggyDoc: Ну я ж говорил, что, возможно, выполнял тестирование не в полном объеме (#13). Я попробовал представленный в #43 вариант, понял свою неправоту. Есть, конечно, некоторое количество идей, только они трудно (или вообще) нереализуемы... Особенно учитывая готовый вариант _-insert. Хотя стоп! Есть идея (правда, не проверял) - если (vl-cmdf "_.change") вернула t, то через (getvar "lastpoint") получить последнюю точку в WCS и назначить ее вставке блока. Проверять надо до получения угла поворота. На реализацию в течение выходных, боюсь, меня не хватит (по крайней мере сегодня точно). Сильно подозреваю, что придется еще за компанию и _.rotate привлекать, что совсем не гуд
> Sleeka: Тема в принципе отдельная, если сильно интересно, давай тогда организуем новый топик, там поговорим. Потому что я, например, настолько глубоко OO не исследовал

[ShaggyDoc]

В результате сделал так:

Код:

[Выделить все]

(defun _ru-block-multi-insert-scaled-rotated-or-angleask
    (block_name x_scale y_scale block_angle msg_insert msg_angle  /
        old_attdia  old_attreq  result is_angle_ok is_point_ok do)

 (setq old_attdia (getvar "ATTDIA") old_attreq (getvar "ATTREQ") do t) 
 (setvar "ATTDIA" 1) (setvar "ATTREQ" 1)
 (ru-var-clear-insunit)
 (while do
  (ru-error-catch
   (function 
    (lambda ()
      (princ (strcat "\n" msg_insert " или ESC для выхода: "))
       (setq is_point_ok
          (vl-cmdf "_.INSERT"  block_name "_PROTATE"
            (if block_angle block_angle 0)
             "_PXScale" x_scale "_PYScale" y_scale pause)
       )
       (if is_point_ok
         (progn
          (vl-cmdf x_scale y_scale
            (if (not block_angle)
             (progn (princ "\nУгол поворота<0>: ") pause) block_angle
            )
           )
         )
       )
       (setq do is_point_ok)
    )
   )
   nil
  )
 )
 (ru-var-restore-insunit)
 (setvar "ATTDIA" old_attdia)(setvar "ATTREQ" old_attreq)
 (princ)
)

Проверить нажатие Enter во время первой pause не сумел, в том числе с использованием grread. Пришлось разрешить прерывание цикла только по ESC. Соответственно пришлось во всех функциях, где допустим пустой выход, разрешить прерывание по ESC. С ловушкой ошибок это не страшно - программа не прерывается.

Вот эта функция теперь делает все, что надо (за исключением маленького нюанса) и стала компактной.

[ES]

Действительно, пора на форуме сделать отдельную ветку по тому же BricsCAD, ZwCAD и др.альтернативам акада. Но раз в этой теме затронули этот вопрос (и даже вскользь упомянули меня :

Приличные проблемы при загрузке меню (по крайней мере пока) - сужу по методике установки BricsCAD BonusTools от Евгения на сабитовском форуме

Посему вставлю и свои пять копеек.
Приятно читать, что профи наконец-то понемногу начинают обращать внимание и на BricsCAD. Сам я лиспом занялся меньше года назад именно из-за того, что приобрели на нашу организацию лицензии, а акадовский доп.софт часто работать отказывался. Но никто им и не занимался всерьез. Вот и пришлось "на старости лет" попытаться освоить лиспописание. Так что, возможно моя "хитрая" методика установки BricsCAD BonusTools связана не только с особенностями BricsCAD, но и с недостатком опыта, за что сорри . Хотя в ряде случаев действительно пришлось применять нестандартные методы именно из-за особенностей работы брикса. Так что опытным программистам тоже надо быть готовым к сюрпризам. Даже при расширении возможностей программирования в ожидающихся в ближайшее время обновлениях брикса. Но в любом случае уделять внимание BricsCAD стоит. Свою нишу этот продукт займет. Тем более, что и в России, и у нас в Украине его можно

купить с соответствующим оформлением платежных документов.

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