Связывание пользовательских объектов.

[Vt]

Здравствуйте. Помогите разобраться с реакторами автокада. Возможно ссылки на примеры. Я хочу реализовать связывание пользовательских объектов, при котором изменение одного из объектов вызывает изменение связанного (связанных) объектов. К примеру модель цепочки: тянем за один конец, и каждое последующее звено тянется предыдущим.
У меня идея такая: каждый из объектов имеет порты в данном случае по два порта, к каждому порту может быть подключен (а может быть и нет) один из портов связанного. Когда положение объекта меняется. Эта информация через порты передается связанным примитивам. То есть через порт получаем связанный примитив. Вызываем в этом примитиве метод, который обработает характер изменений и через другой порт вызовет этот метод у последующего и т.д. Правильный ли у меня ход мыслей в данной задаче? Какие реакторы больше подойдут? Пока еще  с реакторами для автокада мне не приходилось иметь дело. Буду благодарен за любую информацию.

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

И что от нас нужно?

[Vt]

Случайно на отправить нажал полностью не сформулировав  . Подправил предыдущее.

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

В примере с цепочкой я бы наверное делал бы иначе - один примитив, похожий на полилинию. При необходимости можно добавлять/удалять сегменты (вершины). В противном случае тебе придётся хранить коллекцию AcDbObjectId's ссылок друг на друга или, как ты предлагаешь, на "коннекторы". Тут реакторами ты не отделаешься. Обработку связанных примитивов придётся добавлять в кучу методов классов "воздуховодов". Потом ты пишешь по два порта у элемента. А если это разветвитель у которого может быть и три и четыре (теоретически и больше) порта? Тут всё очень не просто.
Потом нужно будет разобраться с операциями копирования/переноса, добавления/удаления. Понадобится много и разных реакторов. Наверняка, beginDeepClone, endDeepClone. Сразу всё не опишешь. Так что давай "впрягайся" (т.е. начинай программировать), а потом будешь задавать конкретные вопросы, типа: "как отследить копирование", или "как отследить копирование в буфер обмена", или "как перенести все связанные объекты".

[Vt]

Спасибо за ваши комментарии. Вот что я примерно решил: попробую реализовать идею с коннекторами, так как будут связываться разные объекты с разным количеством портов, таким образом, что бы в методах объекта не проводилось операций над связанными объектами (информация передается через порты и обрабатывается в объекте). В порте будет содержаться ссылка на связанный порт. Потребуются реактор изменения объекта, который запустит процесс. Нужно продумать каким-то образом, что бы он не срабатывал при изменении связанного объекта в следствии изменения главного, Опять же при переносе группы объектов. Реактор копирования, удаления...

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

таким образом, что бы в методах объекта не проводилось операций над связанными объектами (информация передается через порты и обрабатывается в объекте)

Врядли это у тебя получится с перемещением "ручек", т.к. в реакторе ты будешь видеть, что примитив изменился, но не будешь иметь информации что именно в нём изменилось. Так что в методе subMoveGripPointsAt наверняка придётся что-то делать со связанными примитивами.

[Дима_]

Врядли это у тебя получится с перемещением "ручек", т.к. в реакторе ты будешь видеть, что примитив изменился, но не будешь иметь информации что именно в нём изменилось.

Я делал близкие по логике манипуляции с объектами (overrul'ли всех видов) - не скажу что без "запинки", но вполне все решается через "чистые" функции преобразования (то есть не зависимо от предудущего состояния объекта создается однозначная свзяь - параметры->конфигирация).

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

Не буду говорить, что это невозможно. Я решал задачу очень похожую на ту, которую решает Vitaut Tryputsin. Там использовался ряд Custom Entity, экземпляры которых были "пристыкованы" друг к другу. Ряд из них представлял из себя линейные объекты (которые могли растягиваться). Ряд из них были "узловыми" (тройники, повороты, X-образные разветвители и т.д.). У меня обработка ручек всех связанных по цепочке объектов осуществлялась именно в обработчике ручек (subMoveGripPointsAt). Так как это часть коммерческого приложения, то исходниками я не буду делиться ни при каких обстоятельствах. А вот видео по возможности выложу.

[Vt]

Скажите, возможно ли в AcDbDwgFiler хранить массив указателей на присоединенные обьекты. например сейчас был присоединен один потом стало два, я undo и снова один. Или как это сделать?

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

Скажите, возможно ли в AcDbDwgFiler хранить массив указателей на присоединенные обьекты.

Хранить можно, но в своём (унаследованном от AcDbDwgFiler). А в стандартном как ты можешь хранить?

[Vt]

Я наверное неправильно сформулировал. Я не совсем понимаю тонкости работы методов этого класса writeItem () и readItem() но они позволяют хранить изменения обьекта. Например они принимают в качестве параметра экземпляр класса AcDbHardPointerId. Может мне попытаться наследовать AcDbHardPointerId и в этот обьект записать список id? что бы на него распространялось undo redo?

[Vt]

Кажется у меня есть одна идея. К примеру делаем метод который сначала записывает количество id объектов а потом по очереди производит запись. при считывании опять же вначале читается количество а потом по циклу считывается значения.

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

1. void writeIdList(const std::vector<AcDbHardPointerId> &idList, AcDbDwgFiler *pFiler)
2. {
3.        
4.         pFiler->writeItem((Adesk::UInt32)idList.size());
5.         for (unsigned int i = 0;i<idList.size();i++)
6.         {
7.                 pFiler->writeItem(idList[i]);
8.         }
9. }
10.  
11. void readIdList( std::vector<AcDbHardPointerId> &idList, AcDbDwgFiler *pFiler)
12. {
13.         Adesk::UInt32 count;
14.         pFiler->readItem(&count);
15.         idList.resize(count);
16.         for (unsigned int i = 0;i<count;i++)
17.         {
18.                 pFiler->readItem(&idList[i]);
19.         }
20. }
21.  

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

Может мне попытаться наследовать AcDbHardPointerId и в этот обьект записать список id? что бы на него распространялось undo redo?

Очень похоже на бред.

Кажется у меня есть одна идея.

Идея нормальная. Собственно говоря у меня реализовано подобным образом. Сильно сомневаюсь только в необходимости использовать AcDbHardPointerId вместо AcDbObjectId. И не забывай про форматирование кода на форуме. Я уже устал повторять. Читай у меня в подписи.