From e1dd86f0a9e8ca358c836043382c00271a645423 Mon Sep 17 00:00:00 2001
From: Abdullah Tahiri <abdullah.tahiri.yo@gmail.com>
Date: Wed, 7 Oct 2015 14:33:54 +0200
Subject: [PATCH] Sketcher: Bug fix: unable to move geometry after addition of
 a constraint

=========================================================================

This fixes issue:
http://www.freecadweb.org/tracker/view.php?id=2281

Discussed in:
http://forum.freecadweb.org/viewtopic.php?p=101910#p101910

How to reproduce?
With Auto-Update mode unchecked, execute the sequence in the bug tracker. You will reach to a geometry assembly successfully solved that can not be moved.

Why?
The coincident constraint is partially redundant within the meaning of redundancy of the solver.
The solve within "addconstraint" in SketchObjectPy.cpp causes the geometry to move to meet the coincident constraint.
At the end of the solve, the initial solution used in diagnostics is no longer valid (the geometry moved). This causes a subsequente move not to be executed.

The Solution:
Recalculate just the initial solution after the addition.
---
 src/Mod/Sketcher/App/SketchObject.cpp      | 6 ++++++
 src/Mod/Sketcher/App/SketchObject.h        | 5 +++++
 src/Mod/Sketcher/App/SketchObjectPyImp.cpp | 7 ++++++-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/Mod/Sketcher/App/SketchObject.cpp b/src/Mod/Sketcher/App/SketchObject.cpp
index 472c1241a..d0ac076fc 100644
--- a/src/Mod/Sketcher/App/SketchObject.cpp
+++ b/src/Mod/Sketcher/App/SketchObject.cpp
@@ -372,6 +372,12 @@ int SketchObject::toggleDriving(int ConstrId)
     return 0;
 }
 
+int SketchObject::setUpSketch()
+{
+    return solvedSketch.setUpSketch(getCompleteGeometry(), Constraints.getValues(),
+                             getExternalGeometryCount());
+}
+
 int SketchObject::movePoint(int GeoId, PointPos PosId, const Base::Vector3d& toPoint, bool relative, bool updateGeoBeforeMoving)
 {
     // if we are moving a point at SketchObject level, we need to start from a solved sketch
diff --git a/src/Mod/Sketcher/App/SketchObject.h b/src/Mod/Sketcher/App/SketchObject.h
index e4be0eeb5..7efcfa3cf 100644
--- a/src/Mod/Sketcher/App/SketchObject.h
+++ b/src/Mod/Sketcher/App/SketchObject.h
@@ -122,6 +122,11 @@ public:
 
     /// returns non zero if the sketch contains conflicting constraints
     int hasConflicts(void) const;
+    /** 
+     * sets the geometry of sketchObject as the solvedsketch geometry
+     * returns the DoF of such a geometry.
+     */
+    int setUpSketch();
 
     /** solves the sketch and updates the geometry, but not all the dependent features (does not recompute)
         When a recompute is necessary, recompute triggers execute() which solves the sketch and updates all dependent features
diff --git a/src/Mod/Sketcher/App/SketchObjectPyImp.cpp b/src/Mod/Sketcher/App/SketchObjectPyImp.cpp
index 90fbdb1cf..a480c27b7 100644
--- a/src/Mod/Sketcher/App/SketchObjectPyImp.cpp
+++ b/src/Mod/Sketcher/App/SketchObjectPyImp.cpp
@@ -264,7 +264,12 @@ PyObject* SketchObjectPy::addConstraint(PyObject *args)
         //
         // N.B.: However, the solve itself may be inhibited in cases where groups of geometry/constraints
         //      are added together, because in that case undoing will also make the geometry disappear.
-        this->getSketchObjectPtr()->solve(); 
+        this->getSketchObjectPtr()->solve();
+        // if the geometry moved during the solve, then the initial solution is invalid
+        // at this point, so a point movement may not work in cases where redundant constraints exist.
+        // this forces recalculation of the initial solution (not a full solve)
+        if(this->getSketchObjectPtr()->noRecomputes)
+            this->getSketchObjectPtr()->setUpSketch(); 
         return Py::new_reference_to(Py::Int(ret));
     }
     else if (PyObject_TypeCheck(pcObj, &(PyList_Type)) ||