Georg Baum wrote:
> Georg Baum wrote:
>
>> We still have some crashes related to open dialogs, see
>> http://bugzilla.lyx.org/show_bug.cgi?id=1879. The attached patch should
>> fix them. I am now pretty sure that I understand LFUN_INSET_MODIFY: The
>> arguments are the new inset parameters. For many insets the first
>> parameter is thee inset name, but not for all. So it is safe to accept
>> LFUN_INSET_MODIFY in InsetBase::getStatus() unconditionally.
>> The other changes are some leftovers from my last patch. This is going
>> in tomorrow unless somebody objects.
>
> I applied that now, but it was not the whole fix. It only moved the
> crash, we have a more general problem here: The Dialogs class stores a
> InsetBase * for every open dialog. If you delete an inset while the
> dialog is open the pointer does still exist, but is not valid anymore.
> Storing a pointer in frontend code while all other
> fronted-core-interaction uses strings is no clean design IMHO.
If memory serves me right, all insets should emit a signal from their
destructor:
InsetCommand::~InsetCommand()
{
if (!mailer_name_.empty())
InsetCommandMailer(mailer_name_, *this).hideDialog();
}
void MailInset::hideDialog() const
{
Dialogs::hide(name(), &inset());
}
// Note that this is a static member function.
void Dialogs::hide(string const & name, InsetBase* inset)
{
hideSignal()(name, inset);
}
> A proof-of-concept fix is attached. It works only for "normal" delete
> (the inset must not be selected, and the deletion must not cause a
> paragraph merge. BTW, Dialogs::hideSlot() is currently not used.
Urgggg. When did that happen?
> Does anybody have an idea what to do now?
Connect the signal to the slot.
--
Angus
