The move tool can stack on others, so when we re-enter the previous tool
this caused another immediate action. We flag re-entry in the tool
stack to check for this and avoid unexpected tool starts
Can happen if someone hammers away on the probe and/or tune tools
without ever mousing over the schematic in between.
*May* fix the below bug.
Fixes https://gitlab.com/kicad/code/kicad/issues/6876
* Make the events generated by the selection of context menu items
have the position where the menu was opened
* Ensure that TC_COMMAND type events have their position set to
be the cursor position where the event originated
We were running into various corner conditions where a tool's event
loop would exit while the tool was still active, or the tool would
get popped while we were still in the event loop. (A lot of these
had to do with the POINT_EDITOR's, but not all of them.)
The new architecture:
1) tools always do a Push()/Pop()
2) everyone is responsible for their own pops; no more stack-clearing
on a cancel
3) CancelInteractive events go to all tools to facilitate (2)
If a tool called something like clearSelection while processing a
MOUSE_CLICK, the SELECTION_TOOL will pass the clearSelection
COMMAND_EVENT because it handles it as a transition, not as an
event. Because m_passEvent is effectively global, the tool manager
would then interpret that as passing the MOUSE_CLICK and we'd end
up processing the click by multiple tools.
Getting the position of a non-position TOOL_EVENT will
now result in a wxCHECK, and a null-position (0,0) will
be returned. The new interface HasPosition() can be used
to determine if a call to a position function is safe to
make from the caller.
Fixes the underlying danger behind lp:1796045, which has
already been neutralised by a4966adb6, which avoids calling
the Position() functions when the TOOL_EVENT is not known
to be a position.
Fixes: lp:1796045
* https://bugs.launchpad.net/kicad/+bug/1796045
It fixes the case when a tool sets up a menu and starts its event loop
waiting exclusively for menu events. If none arrived, the tool was stuck
in the loop forever.
Fixes: lp:1744915
* https://bugs.launchpad.net/kicad/+bug/1744915
TOOL_EVENT message is supposed to contain string as parameter.
Added missing header for class_drawsegment.h (KiROUND).
Renamed SELECTION_TOOL::containsSelected() to SELECTION_TOOL::selectionContains().