Обновление Xdata с кодом DxfCode.ExtendedDataWorldXCoordinate

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

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

World Space Position
1011. Unlike a simple 3D point, the WCS coordinates are moved, scaled, rotated, and mirrored along with the parent entity to which the extended data belongs. The WCS position is also stretched when the AutoCAD STRETCH command is applied to the parent entity and when this point lies within the select window.

Возможность достаточно интересная и даже работает - эти точки "таскаются" вместе с примитивом при перемещении, копировании, повороте и даже копировании через буфер. Но без подводных камней не обошлось - они не меняются, при редактировании свойств примитива через палитру свойств.
При попытке попробовать найти ответ на вопрос наткнулся на тему, где подсказали использовать методы Arx. В частности метод acdbEntUpd. Так ли это или можно что-то предусмотреть методами .Net?

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

При попытке попробовать найти ответ на вопрос наткнулся на тему, где подсказали использовать методы Arx. В частности метод acdbEntUpd.

Покажи где наткнулся? Вообще-то acdbEntUpd - это не по теме...

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

При попытке попробовать найти ответ на вопрос наткнулся на тему, где подсказали использовать методы Arx. В частности метод acdbEntUpd.

Покажи где наткнулся? Вообще-то acdbEntUpd - это не по теме...

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

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

Там конечно немного другое, но в одном из комментариев автор указал, что ему это нужна из-за наличия  Xdata.

Это совершенно из другой оперы. В твоём случае ты должен отслеживать изменение примитива в панели свойств и самостоятельно изменять Xdata.

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

Там конечно немного другое, но в одном из комментариев автор указал, что ему это нужна из-за наличия  Xdata.

Это совершенно из другой оперы. В твоём случае ты должен отслеживать изменение примитива в панели свойств и самостоятельно изменять Xdata.

Тогда напрочь теряется весь смысл расширенных данных с кодом 1011 ))
Даже если выяснится, что во всех остальных случаях все нормально и нужно только изменения через палитру свойств обработать, то у меня вопрос - а как эти изменения поймать? Это ведь надо заиметь объект до изменения и сразу после...

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

то у меня вопрос - а как эти изменения поймать? Это ведь надо заиметь объект до изменения и сразу после...

Теоретически это возможно при помощи пары событий: Database.ObjectOpenedForModify и Database.ObjectModified. В первом сохраняешь состояние, во втором сравниваешь текущее и сохраненное.

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

то у меня вопрос - а как эти изменения поймать? Это ведь надо заиметь объект до изменения и сразу после...

Теоретически это возможно при помощи пары событий: Database.ObjectOpenedForModify и Database.ObjectModified. В первом сохраняешь состояние, во втором сравниваешь текущее и сохраненное.

С самого утра прокручиваю в голове варианты и пути решения и прихожу к выводу, что придется отказаться от расширенных данных с кодом 1011 и придумать другой вариант. В принципе, идея уже родилась и буду начинать над ней работать.
К вопросу о XData: я правильно понимаю, что в XData примитива я могу помещать только данные с кодами из группы 1000-1071? Пробовал другие коды - ловил ошибки. А если я буду использовать XRecord, то там я могу уже любые коды использовать?

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

К вопросу о XData: я правильно понимаю, что в XData примитива я могу помещать только данные с кодами из группы 1000-1071? Пробовал другие коды - ловил ошибки.

Да. Об это четко сказано в документации.

А если я буду использовать XRecord, то там я могу уже любые коды использовать?

Да. Но добавишь себе проблем, связанных с копированием XRecord.

[Дмитрий Загорулькин]

Дмитрий Загорулькин подсказал интересную идею с использованием расширенных данных, которые меняются вместе с примитивом

Подсказать-то подсказал, но сам, честно говоря, никогда не пробовал этот механизм. Я о нем узнал еще когда писал на LISP, отметил на будущее эту возможность, но так и не воспользовался ею. Одна из причин - я крайне редко и неохотно использую Xdata из-за их ограничения по размеру и нелогичной (с моей точки зрения) надобностью регистрировать приложение, чтобы их использовать.

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

А не баг ли это, случаем? Может поинтересоваться в АДН, что они об этом думают?

Теоретически это возможно при помощи пары событий: Database.ObjectOpenedForModify и Database.ObjectModified. В первом сохраняешь состояние, во втором сравниваешь текущее и сохраненное.

