ADN Club > AutoLisp / VisualLISP и DCL
LISP. Разница применения командных реакторов и реакторов dwg
skkkk:
--- Цитата: Алексей Кулик от 26-06-2013, 18:46:55 ---Я, правда, стараюсь объектные реакторы вообще не использовать - уж больно много я от них головняка получил в свое время.
--- Конец цитаты ---
Алексей, расскажи, пожалуйста, подробнее: что за головняк?
Алексей Кулик:
Да на самом деле сразу сложились такие вещи:
- Если в файле прописать постоянные реакторы, то после аудита / восстановления файла в чужих руках, эти реакторы уничтожаются либо как мусор, либо как ошибки.
- Если делать непостоянные реакторы, то как-то и где-то приходится хранить ссылки на объекты, к которым они применяются. В принципе, это не проблема - до тех пор, пока не возникает вопрос с копирастингом, или внедрением внешней ссылки, или (опять же) чужими руками. Т.е. приходится прописывать дополнительные реакторы на клонирование объектов, на копирастинг, на внедрение ссылки и т.п.
В результате я пришел к выводу, что для постоянной работы лучше использовать все же командные реакторы: поведение их более предсказуемо, загрузка (как правило) выполняется быстро и просто. Если же надо что-то из ряда вон выходящее, то проще уже внутрь объекта засунуть словарь, а в нужном командном реакторе прописать чтение такого словаря. Правда, с этой технологией я как-то поигрался и потом на нее забил: она не оказалась сильно востребованной.
skkkk:
Спасибо, Алексей.
Я и сам уже пришел к тому, что передавая комплект, хорошо бы соблюдать правило: чем меньше "хвостов" - различной информации в теле файла, различных файлов в прицепе комплекта, - тем меньше проблем. Считаю, при этом важным обеспечить гарантии правильного отображения информации и возможности ее редактирования стандартными средствами Автокада (иначе какой тогда смысл в передаче dwg?) Если проект создан в среде, незнакомой "чужим рукам" на чужой машине, то после возврата из этих рук среда его всё равно уже скорее всего не примет. Реакторы же, несомненно, могут быть очень полезны человечеству при внесении изменений. Отсюда вывод: изменения вносить лучше всего в "родной" среде разработки, к тому же, это поможет удержать от возможных соблазнов обойтись без автора проекта, если конечно, нет желания править все вручную и наделать ошибок.
Навигация
Перейти к полной версии