On 10-Dec-2001 Allan Rae wrote:
>> | Now that we've established that the code you wrote has several
>> | redundancies I have committed a patch to clean them up -- removing 10
>> | lines of code in the process. Three cases of plus one other:
I've seen the changes on lyx-cvs (I always have a loo
On Mon, 10 Dec 2001, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | On Fri, 7 Dec 2001, Juergen Vigna wrote:
> >
> >>
> >> On 07-Dec-2001 Allan Rae wrote:
> >> > Perhaps there is some other thinking behind this apparent discrepency?
> >> > Or I'm still misunderstanding s
On Fri, 7 Dec 2001, Juergen Vigna wrote:
>
> On 07-Dec-2001 Allan Rae wrote:
> > Perhaps there is some other thinking behind this apparent discrepency?
> > Or I'm still misunderstanding something.
>
> Well I'm now writing v e r ys l o w l y so you
> may understand this t
On 07-Dec-2001 Allan Rae wrote:
> Perhaps there is some other thinking behind this apparent discrepency?
> Or I'm still misunderstanding something.
Well I'm now writing v e r ys l o w l y so you
may understand this time (hopefully):
We call: unlockInsetInInset(bv, the_
On Thu, 6 Dec 2001, Juergen Vigna wrote:
>
> On 06-Dec-2001 Allan Rae wrote:
>
> > The use of the_locking_inset there seems haphazard at best. Some
> > places seem to clear the_locking_inset after an unlock call while
> > others don't.
>
> Well sometimes I think you should sleep a bit more befor
On 06-Dec-2001 Juergen Vigna wrote:
>> There appear as though there may be a few places where
>> InsetText::the_locking_inset isn't cleared after an unlock attempt but
>
> ??? We don't have a InsetText::the_locking_inset!!!
Sorry we obviously HAVE one (it was very e
conditionally like all
> the other instances in insettabular.C?
We don't need to use the returnvalue as it is irrelevant INSIDE THIS
insettabular, but unlockInsetInInset() is also called from the outside
world and there the returnvalue IS important!
> There appear as though the
he_locking_inset);
insettabular.C:1744:unlockInsetInInset(bv, the_locking_inset);
insettabular.C:1755:unlockInsetInInset(bv, the_locking_inset);
There appear as though there may be a few places where
InsetText::the_locking_inset isn't cleared after an unlock attempt but
the code using
then the claimed pure
virtual function must be called by the insettext in the minipage.
But why would it go bang?
Because InsetText::the_locking_inset is an InsetFig in this case?
Maybe, maybe not. Another case after the backtrace.
src/insets/insettext.C:
1820 1.171 (jug 12-Jul-01
