[REVIEW 3-6] fix for fdo#56742 , ScRangeList::UpdateReference does not handle URM_COPY
Hey, [1] fixes [2] which is more or less a problem in ScRangeList::UpdateReference but we can't safely change it as there might be some users that rely on this behavior. So we just map URM_COPY to URM_MOVE which does the right thing in our case too. Regards, Markus [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c60abfdb617039cedc53982c7c8eca640e28cac [2] https://bugs.freedesktop.org/show_bug.cgi?id=56742 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW 3-6] fix for fdo#56742 , ScRangeList::UpdateReference does not handle URM_COPY
Hi Markus, On Saturday, 2012-12-15 15:28:49 +0100, Markus Mohrhard wrote: [1] fixes [2] which is more or less a problem in ScRangeList::UpdateReference but we can't safely change it as there might be some users that rely on this behavior. So we just map URM_COPY to URM_MOVE which does the right thing in our case too. Hmm.. sure it doesn't introduce unwanted side effects? When copying from one sheet to another, previously all relative references where then relative to the new position with same offsets. With the change relative references moved along with the range still do this, but references pointing outside that range now still point to the old position instead of the new relative position. Note: I didn't try, just making this up from what I know about reference handling so far.. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpVGGMPa6p5U.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW 3-6] fix for fdo#56742 , ScRangeList::UpdateReference does not handle URM_COPY
Hey Eike, [1] fixes [2] which is more or less a problem in ScRangeList::UpdateReference but we can't safely change it as there might be some users that rely on this behavior. So we just map URM_COPY to URM_MOVE which does the right thing in our case too. Hmm.. sure it doesn't introduce unwanted side effects? When copying from one sheet to another, previously all relative references where then relative to the new position with same offsets. With the change relative references moved along with the range still do this, but references pointing outside that range now still point to the old position instead of the new relative position. Note: I didn't try, just making this up from what I know about reference handling so far.. I'm only using URM_MOVE to update references inside a ScRangeList which just contains a vector of ScRange entries. Since ScRange does not contain a notion of relative or absolute references this is a safe change, Two lines later where I call UpdateReference for the entries which might contain formulas I still use the original URM_* netry. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
