[Bf-blender-cvs] [3b75d6c] master: Fix T39880: Cancelling transforms in Graph Editor does not restore F-Curves to original state

[Joshua Leung]

Commit: 3b75d6c4f9a60258b40ead78533dfd219cfc85ce
Author: Joshua Leung
Date:   Fri Apr 25 13:32:27 2014 +1200
https://developer.blender.org/rB3b75d6c4f9a60258b40ead78533dfd219cfc85ce

Fix T39880: Cancelling transforms in Graph Editor does not restore F-Curves to original state

Since autosnap was being applied during the flushing step for various practical reasons,
it wasn't possible to restore keyframes and handles to their original values, as these
would always get overwritten before getting a chance to be written back to the keyframes.

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

M	source/blender/editors/transform/transform_conversions.c
M	source/blender/editors/transform/transform_generics.c

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

diff --git a/source/blender/editors/transform/transform_conversions.c b/source/blender/editors/transform/transform_conversions.c
index 8830b02..2ac92ce 100644
--- a/source/blender/editors/transform/transform_conversions.c
+++ b/source/blender/editors/transform/transform_conversions.c
@@ -4107,8 +4107,9 @@ void flushTransGraphData(TransInfo *t)
 		/* handle snapping for time values
 		 *	- we should still be in NLA-mapping timespace
 		 *	- only apply to keyframes (but never to handles)
+		 *  - don't do this when cancelling, or else these changes won't go away
 		 */
-		if ((td->flag & TD_NOTIMESNAP) == 0) {
+		if ((t->state != TRANS_CANCEL) && (td->flag & TD_NOTIMESNAP) == 0) {
 			switch (sipo->autosnap) {
 				case SACTSNAP_FRAME: /* snap to nearest frame */
 					td2d->loc[0] = floor((double)td2d->loc[0] + 0.5);
@@ -4136,8 +4137,11 @@ void flushTransGraphData(TransInfo *t)
 		 *
 		 * NOTE: We also have to apply to td->loc, as that's what the handle-adjustment step below looks
 		 *       to, otherwise we get "swimming handles"
+		 * NOTE: We don't do this when cancelling transforms, or else these changes don't go away
 		 */
-		if ((td->flag & TD_NOTIMESNAP) == 0 && ELEM(sipo->autosnap, SACTSNAP_STEP, SACTSNAP_TSTEP)) {
+		if ((t->state != TRANS_CANCEL) && (td->flag & TD_NOTIMESNAP) == 0 && 
+		    ELEM(sipo->autosnap, SACTSNAP_STEP, SACTSNAP_TSTEP)) 
+		{
 			switch (sipo->autosnap) {
 				case SACTSNAP_STEP: /* frame step */
 					td2d->loc2d[0] = floor((double)td2d->loc[0] + 0.5);
diff --git a/source/blender/editors/transform/transform_generics.c b/source/blender/editors/transform/transform_generics.c
index ccb7e13..ee8a851 100644
--- a/source/blender/editors/transform/transform_generics.c
+++ b/source/blender/editors/transform/transform_generics.c
@@ -529,41 +529,45 @@ static void recalcData_nla(TransInfo *t)
 				break;
 		}
 		
-		/* handle auto-snapping */
-		switch (snla->autosnap) {
-			case SACTSNAP_FRAME: /* snap to nearest frame */
-			case SACTSNAP_STEP: /* frame step - this is basically the same, since we don't have any remapping going on */
-			{
-				tdn->h1[0] = floorf(tdn->h1[0] + 0.5f);
-				tdn->h2[0] = floorf(tdn->h2[0] + 0.5f);
-				break;
-			}
-			
-			case SACTSNAP_SECOND: /* snap to nearest second */
-			case SACTSNAP_TSTEP: /* second step - this is basically the same, since we don't have any remapping going on */
-			{
-				/* This case behaves differently from the rest, since lengths of strips
-				 * may not be multiples of a second. If we just naively resize adjust
-				 * the handles, things may not work correctly. Instead, we only snap
-				 * the first handle, and move the other to fit.
-				 *
-				 * FIXME: we do run into problems here when user attempts to negatively
-				 *        scale the strip, as it then just compresses down and refuses
-				 *        to expand out the other end.
-				 */
-				float h1_new = (float)(floor(((double)tdn->h1[0] / secf) + 0.5) * secf);
-				float delta  = h1_new - tdn->h1[0];
+		/* handle auto-snapping
+		 * NOTE: only do this when transform is still running, or we can't restore
+		 */
+		if (t->state != TRANS_CANCEL) {
+			switch (snla->autosnap) {
+				case SACTSNAP_FRAME: /* snap to nearest frame */
+				case SACTSNAP_STEP: /* frame step - this is basically the same, since we don't have any remapping going on */
+				{
+					tdn->h1[0] = floorf(tdn->h1[0] + 0.5f);
+					tdn->h2[0] = floorf(tdn->h2[0] + 0.5f);
+					break;
+				}
 				
-				tdn->h1[0] = h1_new;
-				tdn->h2[0] += delta;
-				break;
-			}
-			
-			case SACTSNAP_MARKER: /* snap to nearest marker */
-			{
-				tdn->h1[0] = (float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h1[0]);
-				tdn->h2[0] = (float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h2[0]);
-				break;
+				case SACTSNAP_SECOND: /* snap to nearest second */
+				case SACTSNAP_TSTEP: /* second step - this is basically the same, since we don't have any remapping going on */
+				{
+					/* This case behaves differently from the rest, since lengths of strips
+					 * may not be multiples of a second. If we just naively resize adjust
+					 * the handles, things may not work correctly. Instead, we only snap
+					 * the first handle, and move the other to fit.
+					 *
+					 * FIXME: we do run into problems here when user attempts to negatively
+					 *        scale the strip, as it then just compresses down and refuses
+					 *        to expand out the other end.
+					 */
+					float h1_new = (float)(floor(((double)tdn->h1[0] / secf) + 0.5) * secf);
+					float delta  = h1_new - tdn->h1[0];
+					
+					tdn->h1[0] = h1_new;
+					tdn->h2[0] += delta;
+					break;
+				}
+				
+				case SACTSNAP_MARKER: /* snap to nearest marker */
+				{
+					tdn->h1[0] = (float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h1[0]);
+					tdn->h2[0] = (float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h2[0]);
+					break;
+				}
 			}
 		}