I was thinking of handling this bug, so I assigned it to me in Mantis. Thanks for starting to fix the issue (it was driving me crazy last week)
I am not handling it any more so not to interfere.
I have found no general issues regarding the code. Some considerations:
Aside from the bug. I have been asking myself partly the same question DeepSOIC does for a while.
If we fully disregard the sign, the problem then is that when you set it to be a length of a line (not the position of a point with respect to the other), you will see the negative sign. This, I think, makes little sense for a length (Distance). I never realised that the radius could actually be negative in any calculation in the sketcher (can it really be?). Anyway, in those cases, IMO, the solution below is the only one that makes sense. Of course, we should take care that whatever we calculate is not negative. If a radius or a distance is calculated or otherwise entered as negative, a warning/error may be shown.
However, DistanceX and DistanceY, may not be considered "lengths", but "distances" with respect to a reference. Not only in the cases considered below (reference is an axis of the sketch), but also on the others (when the reference is applied on a line instead of on its two points OR when the reference is not an axis of the sketch).
Code: Select all
double Constraint::getPresentationValue() const
{
switch (Type) {
case Distance:
case Radius:
return std::abs(Value);
case DistanceX:
case DistanceY:
if (FirstPos == Sketcher::none || Second != Sketcher::Constraint::GeoUndef)
return std::abs(Value);
else
return Value;
case Angle:
case SnellsLaw:
return Value;
default:
return Value;
}
}
It may be possible that this "obscuring" of the sign in these cases will be confusing for the user, when working with the spreedsheet and references between sketches... But it may also be that showing the sign confuses the user... anybody has an opinion on this?
English translation: When using horizontal or vertical distance constraints (not distance constraint), anybody sees a problem if instead of showing the value in absolute value, the value shown on the screen is signed (e.g. -30 mm), meaning that the point to the right (in horizontal distance constraint) is the one taken as reference for then definition of the "distance"? Anybody thinks that there is an advantage for the user if the sign is shown?
cox wrote:I am also experiencing the same when positive numbers are returned from expression, when driving constraint in second quadrant.
This could be the same problem you are experiencing.
To reproduce:
Open test1.fcstd
Assign Sketch.Constraint9 = Spreadsheet.Va
Observation:
Point in quadrant 2 jumps to quadrant 1
Additional info: In master it does not change quadrant.
FreeCAD