[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
gEDA-cvs: pcb.git: branch: master updated (a537b78f5edc8c8c106ee146987797ef99ceb60a)
The branch, master has been updated
via a537b78f5edc8c8c106ee146987797ef99ceb60a (commit)
via 9a8e559401db73ea3c9f9ecddb9f50a179a91bb2 (commit)
via d0a3105c8dfe80d6a03d358ae850a9587236a23f (commit)
via a7d774b4e0fc7c2aa86a12819c169bc1392b20de (commit)
via 7705118c47da4941c55d644e20b937e981168e7b (commit)
via d63f3f35cb2d0f6d0bef71ecb4bf17208ed76ad7 (commit)
from c8e0f875155405bdcdb6835e8439a2c2fd4fb4a0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
=========
Summary
=========
src/find.c | 2 -
src/report.c | 97 +++++++++++++++++++++---------
src/undo.c | 188 +++++++++++++++++++++++++++++++++-------------------------
3 files changed, 177 insertions(+), 110 deletions(-)
=================
Commit Messages
=================
commit a537b78f5edc8c8c106ee146987797ef99ceb60a
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
report.c: Don't leave actions in the undo stack or change the user's flags
Some actions in ReportNetLength*() would have been lumped in with
whatever actions were next added to the undo stack. These functions
also left the user's board with a different "FOUND" flags on various
items.
In the case of the "Report(AllNetLenths)" action, a very long undo stack
would be created, which is not very helpful to the user.
These changes hide the internal flag changes made during the net length
calculation from the undo system.
We are able to get back to the inital board state because we save the
operations caused by our initial RestConnections() on the undo stack.
After we have done our work (modifying various flags in the process),
we reset the flags again (this time bypassing the Undo system), so the
board is consistent with the ResetConnections() call we DID save undo
data for. We then Undo() these changes before we leave the function.
:100644 100644 cf3635b... d461bd2... M src/report.c
commit 9a8e559401db73ea3c9f9ecddb9f50a179a91bb2
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
report.c: Return 1 for all failure conditions in ReportNetLengthByName()
:100644 100644 4d5e27b... cf3635b... M src/report.c
commit d0a3105c8dfe80d6a03d358ae850a9587236a23f
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
undo.c: Add error message where RestoreUndoSerialNumber() will break things
If operations are addded to the undo stack between a call to
IncrementUndoSerialNumber() and a subsequent call for
RestoreUndoSerialNumber(), those added operations will be placed in the
undo stack with an inconsistent serial number.
The {Save,Restore}UndoSerialNumber() API is pretty fragile in this
regard, and we should avoid using it where possible.
An better alternative might be to implement a "LockUndoSerialNumber()"
call which temporarily disables IncrementUndoSerialNumber(), and a
"UnlockUndoSerialNumber()" call which re-enables its increment function.
Better yet - we could make these functions nestable, so we need not
worry whether some action uses this new feature internally when we are
also using it.
:100644 100644 7832600... 17bebb9... M src/undo.c
commit a7d774b4e0fc7c2aa86a12819c169bc1392b20de
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
undo.c: Handle undo failures in a more sane manner
Our current error-case handling can cause serial number inconsistency
when something goes wrong when performing an Undo operation. There are
also various logic flaws in our handling, as it only catches failures
where every sub-undo operation with that serial number fails.
Remove the confusing do-loop which decrements the serial number in the
failure case, and return some sensible error message instead.
This patch also removes the code which looked like it was intended to
loop over the undo stack until a serial number was found to operate on.
It is advantageous for code like the DRC to be able to add increment
the undo serial number, then safely perform an Undo - even if there were
no changes logged in the undo system during the previous serial number.
Closes-bug: lp-848509
:100644 100644 fe3a6c7... 7832600... M src/undo.c
commit 7705118c47da4941c55d644e20b937e981168e7b
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
undo.c: Allow undo of locked objects
Our internal actions can make changes to locked objects, then
use the undo mechanism to revert these changes. An example is
DRC, which changes flags on objects and uses the Undo system
to restore their original values.
Affects-bug: lp-848509
:100644 100644 576b9cb... fe3a6c7... M src/undo.c
commit d63f3f35cb2d0f6d0bef71ecb4bf17208ed76ad7
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
find.c: Remove stray RestoreUndoSerialNumber() calls
These will cause havoc with the undo system, as we don't actually
save a serial number to restore to.
Until a commit efd212c1deb264e9a7f2be17e9338fbb60e22cc0 we were
saving a serial number at the start of each "ResetConnections (true);"
call, and it would have been that serial number which got restored.
With this and some other fixes to the undo system, these restores
are no longer required.
Affects-bug: lp-848509
:100644 100644 6edd29d... 877deb4... M src/find.c
=========
Changes
=========
commit a537b78f5edc8c8c106ee146987797ef99ceb60a
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
report.c: Don't leave actions in the undo stack or change the user's flags
Some actions in ReportNetLength*() would have been lumped in with
whatever actions were next added to the undo stack. These functions
also left the user's board with a different "FOUND" flags on various
items.
In the case of the "Report(AllNetLenths)" action, a very long undo stack
would be created, which is not very helpful to the user.
These changes hide the internal flag changes made during the net length
calculation from the undo system.
We are able to get back to the inital board state because we save the
operations caused by our initial RestConnections() on the undo stack.
After we have done our work (modifying various flags in the process),
we reset the flags again (this time bypassing the Undo system), so the
board is consistent with the ResetConnections() call we DID save undo
data for. We then Undo() these changes before we leave the function.
diff --git a/src/report.c b/src/report.c
index cf3635b..d461bd2 100644
--- a/src/report.c
+++ b/src/report.c
@@ -545,6 +545,10 @@ ReportFoundPins (int argc, char **argv, Coord x, Coord y)
return 0;
}
+/* Assumes that we start with a blank connection state,
+ * e.g. ResetConnections() has been run.
+ * Does not add its own changes to the undo system
+ */
static double
XYtoNetLength (Coord x, Coord y, int *found)
{
@@ -552,7 +556,11 @@ XYtoNetLength (Coord x, Coord y, int *found)
length = 0;
*found = 0;
- LookupConnection (x, y, true, PCB->Grid, FOUNDFLAG);
+
+ /* NB: The third argument here, 'false' ensures LookupConnection
+ * does not add its changes to the undo system.
+ */
+ LookupConnection (x, y, false, PCB->Grid, FOUNDFLAG);
ALLLINE_LOOP (PCB->Data);
{
@@ -591,6 +599,17 @@ ReportAllNetLengths (int argc, char **argv, Coord x, Coord y)
int ni;
int found;
+ /* Reset all connection flags and save an undo-state to get back
+ * to the state the board was in when we started this function.
+ *
+ * After this, we don't add any changes to the undo system, but
+ * ensure we get back to a point where we can Undo() our changes
+ * by resetting the connections with ResetConnections() before
+ * calling Undo() at the end of the procedure.
+ */
+ ResetConnections (true);
+ IncrementUndoSerialNumber ();
+
for (ni = 0; ni < PCB->NetlistLib.MenuN; ni++)
{
char *netname = PCB->NetlistLib.Menu[ni].Name + 2;
@@ -647,17 +666,18 @@ ReportAllNetLengths (int argc, char **argv, Coord x, Coord y)
if (argc < 1)
units_name = Settings.grid_unit->suffix;
- if (ResetConnections (true))
- Draw ();
- /* NB: XYtoNetLength calls LookupConnection, which performs an undo
- * serial number update, so we don't need to add one here.
- */
length = XYtoNetLength (x, y, &found);
+ /* Reset connectors for the next lookup */
+ ResetConnections (false);
+
pcb_sprintf(buf, "%$m*", units_name, length);
gui->log("Net %s length %s\n", netname, buf);
}
}
+
+ ResetConnections (false);
+ Undo (true);
return 0;
}
@@ -668,17 +688,25 @@ ReportNetLength (int argc, char **argv, Coord x, Coord y)
char *netname = 0;
int found = 0;
- if (ResetConnections (true))
- Draw ();
- /* NB: XYtoNetLength calls LookupConnection, which performs an undo
- * serial number update, so we don't need to add one here.
- */
gui->get_coords ("Click on a connection", &x, &y);
+ /* Reset all connection flags and save an undo-state to get back
+ * to the state the board was in when we started this function.
+ *
+ * After this, we don't add any changes to the undo system, but
+ * ensure we get back to a point where we can Undo() our changes
+ * by resetting the connections with ResetConnections() before
+ * calling Undo() at the end of the procedure.
+ */
+ ResetConnections (true);
+ IncrementUndoSerialNumber ();
+
length = XYtoNetLength (x, y, &found);
if (!found)
{
+ ResetConnections (false);
+ Undo (true);
gui->log ("No net under cursor.\n");
return 1;
}
@@ -737,7 +765,10 @@ ReportNetLength (int argc, char **argv, Coord x, Coord y)
END_LOOP;
}
END_LOOP;
- got_net_name:
+
+got_net_name:
+ ResetConnections (false);
+ Undo (true);
{
char buf[50];
@@ -747,6 +778,7 @@ ReportNetLength (int argc, char **argv, Coord x, Coord y)
else
gui->log ("Net length: %s\n", buf);
}
+
return 0;
}
@@ -778,12 +810,6 @@ ReportNetLengthByName (char *tofind, int x, int y)
if (!tofind)
return 1;
- SaveUndoSerialNumber ();
- ResetFoundPinsViasAndPads (true);
- RestoreUndoSerialNumber ();
- ResetFoundLinesAndPolygons (true);
- RestoreUndoSerialNumber ();
-
#if defined(USE_RE)
use_re = 1;
for (i = 0; i < PCB->NetlistLib.MenuN; i++)
@@ -864,24 +890,38 @@ ReportNetLengthByName (char *tofind, int x, int y)
gui->log ("No net named %s\n", tofind);
return 1;
}
+
#ifdef HAVE_REGCOMP
if (use_re)
regfree (&elt_pattern);
#endif
+ /* Reset all connection flags and save an undo-state to get back
+ * to the state the board was in when we started.
+ *
+ * After this, we don't add any changes to the undo system, but
+ * ensure we get back to a point where we can Undo() our changes
+ * by resetting the connections with ResetConnections() before
+ * calling Undo() when we are finished.
+ */
+ ResetConnections (true);
+ IncrementUndoSerialNumber ();
+
length = XYtoNetLength (x, y, &found);
netname = net->Name + 2;
- if (!found && net_found)
- {
- gui->log ("Net found, but no lines or arcs were flagged.\n");
- return 1;
- }
- else if (!found)
- {
- gui->log ("Net not found.\n");
+ ResetConnections (false);
+ Undo (true);
+
+ if (!found)
+ {
+ if (net_found)
+ gui->log ("Net found, but no lines or arcs were flagged.\n");
+ else
+ gui->log ("Net not found.\n");
+
return 1;
- }
+ }
{
char buf[50];
@@ -891,6 +931,7 @@ ReportNetLengthByName (char *tofind, int x, int y)
else
gui->log ("Net length: %s\n", buf);
}
+
return 0;
}
commit 9a8e559401db73ea3c9f9ecddb9f50a179a91bb2
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
report.c: Return 1 for all failure conditions in ReportNetLengthByName()
diff --git a/src/report.c b/src/report.c
index 4d5e27b..cf3635b 100644
--- a/src/report.c
+++ b/src/report.c
@@ -812,7 +812,7 @@ ReportNetLengthByName (char *tofind, int x, int y)
if ((elt_pattern = re_comp (tofind)) != NULL)
{
Message (_("re_comp error: %s\n"), elt_pattern);
- return (false);
+ return (1);
}
#endif
}
commit d0a3105c8dfe80d6a03d358ae850a9587236a23f
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
undo.c: Add error message where RestoreUndoSerialNumber() will break things
If operations are addded to the undo stack between a call to
IncrementUndoSerialNumber() and a subsequent call for
RestoreUndoSerialNumber(), those added operations will be placed in the
undo stack with an inconsistent serial number.
The {Save,Restore}UndoSerialNumber() API is pretty fragile in this
regard, and we should avoid using it where possible.
An better alternative might be to implement a "LockUndoSerialNumber()"
call which temporarily disables IncrementUndoSerialNumber(), and a
"UnlockUndoSerialNumber()" call which re-enables its increment function.
Better yet - we could make these functions nestable, so we need not
worry whether some action uses this new feature internally when we are
also using it.
diff --git a/src/undo.c b/src/undo.c
index 7832600..17bebb9 100644
--- a/src/undo.c
+++ b/src/undo.c
@@ -76,6 +76,9 @@
RCSID ("$Id$");
+static bool between_increment_and_restore = false;
+static bool added_undo_between_increment_and_restore = false;
+
/* ---------------------------------------------------------------------------
* some local data types
*/
@@ -254,6 +257,9 @@ GetUndoSlot (int CommandType, int ID, int Kind)
break;
}
+ if (between_increment_and_restore)
+ added_undo_between_increment_and_restore = true;
+
/* copy typefield and serial number to the list */
ptr = &UndoList[UndoN++];
ptr->Type = CommandType;
@@ -1177,6 +1183,10 @@ Redo (bool draw)
void
RestoreUndoSerialNumber (void)
{
+ if (added_undo_between_increment_and_restore)
+ Message (_("ERROR: Operations were added to the Undo stack with an incorrect serial number\n"));
+ between_increment_and_restore = false;
+ added_undo_between_increment_and_restore = false;
Serial = SavedSerial;
}
@@ -1187,6 +1197,8 @@ void
SaveUndoSerialNumber (void)
{
Bumped = false;
+ between_increment_and_restore = false;
+ added_undo_between_increment_and_restore = false;
SavedSerial = Serial;
}
@@ -1205,6 +1217,7 @@ IncrementUndoSerialNumber (void)
SetChangedFlag (true);
Serial++;
Bumped = true;
+ between_increment_and_restore = true;
}
}
commit a7d774b4e0fc7c2aa86a12819c169bc1392b20de
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
undo.c: Handle undo failures in a more sane manner
Our current error-case handling can cause serial number inconsistency
when something goes wrong when performing an Undo operation. There are
also various logic flaws in our handling, as it only catches failures
where every sub-undo operation with that serial number fails.
Remove the confusing do-loop which decrements the serial number in the
failure case, and return some sensible error message instead.
This patch also removes the code which looked like it was intended to
loop over the undo stack until a serial number was found to operate on.
It is advantageous for code like the DRC to be able to add increment
the undo serial number, then safely perform an Undo - even if there were
no changes logged in the undo system during the previous serial number.
Closes-bug: lp-848509
diff --git a/src/undo.c b/src/undo.c
index fe3a6c7..7832600 100644
--- a/src/undo.c
+++ b/src/undo.c
@@ -932,50 +932,71 @@ Undo (bool draw)
UndoListTypePtr ptr;
int Types = 0;
int unique;
+ bool error_undoing = false;
unique = TEST_FLAG (UNIQUENAMEFLAG, PCB);
CLEAR_FLAG (UNIQUENAMEFLAG, PCB);
andDraw = draw;
- do
+ if (Serial == 0)
{
- if (!UndoN)
- {
- if (!Serial)
- Message (_("Nothing to undo - buffer is empty\n"));
- else
- Serial--;
- return (false);
- }
+ Message (_("ERROR: Attempt to Undo() with Serial == 0\n"
+ " Please save your work and report this bug.\n"));
+ return 0;
+ }
+
+ if (UndoN == 0)
+ {
+ Message (_("Nothing to undo - buffer is empty\n"));
+ return 0;
+ }
+
+ Serial --;
+
+ ptr = &UndoList[UndoN - 1];
- /* lock undo module to prevent from loops
- * and loop over all entries with the same serial number
+ if (ptr->Serial > Serial)
+ {
+ Message (_("ERROR: Bad undo serial number %d in undo stack - expecting %d or lower\n"
+ " Please save your work and report this bug.\n"),
+ ptr->Serial, Serial);
+
+ /* It is likely that the serial number got corrupted through some bad
+ * use of the SaveUndoSerialNumber() / RestoreUndoSerialNumber() APIs.
+ *
+ * Reset the serial number to be consistent with that of the last
+ * operation on the undo stack in the hope that this might clear
+ * the problem and allow the user to hit Undo again.
*/
- ptr = &UndoList[UndoN - 1];
- if (ptr->Serial != Serial - 1)
- {
- Message (_("Undo bad serial number %d expecting %d\n"),
- ptr->Serial, Serial - 1);
- Serial = ptr->Serial + 1;
- return (false);
- }
- LockUndo ();
- Serial = ptr->Serial;
- for (; UndoN && ptr->Serial == Serial; ptr--, UndoN--, RedoN++)
- Types |= PerformUndo (ptr);
- /* release lock */
- UnlockUndo ();
+ Serial = ptr->Serial + 1;
+ return 0;
}
- while (Types == 0);
+
+ LockUndo (); /* lock undo module to prevent from loops */
+
+ /* Loop over all entries with the correct serial number */
+ for (; UndoN && ptr->Serial == Serial; ptr--, UndoN--, RedoN++)
+ {
+ int undid = PerformUndo (ptr);
+ if (undid == 0)
+ error_undoing = true;
+ Types |= undid;
+ }
+
+ UnlockUndo ();
+
+ if (error_undoing)
+ Message (_("ERROR: Failed to undo some operations\n"));
+
if (Types && andDraw)
Draw ();
/* restore the unique flag setting */
if (unique)
SET_FLAG (UNIQUENAMEFLAG, PCB);
-
- return (Types);
+
+ return Types;
}
static int
@@ -1096,34 +1117,58 @@ Redo (bool draw)
{
UndoListTypePtr ptr;
int Types = 0;
+ bool error_undoing = false;
andDraw = draw;
- do
+
+ if (RedoN == 0)
{
- if (!RedoN)
- {
- Message
- (_
- ("Nothing to redo. Perhaps changes have been made since last undo\n"));
- return (false);
- }
+ Message (_("Nothing to redo. Perhaps changes have been made since last undo\n"));
+ return 0;
+ }
+
+ ptr = &UndoList[UndoN];
- /* lock undo module to prevent from loops
- * and loop over all entries with the same serial number
+ if (ptr->Serial < Serial)
+ {
+ Message (_("ERROR: Bad undo serial number %d in redo stack - expecting %d or higher\n"
+ " Please save your work and report this bug.\n"),
+ ptr->Serial, Serial);
+
+ /* It is likely that the serial number got corrupted through some bad
+ * use of the SaveUndoSerialNumber() / RestoreUndoSerialNumber() APIs.
+ *
+ * Reset the serial number to be consistent with that of the first
+ * operation on the redo stack in the hope that this might clear
+ * the problem and allow the user to hit Redo again.
*/
- LockUndo ();
- ptr = &UndoList[UndoN];
Serial = ptr->Serial;
- for (; RedoN && ptr->Serial == Serial; ptr++, UndoN++, RedoN--)
- Types |= PerformUndo (ptr);
- /* Make next serial number current in case we take a new branch */
- Serial++;
- UnlockUndo ();
+ return 0;
}
- while (Types == 0);
+
+ LockUndo (); /* lock undo module to prevent from loops */
+
+ /* and loop over all entries with the correct serial number */
+ for (; RedoN && ptr->Serial == Serial; ptr++, UndoN++, RedoN--)
+ {
+ int undid = PerformUndo (ptr);
+ if (undid == 0)
+ error_undoing = true;
+ Types |= undid;
+ }
+
+ /* Make next serial number current */
+ Serial++;
+
+ UnlockUndo ();
+
+ if (error_undoing)
+ Message (_("ERROR: Failed to redo some operations\n"));
+
if (Types && andDraw)
Draw ();
- return (Types);
+
+ return Types;
}
/* ---------------------------------------------------------------------------
@@ -1155,12 +1200,11 @@ IncrementUndoSerialNumber (void)
{
if (!Locked)
{
- /* don't increment if nothing was added */
- if (UndoN == 0 || UndoList[UndoN - 1].Serial != Serial)
- return;
+ /* Set the changed flag if anything was added prior to this bump */
+ if (UndoN > 0 && UndoList[UndoN - 1].Serial == Serial)
+ SetChangedFlag (true);
Serial++;
Bumped = true;
- SetChangedFlag (true);
}
}
commit 7705118c47da4941c55d644e20b937e981168e7b
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
undo.c: Allow undo of locked objects
Our internal actions can make changes to locked objects, then
use the undo mechanism to revert these changes. An example is
DRC, which changes flags on objects and uses the Undo system
to restore their original values.
Affects-bug: lp-848509
diff --git a/src/undo.c b/src/undo.c
index 576b9cb..fe3a6c7 100644
--- a/src/undo.c
+++ b/src/undo.c
@@ -295,8 +295,6 @@ UndoRotate (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (ArcTypePtr) ptr2))
- return (false);
RotateObject (type, ptr1, ptr2, ptr3,
Entry->Data.Rotate.CenterX, Entry->Data.Rotate.CenterY,
(4 - Entry->Data.Rotate.Steps) & 0x03);
@@ -345,8 +343,6 @@ UndoChangeName (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (TextTypePtr) ptr3))
- return (false);
Entry->Data.ChangeName.Name =
(char *)(ChangeObjectName (type, ptr1, ptr2, ptr3,
Entry->Data.ChangeName.Name));
@@ -370,8 +366,6 @@ UndoChange2ndSize (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (PinTypePtr) ptr2))
- return (false);
swap = ((PinTypePtr) ptr2)->DrillingHole;
if (andDraw)
EraseObject (type, ptr1, ptr2);
@@ -400,8 +394,6 @@ UndoChangeAngles (UndoListTypePtr Entry)
{
LayerTypePtr Layer = (LayerTypePtr) ptr1;
ArcTypePtr a = (ArcTypePtr) ptr2;
- if (TEST_FLAG (LOCKFLAG, a))
- return (false);
r_delete_entry (Layer->arc_tree, (BoxTypePtr) a);
old_sa = a->StartAngle;
old_da = a->Delta;
@@ -434,8 +426,6 @@ UndoChangeClearSize (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (LineTypePtr) ptr2))
- return (false);
swap = ((PinTypePtr) ptr2)->Clearance;
RestoreToPolygon (PCB->Data, type, ptr1, ptr2);
if (andDraw)
@@ -465,8 +455,6 @@ UndoChangeMaskSize (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type & (VIA_TYPE | PIN_TYPE | PAD_TYPE))
{
- if (TEST_FLAG (LOCKFLAG, (PinTypePtr) ptr2))
- return (false);
swap =
(type ==
PAD_TYPE ? ((PadTypePtr) ptr2)->Mask : ((PinTypePtr) ptr2)->Mask);
@@ -500,8 +488,6 @@ UndoChangeSize (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (PinTypePtr) ptr2))
- return (false);
/* Wow! can any object be treated as a pin type for size change?? */
/* pins, vias, lines, and arcs can. Text can't but it has it's own mechanism */
swap = ((PinTypePtr) ptr2)->Thickness;
@@ -537,9 +523,6 @@ UndoFlag (UndoListTypePtr Entry)
FlagType f1, f2;
PinTypePtr pin = (PinTypePtr) ptr2;
- if (TEST_FLAG (LOCKFLAG, pin))
- return (false);
-
swap = pin->Flags;
must_redraw = 0;
@@ -583,8 +566,6 @@ UndoMirror (UndoListTypePtr Entry)
if (type == ELEMENT_TYPE)
{
ElementTypePtr element = (ElementTypePtr) ptr3;
- if (TEST_FLAG (LOCKFLAG, element))
- return (false);
if (andDraw)
EraseElement (element);
MirrorElementCoordinates (PCB->Data, element, Entry->Data.Move.DY);
@@ -611,8 +592,6 @@ UndoCopyOrCreate (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (PinTypePtr) ptr2))
- return (false);
if (!RemoveList)
RemoveList = CreateNewBuffer ();
if (andDraw)
@@ -640,8 +619,6 @@ UndoMove (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (LineTypePtr) ptr2))
- return (false);
MoveObject (type, ptr1, ptr2, ptr3,
-Entry->Data.Move.DX, -Entry->Data.Move.DY);
Entry->Data.Move.DX *= -1;
@@ -691,8 +668,6 @@ UndoMoveToLayer (UndoListTypePtr Entry)
SearchObjectByID (PCB->Data, &ptr1, &ptr2, &ptr3, Entry->ID, Entry->Kind);
if (type != NO_TYPE)
{
- if (TEST_FLAG (LOCKFLAG, (LineTypePtr) ptr2))
- return (false);
swap = GetLayerNumber (PCB->Data, (LayerTypePtr) ptr1);
MoveObjectToLayer (type, ptr1, ptr2, ptr3,
LAYER_PTR (Entry->Data.
@@ -724,8 +699,6 @@ UndoRemovePoint (UndoListTypePtr Entry)
{
case POLYGON_TYPE: /* restore the removed point */
{
- if (TEST_FLAG (LOCKFLAG, polygon))
- return (false);
/* recover the point */
if (andDraw && layer->On)
ErasePolygon (polygon);
@@ -774,8 +747,6 @@ UndoInsertPoint (UndoListTypePtr Entry)
{
case POLYGONPOINT_TYPE: /* removes an inserted polygon point */
{
- if (TEST_FLAG (LOCKFLAG, polygon))
- return (false);
if (andDraw && layer->On)
ErasePolygon (polygon);
commit d63f3f35cb2d0f6d0bef71ecb4bf17208ed76ad7
Author: Peter Clifton <pcjc2@xxxxxxxxx>
Commit: Peter Clifton <pcjc2@xxxxxxxxx>
find.c: Remove stray RestoreUndoSerialNumber() calls
These will cause havoc with the undo system, as we don't actually
save a serial number to restore to.
Until a commit efd212c1deb264e9a7f2be17e9338fbb60e22cc0 we were
saving a serial number at the start of each "ResetConnections (true);"
call, and it would have been that serial number which got restored.
With this and some other fixes to the undo system, these restores
are no longer required.
Affects-bug: lp-848509
diff --git a/src/find.c b/src/find.c
index 6edd29d..877deb4 100644
--- a/src/find.c
+++ b/src/find.c
@@ -3534,7 +3534,6 @@ DRCFind (int What, void *ptr1, void *ptr2, void *ptr3)
drc = false;
Bloat = -PCB->Shrink;
TheFlag = SELECTEDFLAG;
- RestoreUndoSerialNumber ();
ListStart (What, ptr1, ptr2, ptr3);
DoIt (true, true);
DumpList ();
@@ -3588,7 +3587,6 @@ DRCFind (int What, void *ptr1, void *ptr2, void *ptr3)
User = true;
drc = false;
Bloat = 0;
- RestoreUndoSerialNumber ();
TheFlag = SELECTEDFLAG;
ListStart (What, ptr1, ptr2, ptr3);
DoIt (true, true);
_______________________________________________
geda-cvs mailing list
geda-cvs@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-cvs