Grip SetAlternatePoint Fails

[renencon]

Hi,

When AcDbGripData setAlternateBasePoint method is used on a grip it seems to fail when the grip is shared.

Is this a bug?

thanks

Tasos

[owenwengerd]

The phrase "it seems to fail" is meaningless and not useful for describing the problem. What exactly are you doing and in what context, what do you expect to happen, and what actually happens?

[renencon]

Thank for your reply.

Ok

I am sorry, you are quite right, let me try and make it meaningful.

When you have grips that use an alternate point when dragging, for example you set grip point at say (10,0,0) and alternate point at (0,0,0) then when you make the grip hot and drag, a rubber band line is drawn between the dragged point and the alternate point(0,0,0).

I understand that this is the correct behaviour.

However, when that grip location point is shared between 2 or more grip points that functionality is lost and instead the rubber band line is drawn between the grip point(10,0,0) and the dragged point. I have tried several approaches to this with no success.

This is causing problems with the subMoveGripPointsAt because the offset in the first case is given from (0,0,0) and the other from (10,0,0).

The only way I can think of solving this problem is by handling this within subMoveGripPointsAt. But you will have a misleading rubber band line drawn. Is this a bug or is there another way of handling this situation.

I think this is also happening when grips with alternate points from two or more entities are shared.

Thanks again

Regards

Tasos

[owenwengerd]

When there are shared grips, AutoCAD makes some changes in how the grip operation is handled. If your grip with the alternate basepoint is shared with a grip that has the *same* alternate basepoint, I think AutoCAD should probably use the alternate basepoint in that case. However, if your grip with the alternate basepoint is shared with another grip that has no alternate basepoint, then I think what you observe is by design, and as you suggest, it is up to your code to handle the situation correctly.

I don't have any experience with alternate basepoints on grips, so I'm not sure *how* this should best be handled. Maybe somebody else can chime in with some ideas. One thought I have is that I'm pretty sure there is a grip flag related to how shared grips are handled. I don't have access to the ObjectARX SDK documentation at the moment to look up the flag, but this might be an avenue for you to explore.

[renencon]

Thanks Owen

One can use AcDbSelectGrip to filter out the grips that should not be involved in the grip edit operation. That works ok in some ways. For example the mouse does not snap anymore to a grip that has been filtered out by AcDbSelectGrip. Again, I have used AcDbSelectGrip and works as such. But these filtered out grips are still been used by the grip mechanism in some hidden way and are passed to subMoveGripPointsAt Method. That is why I say there might be a bug. ObjectARX documentation is sparse on this, it seeems to be frozen since version 2008 as other parts of the documentation. One has to run many trials to figure out how some classes behave. Maybe Autodesk should look into this.

Thanks again.

regards

Tasos

[owenwengerd]

Indeed, the documentation is practically useless. I am not familiar with AcDbSelectGrip. I see the header file, but how is it used?

The flag I mentioned in a previous post is kSkipWhenShared. I doubt that it has any effect on this problem.

[renencon · Accepted solution]

It is a protocol extension so use it as such.

For the problem I had I managed to implement a satisfying solution by using a hotgrip callback function.

Thanks for your thoughts anyway.

regards

Tasos