GripsOverrule vs DEMANDLOAD

[Александр Пекшев aka Modis]

Всем привет. Эта тема не вопрос, а просто предостережение всем, кто в своих плагинах использует GripsOverrule.

Недавно ко мне обратился один пользователь, который в моём плагине ловил странную (как мне тогда казалось) ошибку - eNotAllowedForThisProxy.
Учитывая, что плагин написан полностью на .Net, появление такой ошибки как минимум смущало. Пользователь даже прислал мне файл рабочий, в котором должна была возникать эта ошибка - но она у меня не возникала. При дальнейшем общении выяснилось, что у пользователя в этом файле находится и удаляется (плагином ExplodeProxy от Александра Ривилиса) порядка 200 прокси-объектов. А у меня в этом файле прокси нет вообще 
Имя данную информацию и гугл под рукой, я нашёл тему на dwg.ru, где обсуждалась переменная DEMANDLOAD. Выяснилось, что у меня (как и у большинства) эта переменная стояла в значении 3, а у пользователя в значении 2. Как только пользователь поменял значение с 2 на 3, то ошибка перестала возникать.

На мой взгляд такой взаимосвязи между значением переменной = 2 (ну или 0, 1, 2) и плагином, написанным на .Net быть не должно, но она есть!
Так что учитывайте этот момент в своих плагинах - или меняя значение переменной или просто уведомляя пользователя

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

Интересно бы глянуть на dwg-файл. И уточни на какой (какие) примитивы ты настроил GripsOverrule.

[Александр Пекшев aka Modis]

Интересно бы глянуть на dwg-файл

Файл прикладываю. В нём ничего особенного не найдете

И уточни на какой (какие) примитивы ты настроил GripsOverrule

BlockReference

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

Интересно бы глянуть на dwg-файл

Файл прикладываю. В нём ничего особенного не найдете

И уточни на какой (какие) примитивы ты настроил GripsOverrule

BlockReference

Ничего не понял. При DEMANDLOAD равном 2 в чертеже находится три прокси-объекта, из них два прокси-примитива.



И это WIPEOUT'ы. Где 200 прокси объектов, причем связанных с твоей программой?

[Александр Пекшев aka Modis]

Где 200 прокси объектов, причем связанных с твоей программой?

Так речь шла не о моих примитивах. Моих там как раз нет, потому-что пользователь их и не мог создать. Точнее - мог только создать и ничего потом не мог сделать. Без плагина мои примитивы будут просто анонимными блоками с расширенными данными.
А 200 штук наверное было из-за того, что скорее всего он прислал "урезанный" вариант файла.

Просто так проверить и что-то там найти не получится)) Или ставить плагин и пробовать с ним, или просто поверить мне, что вот такой случай имел место быть. Кстати, я потом больше не проводил экспериментов

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

Просто так проверить и что-то там найти не получится)) Или ставить плагин и пробовать с ним, или просто поверить мне, что вот такой случай имел место быть. Кстати, я потом больше не проводил экспериментов

Я готов тебе поверить, так как даже VisualLisp умудряется наследить прокси-объектами (постоянные реакторы). Просто было бы интересно понять каким образом это происходит в твоём случае.
Исключение eNotAllowedForThisProxy происходит при выполнении каких-то действий твоего плагина? Если да, то каких?

[Александр Пекшев aka Modis]

Проблема была именно при растягивании за ручки. Хотел сейчас воспроизвести проблему и... не получилось. И тут я вспомнил, что недавно вносил изменения в метод MoveGripPointsAt из-за другой проблемы. Я не думал, что между ними есть связь, но теперь понимаю, что есть! Проблема была в том, что при наличии моего плагина происходил фатал автокада при перетягивании ручек обычного динамического блока. Причем не всех ручек и не всех блоков.
Я пол вечера убил на банальный перебор вариантов этого метода, пока методом тыка не нашёл рабочий вариант. Вариант, который фаталил, выглядел так:

Код - C# [Выбрать]

1. public override void MoveGripPointsAt(Entity entity, GripDataCollection grips, Vector3d offset, MoveGripPointsFlags bitFlags)
2. {
3.     try
4.     {
5.             // Проходим по коллекции ручек
6.             foreach (GripData gripData in grips)
7.             {
8.                 // Приводим ручку к моему классу
9.                 var gripPoint = gripData as BreakLineGrip;
10.                 // Проверяем, что это та ручка, что мне нужна.
11.                 if (gripPoint != null)
12.                 {
13.                     // my code
14.                 }
15.                 else base.MoveGripPointsAt(entity, grips, offset, bitFlags);
16.             }
17.     }
18.     catch (Exception exception)
19.     {
20.         ExceptionBox.Show(exception);
21.     }
22. }

Фаталило на 15 строке
В итоге я сделал вот такую конструкцию:

Код - C# [Выбрать]

1. public override void MoveGripPointsAt(Entity entity, GripDataCollection grips, Vector3d offset, MoveGripPointsFlags bitFlags)
2. {
3.     try
4.     {
5.         if (IsApplicable(entity))
6.         {
7.             // Проходим по коллекции ручек
8.             foreach (GripData gripData in grips)
9.             {
10.                 // Приводим ручку к моему классу
11.                 var gripPoint = gripData as BreakLineGrip;
12.                 // Проверяем, что это та ручка, что мне нужна.
13.                 if (gripPoint != null)
14.                 {
15.                     // my code
16.                 }
17.                 else base.MoveGripPointsAt(entity, grips, offset, bitFlags);
18.             }
19.         }
20.         else base.MoveGripPointsAt(entity, grips, offset, bitFlags);
21.     }
22.     catch (Exception exception)
23.     {
24.         ExceptionBox.Show(exception);
25.     }
26. }

И проблема ушла. Видимо, проблема с DEMANDLOAD тоже ушла

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

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

В итоге я сделал вот такую конструкцию:

Если выбрано несколько ручек, то base.MoveGripPointsAt(entity, grips, offset, bitFlags) будет выполнятся несколько раз (столько раз, сколько не твоих ручек).