On Sunday 13 January 2002 6:48 pm, Michael Koziarski wrote:
> On Sun, Jan 13, 2002 at 04:55:15PM +0000 or thereabouts, John Levon wrote:
> > On Sun, Jan 13, 2002 at 09:19:02PM +1300, Michael Koziarski wrote:
> >
> > > I'm currently having a few problems with the GNOME frontend's
> > > FormUrl. The first one I'll tackle as it could be causing the
> > > other one. If I run
> >
> > Angus can you have a look at this please ? gnome/FormUrl.C looks
> > almost exactly like qt2's. We aren't building in any URL files twice
> > or anything like that. I really don't know where this behaviour is
> > coming from (the double URL thing).
> >
> > > That assert is failing. I notice that during construction params_ is
> > > initialised to 0, but all over the code it's given new Params().
Hardly all over the place.
* In the ControlInset::show which is the point of entry from the LyX kernel
to the dialog
* In ControlInset::update which could be called from the kernel, but is more
usually invoked when you press that reset button,
> > > In what situations could this be left as null, is there anything I can
> > > do to prevent this from happenning?
I don't think that it can. params_ is meant to be a temporary store. When the
dialog is visible, params_ is allocated some memory. When the dialog is
hidden, this memory is deallocated.
> > > inset_ is also null, if that's relevant at all.
That means that you're trying to create a new inset rather than modify an
existing one. Not relevant and not a problem.
> > an "OK" is being done, which applys the changes and removes
> > the connections from the dialog controller to a specific inset.
> >
> > so it's as if it were possible to press OK twice in the GUI and
> > that's whats happening ...
> > very odd
>
> Following the Apply case through the debugger it does pass through
> FormUrl::apply() twice, but both times applyParamsNoInset() is called,
> though the second time, there is an inset.
Well, I can't explain why you're calling apply twice here. Apply is called
from ControlButtons::OKButton() in this instance I think. Why not add a print
statement to this function so that you can confirm that you're emitting two
signals from the Gnome frontend? (Better than modifying ControlInset itself
since this'll mean that you'll have to recompile large numbers of files.)
Nor can I explain why an inset suddenly exists the second time since it's set
only in ControlInset::connectInset.
Nonetheless, I think you've hit on a bug. Well done! Although I don't think
it'll help solve your problem, the fix to that particular problem is:
template <class Inset, class Params>
void ControlInset<Inset, Params>::apply()
{
if (lv_.buffer()->isReadonly())
return;
view().apply();
- if (inset_ && params() != getParams(*inset_))
+ if (inset_)
+ if (params() != getParams(*inset_))
applyParamsToInset();
else
applyParamsNoInset();
if (disconnectOnApply() && !isClosing()) {
*params_ = getParams(string());
inset_ = 0;
ih_.disconnect();
view().update();
}
}
Keep up the good work!
Angus
