kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #19834
Re: Assertion trip due to out-of-order dialog close
This may be window manager related. I get no assertion on windows.
I've seen this before and it appears to be a unfortunate side effect of
the Kiway design. Any dialog derived from DIALAG_SHIM must have a Kiway
object as a parent if it is shown as quasimodal. If you try to make the
parent another DIALOG_SHIM object, you will get the assertion. If you
don't derive you dialog from DIALOG_SHIM and show it as modal, it will
block all of the other open main windows launched by KiCad.
On 8/19/2015 5:50 AM, Lorenzo Marcantonio wrote:
>
> Could be a window manager related issue or just an untested code path;
> in yesterday version:
>
> - Open a board and hover on a part
> - 'E' for component properties
> - Choose 'Change Footprints'
> - With the change dialog open, the footprint properties one is still
> focusable; so you can close it (ESC, OK or cancel, doesn't seem to
> matter)
> - Now try to close the change footprints dialog; the window stack is
> messed up and an assertion triggers:
>
>
> ASSERT INFO:
> /home/lomarcan/cvswork/kicad-bzr/common/dialog_shim.cpp(525): assert "Assert failure" failed in EndQuasiModal(): either DIALOG_SHIM::EndQuasiModal called twice or ShowQuasiModal wasn't called
>
> BACKTRACE:
> [1] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
> [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
> [3] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
> [4] wxEvtHandler::TryHereOnly(wxEvent&)
> [5] wxEvtHandler::ProcessEventLocally(wxEvent&)
> [6] wxEvtHandler::ProcessEvent(wxEvent&)
> [7] wxEvtHandler::SafelyProcessEvent(wxEvent&)
>
> (cut of the most unhelpful stack trace ever seen... the interesting
> stuff probably already happened and queued the close event before
> returning)
>
Follow ups
References