refresh button in gtk interface to DRC loses edits

[Bdale Garbee]

Using pcb with the gtk interface, I see a fairly persistent behavior when running DRC in which hitting the refresh button in the DRC dialog window will cause any edits made since DRC started to be thrown away. It's as if the state of the board is being rolled back to where it was when DRC began. This happens with the Debian packaging of 20100929-2, and was still present in head of git yesterday.

[KaiMartin (kmk-familieknaak)]

Confirm. I also saw this, with recent projects, but never quite got a reliable way to trigger.

---<)kaimartin(>---

[Bdale Garbee (bdale)]

Attached is a version of one of my design files that has a pile of DRC bugs, from a point in history when this bug was biting me badly.

For example. run DRC on this board, then fix the first "potential for broken trace" issue, and hit refresh. The error may not show up in the list of DRC problems found again, but the displayed geometry will be reset to before the fix was made!

This design is under the TAPR Open Hardware License, by the way, and the current version is at git.gag.com in the hw/teleterra repository.

[gpleda.org commit robot (gpleda-launchpad-robot)]

Bug was fixed by a commit
git master commit a7d774b4e0fc7c2aa86a12819c169bc1392b20de
http://git.gpleda.org/?p=pcb.git;a=commit;h=a7d774b4e0fc7c2aa86a12819c169bc1392b20de

commit a7d774b4e0fc7c2aa86a12819c169bc1392b20de
Author: Peter Clifton <email address hidden>
Commit: Peter Clifton <email address hidden>

    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

[gpleda.org commit robot (gpleda-launchpad-robot)]

A commit was made which affects this bug
git master commit 7705118c47da4941c55d644e20b937e981168e7b
http://git.gpleda.org/?p=pcb.git;a=commit;h=7705118c47da4941c55d644e20b937e981168e7b

commit 7705118c47da4941c55d644e20b937e981168e7b
Author: Peter Clifton <email address hidden>
Commit: Peter Clifton <email address hidden>

    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

[gpleda.org commit robot (gpleda-launchpad-robot)]

A commit was made which affects this bug
git master commit d63f3f35cb2d0f6d0bef71ecb4bf17208ed76ad7
http://git.gpleda.org/?p=pcb.git;a=commit;h=d63f3f35cb2d0f6d0bef71ecb4bf17208ed76ad7

commit d63f3f35cb2d0f6d0bef71ecb4bf17208ed76ad7
Author: Peter Clifton <email address hidden>
Commit: Peter Clifton <email address hidden>

    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