V7 dangerous numerical overide change in behaviour from V5, V6

Drawing a line:

V5, V6:

1] Line, click to give start point, input “25”, press enter = constrains the line on screen to 25 units long.

2] A left click draws a line 25 units long and finishes the command.

3] OR Pressing enter again gives feedback of potential endpoints, so you can for example align the end point up with an existing entity. A left click then sets the endpoint and finishes the command.

4] OR pressing enter without setting a end point finishes the command with no line drawn.

V7, V8:

1] line, click to give start point, input “25”, press enter = constrains the line on screen to 25 units long.

2] A left click OVERRIDES the length constraint and draws a line of a length based on where the cursor is on screen when the mouse is clicked, and finishes the command.

3] OR Pressing enter again gives feedback of potential endpoints, so you can for example align the end point up with an existing entity. A left click then sets the endpoint and finishes the command.

4] OR pressing enter without setting a end point, draws a line 25 units long with its end point wherever the cursor was when the enter key is pressed.

While its arguable that the V7 / 8 behavior in point 4 is a better or at least more expected result than previously; the behavior in point 2 is definitely not.

There is no way that setting a length constraint for a line should be able to be overridden mid-command without the user deliberately specifying an alternative numerical constraint – allowing a mouse click to set an unknown length AND finish the command without confirmation of the result is not on.

Generally when creating a 2D drawing, where this command is used a lot, you get used to the visual scale of the drawing, and will often, especially when drawing with ortho on, click to set the endpoint of the line pretty close to where it would be at that length relative to other entities.
So its easy to miss that when you thought you were placing a line 25 units long, in actual fact its 26.5 or 23 or something – an unwanted result that should not be possible, and was not possible in V5 / V6.

Please adjust this command to behave as V5 / V6.

Note: - this overriding of the numerical input occurs with other input also – move, circle (by centrepoint), and probably a stack of others…

I think there was a bug where the Enter was indeed ignored, and this has been fixed. Typing, + Enter , gets you the constrained distance, and you can click anyplace you like to end the command, typing + Enter twice gets you the constrained distance in the cursor direction and finishes the command. Typing + click gets you the click location, no distance constraint.
In addition, typing + Enter, if the cursor is on a SmartTrack line, finishes the command with a line of the constrained length, no click or second Enter needed.

Does that make sense?

-Pascal

-Pascal

Hello Pascal

typing, + enter gets you the constrained distance, and you can click anyplace you like to end the command<

Yes, BUT you don’t get the constrained result.
You get a line of random length depending on where the cursor is.

That’s the problem - ie you can OVERRIDE the constraint you’ve just setup.
This was not possible previously, and I don’t think it should be possible now.

Cheers
rabbit

And, the constraint is being set with an Enter? Just making sure because, if you just type numbers and do nothing else, it looks like there is a constraint, on screen, but a click will override. If you type numbers and Enter then it should be locked in, and a click will only set the direction… ?

-Pascal

No, the constraint is set without an enter, BECAUSE that’s how it works in V5, V6.
ie you don’t need an enter after inputting the numbers…
You can optionally do that, to get the tracking line, but it’s not necessary.

if you just type numbers and do nothing else, it looks like there is a constraint, on screen, but a click will override.<

And that’s the problem exactly, because previously in V5, V6 a click doesn’t override the constraint.

Yes, sorry, what you describe is the bug that is now, here, in our latest, fixed…

-Pascal

Ok, perfect.
Thankyou.

Hi Pascal - Just checking - here in V8 2021-02-16 this problem is fixed, but in V7 of the same date, it’s still happening…?

Thanks
Rabbit

Will the fix be in the next V7 SRC? It is not in Version 7 (7.4.21047.11001, 2021-02-16).

Hi David -

FWIW, this is the YT item - RH-62774
-wim