Hello Noel, 2012/1/13 Noel Power <nopo...@suse.com>: > Hi Guys, > > We have a bug here in the suse system that highlights a regression > attempting to resolve a range by name. Note: this is not a problem on > master. > > the failing macro code is something like so; > > Sub test > ProjectPlanSheet = ThisComponent.Sheets.getByName( "ProjectPlan" ) > chkCellControl = ProjectPlanSheet.getCellRangeByName( "TASK3_ON" ) > End Sub > > where "TASK3_ON" is a document global rangename > > after some digging the commits on master that seem to be involved are > e9159d142a4f25bff88da3dd90e163135ae0bdfa & > 9e8ae1d56076474e4673a953d8ebd726cb5daa18 > > I attach a backport of these patches ( in so far as I could backport them > with at times quite different code base ) > > Note: for this bug the patch to rangeutl.cxx seems sufficient, I backported > the rest for completeness. I want to sound you both out about applying the > patch either partially ( e.g. just the rangeutl.cxx part ) or even > completely to 3.4 or... even find out if ye considered either version too > risky. >
I think it makes sense to remove the findByName and replace them with findByUpperName. The findByName is error-prone and therefore I removed it for 3-5, internally we only use upper name (and in 3.5 we use it even to store the range name). I will clean-up your patch a bit because some changes to rangeutl.cxx only make sense with other changes in master/3.5. But before we push this changes to a stable branch I want to check with backporting the tests from 3.5 to 3.4 and check my other range name commits from my rework that I did not adjust one of these patches. Just to make it clear, I don't think that this patch will create any problems and is safe but I don't feel comfortable changing such an important part without the tests. Markus _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
