[Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
ooo at erack.de
Tue Aug 16 08:31:10 PDT 2011
On Tuesday, 2011-08-16 17:08:53 +0200, Markus Mohrhard wrote:
> > > > The change to the ScFormulaCell ctor apparently unconditionally tries
> > to
> > > > adjust name tokens, this is completely unnecessary in most situations
> > > > and should be triggered only if the sheets of new and old position
> > > > differ.
> > >
> > > No it's not that easy. If we have the same sheet and two different
> > > documents, we need to adjust too. And we can't simply check that the
> > > ScDocument instances are different because they will always be. Either we
> > > have a pointer to the original ScDocument instance in the copy document
> > or
> > > we must always adjust our range names. I used the second approach because
> > I
> > > didn't like the other approach.
> > So at least compare document instances and sheets and if both are
> > identical don't do the adjustment, which I think is the most used
> > scenario when copying cells. Sounds plausible?
> So just to understand you correctly: You suggest to introduce a new variable
> ScDocument* pOriginalDoc; in ScDocument and check if this pointer and the
> address of rNewDoc are the same? I didn't like this very much but I have no
> strong opinion here. If you think that this would be the better version i
> will change this.
No, no new member variable, what I was thinking of is to detect whether
the original source document of the clipboard document is identical to
the current document. There is a way via the document pool, I'll dig out
> > Btw, how well does this all cope with undo/redo?
> I don't see any problems with undo/redo. Local range names are copied either
> way and if global range names are not copied then my check that a global
> ScRangeName exists will fail and don't adjust anything. But I think we can
> simply add a check for IsUndo. Then we don't have to think about it anymore.
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the LibreOffice