On 11/11/2014 11:00 PM, Alfredo Braunstein wrote:
Excellent, thanks! What could be a good way of avoiding this mess in
the future? Maybe put this code in a Buffer::setDocumentClass function
and use always that instead of the BufferParams one? I barely know
what I'm talking about here...
setDocumentClass() is only used in this one place, and it should never,
ever be used anywhere else. The only reason it is used here is because
putClipboard re-uses clones of a single static Buffer, so we have to
reset the DocumentClass associated with that Buffer whenever we clone
it. The usual way to do this is to build a new DocumentClass from a
TextClass and the associated modules, but in this case we are given the
DocumentClass directly, so we can't do that.
In fact, the dangling pointer is harmless, since the empty paragraph to
which it is attached almost immediately disappears when we paste the new
content. So we don't really need to reset the paragraphs: We never do
anything with them. That makes me wonder if the following would not also
silence valgrind with less work:
DocumentClassConstPtr olddc = buffer->params().documentClassPtr();
Then the document class will hang around until olddc goes out of scope
at the end of the routine.
Another possibility, which would get rid of setDocumentClass, would be
to allow cloneBufferOnly() to take an optional DocumentClassConstPtr
object, and to set the document class when we do the clone if it is
given. Then we do not make a new DocumentClass only immediately to
destory it.
Richard