А в третьем событии (Application.Idle, Document.CommandEnded, Editor.EnteringQuiescentState и т.п.) уже можно редактировать расширенные данные. И при каждом чихе, эта троица событий будет отрабатывать: проверять тип объекта, есть ли у него РД, нужно ли их менять... А когда меняешь РД, нужно не забывать отключать эти события, чтобы не уйти в рекурсию. В общем, тот еще головнячок. Но, раз способ со спецкодами не работает, я не вижу другого решения.

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

А не баг ли это, случаем? Может поинтересоваться в АДН, что они об этом думают?

Нет. Не баг. Если логически подумать, то понятно почему изменение свойств примитива не влияет на значения XData.

А в третьем событии (Application.Idle, Document.CommandEnded, Editor.EnteringQuiescentState и т.п.) уже можно редактировать расширенные данные.

Нет. Редактировать можно (и нужно) в ObjectOverrule.Close.

[Дмитрий Загорулькин]

Нет. Не баг. Если логически подумать, то понятно почему изменение свойств примитива не влияет на значения XData.

Я, честно говоря, не вижу логики.

Редактировать можно (и нужно) в ObjectOverrule.Close.

Это проверенный способ? Это не будет ли более сложным способом, чем через события? Просто ранее Вы советовали выполнять модификацию как раз в событиях:
http://adn-cis.org/forum/index.php?topic=380.msg868#msg868
http://adn-cis.org/forum/index.php?topic=743.msg3975#msg3975
Почему в этом случае через ObjectOverrule?

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

Я, честно говоря, не вижу логики.

Логика в том, что группы XData трансформируются обычно при вызове AutoCAD'ом метода TransformBy примитива (в командах _MOVE/_ROTATE и т.д.) или SetStretchPoints (для команды _STRETCH). В случае же изменения координаты в Панели свойств никакой трансформации не происходит. Просто одно значение меняется на другое. Что делать с XData в этом случае непонятно и проще всего просто ничего не делать.

Почему в этом случае через ObjectOverrule?

Я нашел замечание Tony Tanzillo по этому поводу:

The best possible way to deal with problems like this, is to use an ObjectOverrule, provided it is constrained using some kind of Filter (ObjectId filter, XData filter or XDictionary filter). Unlike the ObjectModified event of the Database, within the Close() override of the ObjectOverrule, the notifying object that is about to be closed can be modified, and more-importantly, any additional changes made at that point will be undone along with all other changes made prior to that, by whatever operation made them. 

Т.е. в методе ObjectOverrule.Close можно безопасно изменять объект перед его закрытием. Это не приводит к рекурсии и не нарушается работа _UNDO/_REDO в отличие от того, что происходит в событиях Database.
Сам я не использую Overrule, и не проверял это утверждение, но склонен доверять Tony Tanzillo.

[Дмитрий Загорулькин]

Логика в том, что группы XData трансформируются обычно при вызове AutoCAD'ом метода TransformBy примитива (в командах _MOVE/_ROTATE и т.д.) или SetStretchPoints (для команды _STRETCH). В случае же изменения координаты в Панели свойств никакой трансформации не происходит. Просто одно значение меняется на другое. Что делать с XData в этом случае непонятно и проще всего просто ничего не делать.

Согласен, логично с точки зрения реализации. Но с точки зрения использования - никакой логики. Смысл использования этих кодов, если они в этом случае не обновляются? Я вот не могу придумать ни одного сценария использования. Зачем тогда вообще этот инструмент нужен?

Т.е. в методе ObjectOverrule.Close можно безопасно изменять объект перед его закрытием. Это не приводит к рекурсии и не нарушается работа _UNDO/_REDO в отличие от того, что происходит в событиях Database.
Сам я не использую Overrule, и не проверял это утверждение, но склонен доверять Tony Tanzillo.

Надо попробовать. Спасибо!

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

Согласен, логично с точки зрения реализации. Но с точки зрения использования - никакой логики. Смысл использования этих кодов, если они в этом случае не обновляются? Я вот не могу придумать ни одного сценария использования. Зачем тогда вообще этот инструмент нужен?

В том то и дело, что эти коды появились еще в DOS-овской версии AutoCAD, когда у Autodesk'овцев еще и в мыслях не было, что появится панель свойств, в которой эти свойства можно будет редактировать. Ну а потом видимо решили не ломать то, что уже было. Но как развивать такую возможность видимо придумать не смогли.

[Дмитрий Загорулькин]

Ах вот оно что! Теперь пазл сложился 
Спасибо!