Create a cube, change to front view and then move the cube using the translate tool and not the gripper.
Click on a corner and then move the cursor up and hold the Z key for axis locking, Shark thinks that the Y axis is now the Z axis and will not move the block in a vertical direction if the Z axis locking function is used.

I have had models where the correct axis can never be attained no matter what you do and the gripper has to be used.
Some may say so what seeing as we can use the gripper, but my point is that this highlights an age old internal problem with Shark and is more than likely the cause of other problems.

Hi Tim, I understand that but I have many instances where Shark loses its orientation and the xyz is relative to nothing, while I understand that calling it a bug is incorrect, I feel that this is creating a bug like condition.

On one hand the gripper is staying orientated to the global coordinate system, then on the other the part is relative to the workplane, but here’s the thing.
While the xyz is relative to the workplane it also is relative to the global system as is shown by the fact that the part will move in the correct axis in the input field.

For instance, if I change to front view and move the part in a vertical direction it indicates that it is moving in the y axis, but in the data field it shows that the part has been moved in the z axis which is correct.

The attached image shows the scenario I am talking about, the part was rotated and the axis locking stayed relative to the front view but when I used the use view command the axis locking is now relative to nothing.

Edited by user Sunday, January 17, 2016 2:34:34 AM(UTC)  | Reason: Not specified

Thanks Mitch but mine was unchecked.
There is a definite issue with the workplane in V9, I did a side by side comparison with V8 for them and both programs operated totally different as far as the workplane is concerned.
Why would they do that, V8 and V9 are basically the same program so they should react the same, I think they are in denial as this bug requires a tear down as it is at the heart of the program.
Anytime a CAD system forgets which way is up..........you know you have serious problems.

I do feel that this is a long standing issue in the CAD/modelling community, xyz is a fixed system but you see some jokers using y as the vertical axis!!!!

To me they are thinking like machinists, if you are milling a part on a vertical milling machine you are always working on the x/y plane, if you need to machine another face on the same part you rotate the part and then you are still working in the x/y plane.
For me computer modelling and CAD is a different scenario, you are not moving the part when you go into front view, you are moving the world so the z axis remains in the vertical orientation and if you work on the front face you are working in the x/z axis.

I understand why they do it but I think it is causing a conflict, the gripper stays global, the part goes local but the input figure remains global, confusion rules.