← Back to team overview

kicad-developers team mailing list archive

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