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.
We really don't want to post these events unless the *selected* items
were actually modified, since it results in a redraw of the properties
panel (which disturbs edit state and causes flicker on MSW).
Now the COMMIT system is responsible for sending this event iff the
commit touches items that are selected.
Side note: UpdateMsgPanel is useless on every app except pl_editor, so
it can probably be refactored/removed at some point.
As of wxWidgets 3.2, the wxWidgets event handler runs code after the
the client event handler that depends on the menu still existing.
Because there are potentially many paths to call ReCreateMenuBar from
within a menu event handler, let's just wrap this action in a CallAfter
to make sure it happens after the wx handler call completes.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/13149
1) The highest priority zone that a via/pad collides with "owns" its
connectivity state. Once set, lower priority zones cannot change it --
and in fact, if they would have connected to it are forced not to.
2) The connectivity state goes with the zone fill state, and therefore
must be saved in the file.
3) Display of remove-unconnected's pads is no longer done in GetViewLOD()
(which isn't called for selected items), and is instead done in PCB_PAINTER.
This allows us to draw the full pad in outline mode when a via/pad is
selected which would otherwise only show the hole.
4) Note that in some cases this will still generate DRC errors -- in
particular when a via nearly collides with a higher priority zone it
won't get "owned" by that zone and may therefore have insufficient
clearance if said zone concludes it's unconnected and a subsequent
(lower priority) zone connects to it (causing it to now become flashed).
Fixes https://gitlab.com/kicad/code/kicad/issues/11299
The 3D mouse support is moved from PCB_EDIT_FRAME to PCB_BASE_FRAME.
This allows all PCB_BASE_FRAME derived windows to have 3D mouse enabled
2D navigation support.
The algo used to calculate a focus point on a zone can be *extremely* time
consuming when using the filled areas in zone (can be matter of minutes and more).
So we use now only the zone outlines usually having not a lot of vertices.
Jeff Young
Wayne Stambaugh
Marek Roszko
Jon Evans
markus-bonk
jean-pierre charras
Seth Hillbrand