LISP. Разница применения командных реакторов и реакторов dwg

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

Всем доброго. На днях, просматривая чужие коды, обнаружил примерно следующий код:

Код - Auto/Visual Lisp [Выбрать]

1. (vl-load-com)
2.  
3. (vlr-dwg-reactor "Main_dwg_begin_save_reactor" '((:vlr-beginsave . vlr-callback-beginsave)))
4. (vlr-dwg-reactor "Main_dwg_end_save_reactor" '((:vlr-savecomplete . vlr-callback-endsave)))

Сам я предпочитаю использовать командные реакторы (на команды _.save, _.qsave) как более предсказуемые. Собственно вопросы:
1. Правильно ли я понимаю, что реакторы на события BeginSave и SaveComplete будут срабатывать не только по командам сохранения файла, но и на автосохранение?
2. Если есть реакторы и на команду, и на события, то в какой последовательности они выполняются?
3. Могут ли быть какие-либо "подводные камни" при попытке закрытия файла с сохранением - как при применении командных реакторов, так и при применении DWG-реакторов?
Спасибо

[Александр Ривилис]

1. Правильно ли я понимаю, что реакторы на события BeginSave и SaveComplete будут срабатывать не только по командам сохранения файла, но и на автосохранение?

Да. А как иначе? :-)

2. Если есть реакторы и на команду, и на события, то в какой последовательности они выполняются?

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

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

Ясно, учту Спасибо

[Дима_]

Могут ли быть какие-либо "подводные камни" при попытке закрытия файла с сохранением - как при применении командных реакторов, так и при применении DWG-реакторов?

Я налетал на похожий: http://forum.dwg.ru/showthread.php?t=52228

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

Ага, спасибо Я, правда, стараюсь объектные реакторы вообще не использовать - уж больно много я от них головняка получил в свое время.

[skkkk]

Я, правда, стараюсь объектные реакторы вообще не использовать - уж больно много я от них головняка получил в свое время.

Алексей, расскажи, пожалуйста, подробнее: что за головняк?

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

Да на самом деле сразу сложились такие вещи:
- Если в файле прописать постоянные реакторы, то после аудита / восстановления файла в чужих руках, эти реакторы уничтожаются либо как мусор, либо как ошибки.
- Если делать непостоянные реакторы, то как-то и где-то приходится хранить ссылки на объекты, к которым они применяются. В принципе, это не проблема - до тех пор, пока не возникает вопрос с копирастингом, или внедрением внешней ссылки, или (опять же) чужими руками. Т.е. приходится прописывать дополнительные реакторы на клонирование объектов, на копирастинг, на внедрение ссылки и т.п.
В результате я пришел к выводу, что для постоянной работы лучше использовать все же командные реакторы: поведение их более предсказуемо, загрузка (как правило) выполняется быстро и просто. Если же надо что-то из ряда вон выходящее, то проще уже внутрь объекта засунуть словарь, а в нужном командном реакторе прописать чтение такого словаря. Правда, с этой технологией я как-то поигрался и потом на нее забил: она не оказалась сильно востребованной.

[skkkk]

Спасибо, Алексей.
Я и сам уже пришел к тому, что передавая комплект,  хорошо бы соблюдать правило: чем меньше "хвостов" - различной информации в теле файла, различных файлов в прицепе комплекта, - тем меньше проблем. Считаю, при этом важным обеспечить гарантии правильного отображения информации и возможности ее редактирования стандартными средствами Автокада (иначе какой тогда смысл в передаче dwg?) Если проект создан в среде, незнакомой "чужим рукам" на чужой машине, то после возврата из этих рук среда его всё равно уже скорее всего не примет. Реакторы же, несомненно, могут быть очень полезны человечеству при внесении изменений. Отсюда вывод: изменения вносить лучше всего в "родной" среде разработки, к тому же, это поможет удержать от возможных соблазнов обойтись без автора проекта, если конечно, нет желания править все вручную и наделать ошибок.