Currently, when a point is locked, the Control Points table can be used to change the position status. If the state is accidentally changed to edit and the cursor enters the screen, the previous position will be lost. Since the points are manually locked when a user is finalizing a point position, it would seem more consistent if the option to change the control point state is deactivated for locked points.
I’ve never noticed this behavior but I agree, it doesn’t make sense to change the position of a markup that’s locked. Previously, locking was a surrogate for finalizing a point.
Another behavior we’ve noticed and my students complained about is that you cannot jump to the position of a locked point by clicking on it on 3D rendering. You need to unlock it to click and jump. Since it is easy to move the point by accident when it’s unlocked, students hesitate to unlock and click a point to jump to its position. Was this behavior intentional? If not, is it possible to change it?
Thanks, @ezgimercan I am looking into a bug in the jump interaction described in this thread and will take a look at this behavior too. I don’t believe it’s intentional.
Sure that seems fine to me. To be easy to understand it should be applied in a manner where if the control point is locked, the position status (edit, skip, restore, clear) can’t be changed at all.
If the control point is locked:
and the position is defined, you can’t call to edit any of the states (edit, skip, restore, clear)
and the position is undefined, you can’t call to edit any of the states (edit, skip, restore, clear)
I’m not sure how you plan to show this visual either in the right-click context menu of the control points table or the position status buttons that exist above the control point table. It could be confusing if the point is locked, then someone deliberately tries to clear the state for it and then nothing happens. The nothing happening part is confusing as no indication why nothing happens.
