- In fp editor, fields cannot be duplicated: each is unique.
duplicating fields created a crash and issues in undo/redo command
- In board editor after creating an array with footprints.
- crash when closing pcbnew
- error when undoing the array creation
The crash was due to call run this_item->RunOnDescendants() on footprints: it
must be run only on a PCB_GROUP.
Attempting to create an array of footprint child objects other than a pad
causes the crash due to the fact that only pads where checked. The change
now checks if any object has a footprint as a parent. This should prevent
any future issues when new footprint child objects are added.
There was also another subtle bug fixed when more than one child object of
a footprint were selected, the array feature would make as many copies of
the footprint as selected child items.
https://gitlab.com/kicad/code/kicad/-/issues/16088
(It's still leaking into BOARD_COMMIT and some other places, but at
least it no longer leaks into all the edit tools.)
Also fixes some bugs when moving/copying/pasting multiple selections
containing length-tuning patterns.
Using a boolean argument just leads to a lot of trailing booleans in the
function calls and is not user friendly. Instead, introduce PostAction()
to send an action that runs after the coroutine (equivalent to passing
false or the default argument), and leave RunAction as the immediate
execution function.
ADDED: Option to assign unique reference designators to footprints
created with the array tool [pcbnew]
CHANGED: Array creator dialog no longer displays pad numbering properties
when in the board editor. [pcbnew]
Fixes https://gitlab.com/kicad/code/kicad/-/issues/2354
The unique_ptr was useful when the original function took multiple paths
which could de-scope the pointer. Current use allowed potential
use-after-free. This is now re-written to pass pointer directly.
The module refdes always increment by one. This is problematic
for two reasons:
* It doesn't work when more than one FP is selected (say you have
C1 and C2, you get C1, C2, C2, C3)
* It messes with simple panellisations
The 5.0.x behaviour is to not renumber in Pcbnew, so revert to
that behaviour.
Better refdes incrementation can come post 5.1, as this will need
new strings and UI.
Fixes: lp:1819106
* https://bugs.launchpad.net/kicad/+bug/1819106
The original item is part of the array, so give it a number
and put it in the right place (all current array tools have
a null transform for the first item, but it's not part of the
contract. For example, a circular array with an angle offset
might want to move the first point).
The current module cannot be queried for existing pads as we
add them (because we never commit, until we finish the whole array).
Instead, pre-gather the names and check as we add, skipping any existing
names.
Note: this will not prevent arrays becoming "mis-ordered", but there
is not a lot we can do to prevent all possible errors.
Fixes: 1808706
* https://bugs.launchpad.net/kicad/+bug/1808706
The same principle could be used to skip existing ref-des'es on PCBs.
The geometry and numbering logic is separate to the dialog, and
can be separated for clearer logic and better testability.
Moreover, refactor it to avoid any dependency on pcbnew
classes, so it can be move to common for potential re-use in
eeschema and friends in future.
Also convert all wxPoint logic in these classes to VECTOR2I and
fix some function visibilities.
Add some unit tests of the ARRAY_OPTIONS geometry and numbering.
Devolve the logic as to whether a pad should be numbered or not
to a pad utility function. Add a very simplistic test for this
function (demonstrating how to test BOARD_ITEMs in general).
Fixes: lp:1804787
* https://bugs.launchpad.net/kicad/+bug/1804787
Jeff Young
jean-pierre charras
Wayne Stambaugh
Alex Shvartzkop
Ian McInerney
Mike Williams
Roberto Fernandez Bautista
Mikolaj Wielgus
Seth Hillbrand
Jon Evans
John Beard