>>>>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> I don't think the patch was really thought to be commited, it
Juergen> was more a stuff to see if it solves leaking. After that we
Juergen> know that we would have to free the paragraphs. But the place
Juergen> is wrong!
OK, but it is right for 1.1.6, isn't it?
Juergen> We have to release the paragraphs only at the end
Juergen> of the function! I think we could save the Paragraph * in a
Juergen> vector and then delete them at the end. That would be clean
Juergen> enough IMO.
Why do we have to do that?
bv-> text->ownerParagraph(tmppar3->id(),tmppar3)
Juergen> Head that now we don't have ONE ownerParagraph but EVERY
Juergen> InsetText has it's own FIRST (owner) paragraph. So if tmppar3
Juergen> is INSIDE an inset it means that it is the ownerParagraph()
Juergen> of that inset!
OK, this LyXText::ownerParagraph starts with
void LyXText::ownerParagraph(int id, Paragraph * p) const
{
Paragraph * op = bv_owner->buffer()->getParFromID(id);
if (op && op->inInset()) {
static_cast<InsetText *>(op->inInset())->paragraph(p);
So you are looking for tmppar3 inside the buffer, right? But how can
it be there already, since you have not linked it in at this point?
bv-> text->ownerParagraph(tmppar3);
Juergen> Here you would only handle the case where tmppar3 ==
Juergen> buffers-first-paragraph!
I know that. Actually I figured this out after looking at the code
long enough.
>> Juergen, would you care to explain what happens or (better) to
>> provide a fix?
Juergen> Sure we are still using the freed paragraphs UNTIL we have
Juergen> the new ones REALLY assigned. I explained it above!
So we are looking for information in these freed paragraphs although
we know they are not quite right?
JMarc
