This node doesn't have any equivalent in KiCad so for now we ignore it. In future, we could parse it in detail, to obtain the tree-structure of symbols/footprints in a cadstar library
1) More REPORTER, less exception processing
2) Remove UI calls from SPICE_MODEL
3) Don't replace netlist with errors; show both
4) Don't bail out of netlist generation after single error
Fixes https://gitlab.com/kicad/code/kicad/issues/14295
The list of candidates (names) must be restricted to existing global labels
and symbols creating a global net name: power symbols having only one power
input pin (a power output does not create net name).
Fixes#14319https://gitlab.com/kicad/code/kicad/issues/14319
In symbol editor, symbols are always shown not mirrored, not rotated.
So if the loaded symbol from schematic was rotated/mirrored, the position
of fields must be recalculated for the rotation 0, no mirror.
Also makes the strings match the GUI better so people will know where
to find them later.
And fixes a couple of ERC items that referred to Board Setup (oops).
When drawing the ratsnest, we need to be careful to avoid accessing
CONN_ITEMs that have been changed by the underlying model. Checking for
dirty items instead of valid items will prevent us looking at data that
are out of date
Fixes https://gitlab.com/kicad/code/kicad/issues/14265
The ViewBBox can include the largest document clearance so that pad
clearance lines get included. But the largest clearance can be, well,
large.
Fixes https://gitlab.com/kicad/code/kicad/issues/14276
Don't assume the dialog is mode-less and call Destroy() from within a
dialog method. This will most assuredly crash if the dialog is shown
modally or quasi-modally.
Don't leak memory for mode-less dialogs created on the stack. Make sure
when the parent frame window is closed that all mode-less dialog memory
is cleaned up. Dialogs are not child windows like controls and toolbars
so their memory does not automatically get cleaned up when the parent
window is destroyed.
Do not directly access frame parent window's pointer in dialog destructors.
Apparently the tear down order when destroying mode-less dialogs is not
guaranteed so the parent window may get deleted before the dialog causing
a crash when accessing the parent window pointer from the dialog dtor.
Do not close mode-less dialogs in the parent frame's destructor. This
doesn't guarantee that the dialog(s) will be destroyed before the parent
but it may reduce some careless mode-less dialog event handling in the
future.
Jeff Young
Roberto Fernandez Bautista
Wayne Stambaugh
jean-pierre charras
Alex
Seth Hillbrand