I would like the ability to lock input to the number of decimal places set for the relevant working unit. Without such an ability working units is nothing more than display units. Although I think it is important for both numerical and graphical input. Its less of a problem for numerical input - graphical input on the other hand becomes pretty much useless without a lock/snap/constrain.
If I understand your wish, you are wanting the graphical input of placing say the length of a wall, to snap to the Working Units defined in your model.
So wall lengths could only snap to whole or decimal millimetres or inches and not part of decimals as they do now if you just stretch something without typing an exact figure.
The problem with that is you would also have to start the wall (or what ever element) at an exact location based on your working unit settings.
You couldn't just pick any random point to start your wall.
You would get it to snap to the exact length you want, but it may be starting at the wrong position, so therefore the end will still be in the wrong position.
Everything would have to be set out from an exact origin point or 'snap' distances from that origin point.
That is what the grids and grid snaps are for.
But they really only work with larger units - feet or metres.
When you start getting down to 1/4 inches or millimetres (or decimals of those), you will find you will be zooming in so close to find an appropriate starting point (grid point) that it is not practical.
Tip for all users.
Don't just watch the value in the tracker and assume that what it shows is what it will draw.
You can't be accurate that way.
The tracker may show you the figure you want, but there will always be an extra decimal component that is not shown in the tracker - I know that is what this wish is about, but see my above problem with it.
You should always type an exact figure into the tracker if you want an exact length.
And of course you can snap to existing elements (assuming they are in their correct positions) so you don't have to type in a figure.
One of the forum moderators. Versions 6.5 to 27 Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10 Lenovo Thinkpad - i7-1270P 2.20 GHz, 32GB RAM, Nvidia T550, Windows 11
The wish is for the ability to lock input to working units decimal places - not for the inability to deviate.
The use for the ability becomes clear when working graphically - tracing references or sketching forms.
So lets say that you do that - it's early in the process so you can work with whole decimeters and angular degrees. After positioning the first node you graphically find the second node's first coordinate, lock it using Alt and then graphically find the second coordinate and place the second node and so on. Easy peasy - but sadly you are left with quite a mess of a model that won't be much fun handling going forward.
In order to avoid that you for each coordinate input (two times per node) have to:
- graphically find the wanted value of the coordinate,
Without the ability to lock/constrain to working units we can't really use purely graphical input as it will result in a model with arbitrary geometries. To avoid this we have to go through a set of operations that affects the workflow negatively.
No - there still seem to be some misunderstanding of the wish and it's justification. The wish is about being able to use graphical input to its full potential while still getting a model that is robust to changes in the number of decimal places. It might be that you don't see any benefit in that and thus inclined to find it superfluous and impractical in any and all cases but your objections are not real obstacles for the wish.
As noted before. It is about the ability to constrain - it is not about the inability to deviate. Your reference to snap grids and the notion that everything should line up make it seem that your understanding is that the wish entails the need for the constraints to hold simultaneously for each and ever way in which a geometry can be defined. It does not. Whats important is that it does for the ones chosen by the user to define the geometry. One would simply choose when and which input should be constrained and the choice is made based on the most practical definition (absolute/relative, cartesian/polar) of the geometry.
And regarding your zoom issue. If the relationship between the drawing and the working unit is such that it is impractical to set coordinates graphically then one should either change the working unit to something practical or simply do what is practical - use numerical input. So yes, working in 0,1, 1 or in the context of architecture means you will enter the radial coordinate numerically. But how about when when it is enough to work on 10, 100,1000, .... mm? How about angular coordinates?
Locking/snapping/constraining to number of decimals is a first step but if one can see the benefit in that then it's easy to see the benefit from possible further steps.
Working units could play a central role in modelling and thus become quick options rather than a project preference giving easy access to it so it can be changed frequently on need. Instead of expressed in just units and decimal places it could be expressed in unit multiples.
And instead of just one length unit it could be one for each coordinate type x,y,z,r. Make it possible to set a rotated axis for user origin/pole and this would mean that we now have a smart grid snap functionality based on the tracker. We no longer need to set up or change the construction grid to fit the situation. Just set the wanted working unit multiple in the view and constrain as wanted.