и соответственно я не могу определить какая ручка перемещается.Можешь. Если переопределишь метод AcDbGripData::setHotGripFunc(GripOperationPtr pFunc), то сможешь выяснить какая именно ручка выбрана.
Можешь. Если переопределишь метод AcDbGripData::setHotGripFunc(GripOperationPtr pFunc), то сможешь выяснить какая именно ручка выбрана.
Мне кажется что ты перемудрил с subGetGripPointsAtSubentPath/subMoveGripPointsAtSubentPaths. Мне вообще непонятно зачем они тебе понадобились.
Пробовал добавить в метод MyEntity::subGetGripPointsAtSubentPathА почему ты её добавлял в subGetGripPointsAtSubentPath, а не в subGetGripPoints ?
Код - C++ [Выбрать]
pGripData->setHotGripFunc(HotEditModGripfunc);
Функция HotEditModGripfunc срабатывает только в момент выбора SubEntity (через Ctrl + клик мышкой)
Когда выбираю конкретную ручку для перемещения SubEntity функция не срабатывает.
Я думаю, что и в этом случае можно было бы ограничится subGetGripPoints/subMoveGripPoints.А как тогда получить ручки вложенного примитива? Ведь subGetGripPoints получает ручки только основного примитива.
Впрочем рекомендую посмотреть пример samples\entity\SubEntity из ObjectARX SDK 2009Этот пример я и брал за основу, там тоже используется getGripPointsAtSubentPath/moveGripPointsAtSubentPaths
А почему ты её добавлял в subGetGripPointsAtSubentPath, а не в subGetGripPoints ?Именно потому что subGetGripPoints дает только ручки основного примитива. (Пробовал pGripData->setHotGripFunc(HotEditModGripfunc) вставить в метод subGetGripPoints вложенного
Этот пример я и брал за основу, там тоже используется getGripPointsAtSubentPath/moveGripPointsAtSubentPathsТолько ты не обратил внимание, что используется совсем не так, как у тебя. Разберись как следует с этим примером.
А как тогда получить ручки вложенного примитива? Ведь subGetGripPoints получает ручки только основного примитива.Может получать и ручки вложенного примитива. Тем более, что это твой же примитив. при вызове subGetGripPoints возвращаешь ручки основного примитива и проходишься по всем подпримитивам и добавляешь их ручки к общему массиву.
Может получать и ручки вложенного примитива. Тем более, что это твой же примитив. при вызове subGetGripPoints возвращаешь ручки основного примитива и проходишься по всем подпримитивам и добавляешь их ручки к общему массиву.
Только ты не обратил внимание, что используется совсем не так, как у тебя
Не удается открыть проект SliderCrankUi (не обнаружен PathsToSdk.props)Сейчас нормально?
2) Type the command "AddSliderCrank":
...
b) On selecting the sub-entity, the sub-entity grips will appear on the screen. For example, if the connecting rod is selected, two grip points along the rod will be enabled. Using these grip points, the position of the connecting rod can be modified at both ends.
(При выборе подобъекта, ручки подобъекта появятся на экране. Например, если соединительный стержень будет выбран, две ручки вдоль стержня будут включены. Используя эти ручки, позиция соединительного стержня может быть изменена в обоих концах.)
Придумал для 2017 "костыль":
А в чем секрет, если не секрет?Особенность при работе этого кода в том, что при выборе subentity (т.е. через CTRL+клик) его ручки становятся все выделенными (красными). Как от этого избавиться я не знаю и по логике такого быть не должно (и в AutoCAD 2008 такого нет). Но если кликнуть по одной из ручек c Shift'ом (когда она становится синенькой), то в gripAppData только одна ручка. Попробуй так. Я еще и код слегка модифицировал:
Заметил ещё одну важную деталь.В любом случае должна быть выбрана только одна ручка и в этом случае в gripAppData будет одна ручка. Другое дело, что я не пробовал на > 2 ручках как их следует выбирать.
Для конкретного случая в примере все верно, но если предположить, что
ручек в подобъекте будет более двух (скажем N), то в методе subMoveGripPointsAtSubentPaths в коллекции gripAppData будет не одна, а N - 1 ручка
и, соответственно, код будет прерываться на проверке
Лучше эту проверку убрать, а в методе subGetGripPointsAtSubentPath вернуть как было в первом вариантеЭтот вариант не работает на визуальных стилях кроме 2D-каркас, так как в нём этот метод вызывается однократно, а в остальных дважды.
Вообще, интересно было бы узнать мнение разработчиков, почему при выборе subentity его ручки становятся все выделенными (красными).Отправлю. Думаю, что будут разбираться они с этим долго, так как такое использование крайне редкое.
Может быть у них для этого предусмотрено как сделать их не выделенными, или это всё-таки БАГ?
Значит решение где-то есть! Какой механизм выбора ручек используется там?Думаю, что там используется совсем другой механизм. Ведь там нет никакого реального SubEntity.
Думаю, что там используется совсем другой механизм.Интересно было бы знать какой?
Ведь там нет никакого реального SubEntity.Так и в рассматриваемом примере, тоже вроде бы реальных SubEntity нет, они вычисляются и рисуются в subWorldDraw?
За не имением лучшего этот вариант можно считать решением задачи.Не-не-не! Пока еще своё слово не сказала Engineering Team - мы ждём от неё информацию. Вот когда они скажут, что это единственный способ, а появление выбранных ручек при Ctrl+click - это баг, для которого нет решения - вот тогда можно будет остановиться.