I’ll use the example from my last post again.
A line is fixed at point A, the direction is fixed horizontally. The point B is free in x- direction. In a midpoint calculation, the point B slips. This is hardly visible. For technical applications it is wrong.
By the way: This construction is for a 3D print for kids. The accuracy is not important here.

I have another example. This is more difficult. In the first example, the user may still be able to visualize the malfunction. Here I have a knee joint with fixed endpoints. If in one leg the center point is constructed the whole geometry changes. This is bad. Can you change this?

If I understand correctly your issue is that when you add a constraint the sketch changes. The thing is, that you are missing a concept, when adding contraints, salome will try to solve with the actual constraint and then get a solution for. As your sketch is not completely constraint, when you add a constraint it will re solve the sketch, while it is true that it would be a better behavior to not modify what is not necessary to modify, it is not an error you should simply constraint your sketch and then you will not get modifications when adding the extra things.
Best regards

Hello franco.ota
I did not understand your answer correctly. I think when the centre of a line is calculated, no new constraint is introduced.
My simple idea: The centre of a line is a PROPERTY of the line. Then the calculation/construction of the centre point can be omitted.
I realise that such a change in SALOME destroys compatibility with old versions.

I am not in the pc right now but if I read correctly from your figure it is actually adding a point in the center of the line and giving to that point the contraint of being in the middle.

that is correct. The mistake is that when the point “constrain” comes in the middle of the line, the length of the line changes. This must not be!

Alternative suggestion: Basically add the midpoint to the already existing endpoints to the line properties. This saves the midpoint construction in the current form with the above error possibilities.

As franco explained, when you add a constrain the sketch use a solver to find a solution that respects all the existing constrains. So since the other end line is not fixed, nor the length, it is allowed to move this point to find a solution. I agree it is not intuitive, but apparently it is the first answer found by the solver.
If the length needs to be fixed then you can add a length constrain and it will be respected when you add the middle point constrain.

You’re right. The user must know this situation! Unprepared, he falls into a trap.
There is still one exception to your suggestion: If the line is completely without constrains, Salome locks the construction of a midpoint. See my post “Tunnel”, a 3D print for kids.

The “correct” solution for what you want is that before looking for a new solution when a constraint is added it is that Salome looks at the solution before the additional constraint and looks if that one still fills up the solution, it is feasible, at least to a certain point but not waterproof. You should use “good practices” of CAD modeling so you don’t have this kind of issues, as Fred mentioned, you should fix the rest of your sketch and then add the extra point with the middle constraint. In any case this is not an error to solve in Salome, it could clearly be an improvement.
Best regards

Hello
I would like to help with the software development and not criticize!
Suppose at the beginning of a construction there is an oblique line. Its center is needed. According to the current discussion, there are two correct solutions:

fixing x- distance and y- distance to the origin and fixing the line length and an angle (see picture FixedDetails.jpg).

much easier, the line gets contraint “fixed”

The same task for a horizontal line does not work with constraint “fixed”. SALOME locks (see picture horizontal.jpg).

A uniform solution from the developers would be desirable.

I appreciate Salome and would like to continue using it.